RFC2856 日本語訳
2856 Textual Conventions for Additional High Capacity Data Types. A.Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT=20954 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Bierman
Request for Comments: 2856 K. McCloghrie
Category: Standards Track Cisco Systems, Inc.
R. Presuhn
BMC Software, Inc.
June 2000
Biermanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2856年のK.McCloghrieカテゴリ: 標準化過程シスコシステムズInc.R.Presuhn BMCソフトウェアInc.2000年6月
Textual Conventions for Additional High Capacity Data Types
追加高容量データ型のための原文のコンベンション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future.
このメモは既にCounter64データ型をサポートするSNMP実装のために意図する追加高容量データ型に新しい原文のコンベンションを指定します。 本書では含まれた定義は将来推奨しないかもしれない短期間ソリューションを表します。
Table of Contents
目次
1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Short Term and Long Term Objectives ......................... 3 2.2 Limitations of the Textual Convention Approach .............. 3 3 New Textual Conventions ....................................... 4 3.1 CounterBasedGauge64 ......................................... 4 3.2 ZeroBasedCounter64 .......................................... 4 4 Definitions ................................................... 4 5 Intellectual Property ......................................... 7 6 References .................................................... 7 7 Security Considerations ....................................... 9 8 Authors' Addresses ............................................ 9 9 Full Copyright Statement ...................................... 10
1 SNMP管理フレームワーク… 2 2概要… 3 2.1短期間、長期目的… 3 原文のコンベンションの2.2の制限にアプローチします… 3 3の新しい原文のコンベンション… 4 3.1CounterBasedGauge64… 4 3.2ZeroBasedCounter64… 4 4の定義… 4 5知的所有権… 7 6の参照箇所… 7 7のセキュリティ問題… 9 8人の作者のアドレス… 9 9の完全な著作権宣言文… 10
Bierman, et al. Standards Track [Page 1] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[1ページ]。
1. The SNMP 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 of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[RFC1905]で説明されます。
o A set of fundamental applications 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 specifies a MIB module that is compliant to the SMIv2. The textual conventions defined in this MIB module cannot be translated to SMIv1 since the Counter64 type does not exist in SMIv1.
このメモはSMIv2に対応であるMIBモジュールを指定します。 Counter64タイプがSMIv1に存在していないので、このMIBモジュールで定義された原文のコンベンションはSMIv1に翻訳できません。
Bierman, et al. Standards Track [Page 2] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[2ページ]。
2. Overview
2. 概要
The Structure of Management Information [RFC2578] does not explicitly address the question of how to represent integer objects other than counters that would require up to 64 bits to provide the necessary range and precision. There are MIBs in progress targeted for the standards track, which need such data types. This memo specifies a short term solution, using textual conventions, to meet these needs.
Management情報[RFC2578]のStructureは明らかにどう必要な範囲と精度を提供するために最大64ビットを必要とするカウンタ以外の整数オブジェクトを表すかに関する質問を扱いません。 標準化過程に狙う進行中におけるMIBsがあります。(MIBsはそのようなデータ型を必要とします)。 これらの需要を満たすのに原文のコンベンションを使用して、このメモは短期間ソリューションを指定します。
2.1. Short Term and Long Term Objectives
2.1. 短期間、長期目的
There is an immediate need to provide a Gauge64 data type, similar in semantics to the Gauge32 data type, in order to support common data representations such as:
Gauge64データ型を提供する即座の必要があります、意味論では、一般的なデータが以下などの表現であるとサポートして、Gauge32データ型と同様です。
- a snapshot of a Counter64 at a given moment, e.g., history ring
buffer
- 与えられた瞬間、例えば、歴史リングバッファのCounter64のスナップ
- the difference between two Counter64 values
- 2つのCounter64値の違い
There is also an immediate need for a 64-bit zero-based counter type, similar in semantics to the ZeroBasedCounter32 TC defined in the RMON-2 MIB [RFC2021].
また、64ビットの無ベースのカウンタタイプの即座の必要があります、意味論では、RMON-2 MIB[RFC2021]で定義されたZeroBasedCounter32 TCと同様です。
Both of these textual conventions should use a base type of Gauge64 or Unsigned64, but such a base type is not available. Until such a base type is defined and deployed, these temporary textual conventions (which use a base type of Counter64) will be used in MIBs which require unsigned 64-bit data types.
これらの原文のコンベンションの両方がGauge64かUnsigned64のベースタイプを使用するべきですが、そのようなベースタイプは手があいていません。 そのようなベースタイプが定義されて、配布されるまで、これらの一時的な原文のコンベンション(Counter64のベースタイプを使用する)は未署名の64ビットのデータタイプを必要とするMIBsで使用されるでしょう。
In order to be backward compatible with existing implementations of Counter64, the ASN.1 encoding of unsigned 64-bit data types must be identical to the encoding of Counter64 objects, i.e., identified by the [APPLICATION 6] ASN.1 tag.
Counter64の既存の実装と互換性があった状態で後方であるために、すなわち、[APPLICATION6]ASN.1タグによって特定されて、未署名の64ビットのデータタイプのASN.1コード化はCounter64オブジェクトのコード化と同じでなければなりません。
Note that the textual conventions defined in this document represent a limited and short-term solution to the problem. These textual conventions may be deprecated as a long term solution is defined and deployed to replace them. A MIB object which uses either of these textual conventions may also eventually have to be deprecated.
本書では定義された原文のコンベンションが制限されて短期的なソリューションを問題に表すことに注意してください。 長期ソリューションがそれらに取って代わるために定義されて、配布されるとき、これらの原文のコンベンションは推奨しないかもしれません。 また、これらの原文のコンベンションのどちらかを使用するMIBオブジェクトも結局、推奨しなくなければならないかもしれません。
2.2. Limitations of the Textual Convention Approach
2.2. 原文のコンベンションアプローチの制限
New unsigned data types with textual conventions based on the Counter64 tag, instead of a new (or other existing) ASN.1 tag have some limitations:
新しい(または、他の存在)ASN.1タグの代わりにCounter64タグに基づいている原文のコンベンションに伴う新しい未署名のデータ型には、いくつかの制限があります:
Bierman, et al. Standards Track [Page 3] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[3ページ]。
- The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS
of the underlying Counter64 type is read-only.
- 基本的なCounter64のマックス-ACCESSタイプが書き込み禁止であるので、TCのマックス-ACCESSは書き込み禁止であるに違いありません。
- No sub-range can be specified on the TC-derived types, because
sub-ranges are not allowed on Counter64 objects.
- サブ範囲がCounter64オブジェクトの上に許容されていないので、TC-派生型の上でサブ範囲を全く指定できません。
- No DEFVAL clause can be specified for the TC-derived types,
because DEFVALs are not allowed on Counter64 objects.
- DEFVALsがCounter64オブジェクトの上に許容されていないので、TC-派生型にDEFVAL節を全く指定できません。
- The TC-derived types cannot be used in an INDEX clause, because
there is no INDEX clause mapping defined for objects of type
Counter64.
- INDEX節でTC-派生型を使用できないで、INDEXが全くないので、節マッピングはタイプのオブジェクトのためにCounter64を定義しました。
3. New Textual Conventions
3. 新しい原文のコンベンション
The following textual conventions are defined to support unsigned 64-bit data types.
以下の原文のコンベンションは、未署名の64ビットのデータがタイプであるとサポートするために定義されます。
3.1. CounterBasedGauge64
3.1. CounterBasedGauge64
This textual convention defines a 64-bit gauge, but defined with Counter64 syntax, since no Gauge64 or Unsigned64 base type is available in SMIv2.
しかし、この原文のコンベンションはCounter64構文で定義されていた状態で64ビットのゲージを定義します、Gauge64かどんなUnsigned64ベースタイプもSMIv2に手があいていないので。
This TC is used for storing the difference between two Counter64 values, or simply storing a snapshot of a Counter64 value at a given moment in time.
このTCは、2つのCounter64値の違いを保存するか、または時間内に与えられた瞬間に単にCounter64価値のスナップを保存するのに使用されます。
3.2. ZeroBasedCounter64
3.2. ZeroBasedCounter64
This textual convention defines a 64-bit counter with an initial value of zero, instead of an arbitrary initial value.
この原文のコンベンションは任意の初期の値の代わりにゼロの初期の値で64ビットのカウンタを定義します。
This TC is used for counter objects in tables which are instantiated by management application action.
このTCは管理アプリケーション動作で例示されるテーブルのカウンタオブジェクトに使用されます。
4. Definitions
4. 定義
HCNUM-TC DEFINITIONS ::= BEGIN
HCNUM-Tc定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, mib-2, Counter64
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
IMPORTS MODULE-IDENTITY、mib-2、Counter64 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC。
hcnumTC MODULE-IDENTITY
LAST-UPDATED "200006080000Z"
hcnumTCモジュールアイデンティティは"200006080000Z"をアップデートしました。
Bierman, et al. Standards Track [Page 4] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[4ページ]。
ORGANIZATION "IETF OPS Area"
CONTACT-INFO
" E-mail: mibs@ops.ietf.org
Subscribe: majordomo@psg.com
with msg body: subscribe mibs
「以下をメールしてください」という組織「IETFオプアート領域」コンタクトインフォメーション mibs@ops.ietf.org は申し込まれます: msgボディーがある majordomo@psg.com : mibsを申し込んでください。
Andy Bierman
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134 USA
+1 408-527-3711
abierman@cisco.com
アンディBiermanシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア95134米国+1 408-527-3711 abierman@cisco.com
Keith McCloghrie
Cisco Systems Inc.
170 West Tasman Drive
San Jose, CA 95134 USA
+1 408-526-5260
kzm@cisco.com
キースMcCloghrieシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア95134米国+1 408-526-5260 kzm@cisco.com
Randy Presuhn
BMC Software, Inc.
Office 1-3141
2141 North First Street
San Jose, California 95131 USA
+1 408 546-1006
rpresuhn@bmc.com"
DESCRIPTION
"A MIB module containing textual conventions
for high capacity data types. This module
addresses an immediate need for data types not directly
supported in the SMIv2. This short-term solution
is meant to be deprecated as a long-term solution
is deployed."
REVISION "200006080000Z"
DESCRIPTION
"Initial Version of the High Capacity Numbers
MIB module, published as RFC 2856."
::= { mib-2 78 }
「ランディPresuhn BMC Software Inc.オフィス1-3141 2141北部Firstサンノゼ、通りカリフォルニア95131米国+1 408 546-1006 rpresuhn@bmc.com 」記述、「高容量データ型のための原文のコンベンションを含むMIBモジュール。」 このモジュールはSMIv2で直接サポートされなかったデータ型の即座の必要性を扱います。 「長期的な解決法が配布されるのでこの短期的なソリューションが推奨しないことが意味されます。」 REVISION"200006080000Z"記述は「RFC2856として発行された高容量数のMIBモジュールのバージョンに頭文字をつけます」。 ::= mib-2 78
CounterBasedGauge64 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The CounterBasedGauge64 type represents a non-negative
integer, which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum value. The
maximum value can not be greater than 2^64-1
(18446744073709551615 decimal), and the minimum value can
CounterBasedGauge64:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「非負の整数を表CounterBasedGauge64がタイプするします」。(負の整数は、最大値を決して超えないのを除いて、増減して、最小値の下まで下がるかもしれません)。 最大値は極めてすばらしいはずがありません。
Bierman, et al. Standards Track [Page 5] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[5ページ]。
not be smaller than 0. The value of a CounterBasedGauge64
has its maximum value whenever the information being modeled
is greater than or equal to its maximum value, and has its
minimum value whenever the information being modeled is
smaller than or equal to its minimum value. If the
information being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
CounterBasedGauge64 also decreases (increases).
0ほど小さくはありません。 CounterBasedGauge64の値には、モデル化される情報がそう以上であるときはいつも、最大値があります。そして、最大が評価する、モデル化される情報が、より最小値以下であるときはいつも、最小値を持っています。 また、次にモデル化される情報が以下(上では、増加する)で最大(最小の)の値を減少させるなら、CounterBasedGauge64は減少します(増加します)。
Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap' semantics
associated with the Counter64 base type are not preserved.
It is possible that management applications which rely
solely upon the (Counter64) ASN.1 tag to determine object
semantics will mistakenly operate upon objects of this type
as they would for Counter64 objects.
このTCがSMIv2で厳密にサポートされないことに注意してください、意味論がCounter64ベースタイプに関連づけた'いつも増加'と'カウンタ包装'が保存されないので。 オブジェクト意味論を決定するために唯一(Counter64)ASN.1タグを当てにされる管理アプリケーションがCounter64オブジェクトのために作動するようにこのタイプのオブジェクトを誤って作動させるのは、可能です。
This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it."
SYNTAX Counter64
「この原文のコンベンションは、制限されて短期的なソリューションを表して、長期ソリューションがそれを取り替えるために定義されて、配布されるとき、推奨しないかもしれません。」 構文Counter64
ZeroBasedCounter64 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^64 is
reached.
ZeroBasedCounter64:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このTCは以下の意味論でイベントを数えるオブジェクトについて説明します」。 このタイプのオブジェクトは、作成の(0)のゼロを合わせるように設定されて、その後適切なイベントを数えるでしょう、値2^64に達しているとき、(0)のゼロを合わせるために後部を包装して。
Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware
of this minimum time and the actual time between polls, and
to discard data if the actual time is too long or there is
no defined minimum time.
アプリケーションが包装する最小の時中に新しいオブジェクトを発見すれば、それは、最後にこのオブジェクトが部分であるテーブルに投票したので、デルタとして初期の値を使用できます。 実際の時間が長過ぎるか、または最小の時間が定義されないなら、管理局がこの最小の時間と投票の間の実際の現代を意識していて、データを捨てるのは重要です。
Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in
use.
通常、このTCはINDEXスペースが絶えず変化していて、TimeFilterメカニズムが使用中であるテーブルで使用されます。
Note that this textual convention does not retain all the
semantics of the Counter64 base type. Specifically, a
Counter64 has an arbitrary initial value, but objects
defined with this TC are required to start at the value
この原文のコンベンションがCounter64ベースタイプのすべての意味論を保有するというわけではないことに注意してください。 明確に、Counter64には、任意の初期の値がありますが、このTCと共に定義されたオブジェクトは値で出発しなければなりません。
Bierman, et al. Standards Track [Page 6] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[6ページ]。
zero. This behavior is not likely to have any adverse
effects on management applications which are expecting
Counter64 semantics.
ゼロ。 この振舞いはCounter64意味論を予想している管理アプリケーションにどんな悪影響も及ぼしそうにはありません。
This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it."
SYNTAX Counter64
「この原文のコンベンションは、制限されて短期的なソリューションを表して、長期ソリューションがそれを取り替えるために定義されて、配布されるとき、推奨しないかもしれません。」 構文Counter64
END
終わり
5. Intellectual Property
5. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格の関連するドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
6. References
6. 参照
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
Bierman, et al. Standards Track [Page 7] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[7ページ]。
[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月。」
[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月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
RFC 2021, January 1997.
S.、「リモートネットワーク監視MIB(RMON-2)」、RFC2021 1997年1月の[RFC2021]Waldbusser。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[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月)。
[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月)。
Bierman, et al. Standards Track [Page 8] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[8ページ]。
[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月のための順応声明。」
7. Security Considerations
7. セキュリティ問題
This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects.
このモジュールはどんな管理オブジェクトも定義しません。 代わりに、それは管理オブジェクトを定義するのに他のMIBモジュールで使用されるかもしれない1セットの原文のコンベンションを定義します。
Meaningful security considerations can only be written in the modules that define management objects.
管理オブジェクトを定義するモジュールで重要なセキュリティ問題を書くことができるだけです。
8. Authors' Addresses
8. 作者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveアンディBiermanシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
Phone: +1 408-527-3711 EMail: abierman@cisco.com
以下に電話をしてください。 +1 408-527-3711 メールしてください: abierman@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
Phone: +1 408-526-5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1 408-526-5260 メールしてください: kzm@cisco.com
Randy Presuhn BMC Software, Inc. Office 1-3141 2141 North First Street San Jose, California 95131 USA
ランディPresuhn BMCソフトウェアInc.オフィス1-3141 2141の北の最初に、通りサンノゼ、カリフォルニア95131米国
Phone: +1 408 546-1006 EMail: rpresuhn@bmc.com
以下に電話をしてください。 +1 408 546-1006 メールしてください: rpresuhn@bmc.com
Bierman, et al. Standards Track [Page 9] RFC 2856 High Capacity Data Types June 2000
Bierman、他 規格は高容量データ型2000年6月にRFC2856を追跡します[9ページ]。
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. Standards Track [Page 10]
Bierman、他 標準化過程[10ページ]
一覧
スポンサーリンク
