RFC3877 日本語訳
3877 Alarm Management Information Base (MIB). S. Chisholm, D.Romascanu. September 2004. (Format: TXT=149783 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Chisholm
Request for Comments: 3877 Nortel Networks
Category: Standards Track D. Romascanu
Avaya
September 2004
コメントを求めるワーキンググループS.チスホルム要求をネットワークでつないでください: 3877 ノーテルはカテゴリをネットワークでつなぎます: 標準化過程D.Romascanu Avaya2004年9月
Alarm Management Information Base (MIB)
アラーム管理情報ベース(MIB)
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 (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはアラームをモデル化して、格納するのに使用される管理物について説明します。
Chisholm & Romascanu Standards Track [Page 1] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[1ページ]RFC3877はMIB2004年9月に驚かせます。
Table of Contents
目次
1. The Internet-Standard Management Framework . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Alarm Management Framework . . . . . . . . . . . . . . . . . . 4
3.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Alarm Management Architecture. . . . . . . . . . . . . . 5
3.3. Features of this Architecture. . . . . . . . . . . . . . 5
3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Relationship between Alarm and Notifications . . . . . . 9
3.6. Notification Varbind Storage and Reference . . . . . . . 9
3.7. Relation to Notification Log MIB . . . . . . . . . . . . 10
3.8. Relation to Event MIB. . . . . . . . . . . . . . . . . . 10
4. Generic Alarm MIB. . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Definitions. . . . . . . . . . . . . . . . . . . . . . . 15
5. ITU Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2. IANA Considerations. . . . . . . . . . . . . . . . . . . 39
5.3. Textual Conventions. . . . . . . . . . . . . . . . . . . 47
5.4. Definitions. . . . . . . . . . . . . . . . . . . . . . . 49
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1. Alarms Based on linkUp/linkDown Notifications. . . . . . 59
6.2. Temperature Alarm using generic Notifications. . . . . . 62
6.3. Temperature Alarm without Notifications. . . . . . . . . 63
6.4. Printer MIB Alarm Example. . . . . . . . . . . . . . . . 65
6.5. Rmon Alarm Example . . . . . . . . . . . . . . . . . . . 66
6.6. The Lifetime of an Alarm . . . . . . . . . . . . . . . . 67
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 70
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.1. Normative References . . . . . . . . . . . . . . . . . . 72
9.2. Informative References . . . . . . . . . . . . . . . . . 73
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 74
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 75
1. インターネット標準の管理枠組み. . . . . . . . . . 3 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 管理枠組み. . . . . . . . . . . . . . . . . . 4 3.1を驚かせてください。 用語。 . . . . . . . . . . . . . . . . . . . . . . 4 3.2. 管理体系を驚かせてください。 . . . . . . . . . . . . . 5 3.3. このArchitectureの特徴。 . . . . . . . . . . . . . 5 3.4. セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . 8 3.5。 アラームと通知. . . . . . 9 3.6との関係。 通知Varbind格納と参照. . . . . . . 9 3.7。 通知ログMIB. . . . . . . . . . . . 10 3.8との関係。 イベントMIBとの関係。 . . . . . . . . . . . . . . . . . 10 4. 一般的なアラームMIB。 . . . . . . . . . . . . . . . . . . . . . . 10 4.1. 概観. . . . . . . . . . . . . . . . . . . . . . . . 10 4.2。 定義。 . . . . . . . . . . . . . . . . . . . . . . 15 5. ITUアラーム。 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1. 概観. . . . . . . . . . . . . . . . . . . . . . . . 38 5.2。 IANA問題。 . . . . . . . . . . . . . . . . . . 39 5.3. 原文のコンベンション。 . . . . . . . . . . . . . . . . . . 47 5.4. 定義。 . . . . . . . . . . . . . . . . . . . . . . 49 6. 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.1。 アラームは通知を結合/linkDownに基礎づけました。 . . . . . 59 6.2. 一般的なNotificationsを使用する温度Alarm。 . . . . . 62 6.3. 通知のない温度アラーム。 . . . . . . . . 63 6.4. プリンタMIBは例を驚かせます。 . . . . . . . . . . . . . . . 65 6.5. Rmonは例. . . . . . . . . . . . . . . . . . . 66 6.6を驚かせます。 アラーム. . . . . . . . . . . . . . . . 67 7の生涯。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 70 8. 承認. . . . . . . . . . . . . . . . . . . . . . . 72 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 72 9.1。 引用規格. . . . . . . . . . . . . . . . . . 72 9.2。 有益な参照. . . . . . . . . . . . . . . . . 73 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 74 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 75
Chisholm & Romascanu Standards Track [Page 2] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[2ページ]RFC3877はMIB2004年9月に驚かせます。
1. The Internet-Standard Management Framework
1. インターネット標準の管理枠組み
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モジュールを指定します。
2. Introduction
2. 序論
In traditional SNMP management, problems are detected on an entity either through polling interesting MIB variables, waiting for the entity to send a Notification for a problem, or some combination of the two. This method is somewhat successful, but experience has shown some problems with this approach. Managers monitoring large numbers of entities cannot afford to be polling large numbers of objects on each device. Managers trying to ensure high reliability are unable to accurately determine whether any problems had occurred when they were not monitoring an entity. Finally, it can be time consuming for managers to try to understand the relationships between the various objects they poll, the Notifications they receive and the problems occurring on the entity. Even after detailed analysis they may still be left with an incomplete picture of what problems are occurring. But, it is important for an operator to be able to determine current problems on a system, so they can be fixed.
伝統的なSNMP管理では、問題は実体におもしろいMIB変数に投票することで検出されます、実体が問題、または2つのものの何らかの組み合わせのために通知書を送るのを待っていて。 この方法はいくらかうまくいっていますが、経験はこのアプローチに関するいくつかの問題を示しました。 多くの実体をモニターしているマネージャには各装置で多くの物に投票する余裕がありません。 高信頼性を確実にしようとするマネージャは、実体をモニターしていなかったとき、何か問題が起こったかどうか正確に決定できません。 最終的に、マネージャがそれらが投票する様々な物と、彼らが受けるNotificationsと実体に起こることにおける問題との関係を理解していようとするのは、時間がかかっている場合があります。 詳細に渡る分析の後にさえ、それらはどんな問題が起こるかに関する不完全な絵と共にまだ出られているかもしれません。 しかし、オペレータがシステムの上で現在の問題を決定できるのは、それらを修理できるように重要です。
This memo describes a method of using alarm management in SNMP to address these problems. It also provides the necessary MIB objects to support this method.
このメモはこれらのその問題を訴えるSNMPでのアラーム管理を使用する方法を説明します。また、それは、この方法を支持するために必要なMIB物を提供します。
Alarms and other terms related to alarm management are defined in the following sections.
アラーム管理に関連するアラームと他の用語は以下のセクションで定義されます。
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, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Chisholm & Romascanu Standards Track [Page 3] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[3ページ]RFC3877はMIB2004年9月に驚かせます。
3. Alarm Management Framework
3. アラーム管理枠組み
3.1. Terminology
3.1. 用語
Error
A deviation of a system from normal operation.
通常の操作からのシステムの誤りA逸脱。
Fault
Lasting error or warning condition.
欠点Lasting誤りか警告状態。
Event
Something that happens which may be of interest. A fault, a
change in status, crossing a threshold, or an external input to
the system, for example.
イベントSomething、興味があるかもしれないそれは起こります。 欠点、例えば、敷居、または外部の入力にシステムと交差する状態の変化。
Notification
Unsolicited transmission of management information.
経営情報の通知Unsolicited伝達。
Alarm
Persistent indication of a fault.
欠点のPersistentしるしを驚かせてください。
Alarm State
A condition or stage in the existence of an alarm. As a minimum,
alarms states are raise and clear. They could also include
severity information such as defined by perceived severity in the
International Telecommunications Union (ITU) model [M.3100] -
cleared, indeterminate, critical, major, minor and warning.
アラームの存在に州A状態かステージを驚かせてください。 最小のアラーム州が昇給であり、きれいにされるので。 また、彼らは知覚された厳しさによって国際Telecommunications Union(ITU)モデル[M.3100]で定義されるように厳しさ情報を含むかもしれません--クリアされて、不確定の、そして、批判的で、主要な未成年者と警告。
Alarm Raise
The initial detection of the fault indicated by an alarm or any
number of alarm states later entered, except clear.
アラームによって示された欠点の初期の検出かいろいろなアラーム州が後で入ったRaiseを驚かせてください、そして、クリアしてください。
Alarm Clear
The detection that the fault indicated by an alarm no longer
exists.
Clearを驚かせてください。欠点がもうアラームで存在しないのを示した検出。
Active Alarm
An alarm which has an alarm state that has been raised, but not
cleared.
アラームがそれを述べる活性Alarm Anアラームは、上げられますが、きれいにされていません。
Alarm Detection Point
The entity that detected the alarm.
Detection Pointを驚かせてください。アラームを検出した実体。
Perceived Severity
The severity of the alarm as determined by the alarm detection
point using the information it has available.
Severityがアラーム検出ポイントのそばで同じくらい決定しているアラームの厳しさであるとそれが利用可能にする情報を使用することで知覚しました。
Chisholm & Romascanu Standards Track [Page 4] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[4ページ]RFC3877はMIB2004年9月に驚かせます。
3.2. Alarm Management Architecture
3.2. アラーム管理体系
+------------------------------------------------+
| |
| +------------------------------------+ |
| | Notification Management | |
| +------------------------------------+ |
| | |
+------------------------------------------------+
|
|
|
|<----------------------------------------------+
| |
+------------------V-------------+ |
| +---------------V-----------+ | |
| | RFC 3413 | | |
| | SNMP-NOTIFICATION-MIB | | |
| +--------+--------------+-+-+ | |
| | | | | |
| | | +------------------+ |
| | | | | |
| | | | +----------V--------------+ |
| | | | | +--------V---------+ | |
| +---------V------------+ | | | | Alarm Modelling | | |
| | RFC 3014 | | | | | (descriptions) | | |
| | NOTIFICATION-LOG-MIB | | | | +--------+---------+ | |
| +----------------------+ | | | | | |
| | | | +--------V------------+ | |
| +------------------------V-+ | | | Generic: Model- | | |
| | RFC 3413 | | | | Active : Specific | | |
| | SNMP-TARGET-MIB | | | | Alarms : Extensions | | |
| +----------+---------------+ | | +--------+------------+ | |
| | | | | | |
+------------|-------------------+ +----------|--------------+ |
| | |
| +------------------+
V
Informs & Traps
+------------------------------------------------+ | | | +------------------------------------+ | | | 通知管理| | | +------------------------------------+ | | | | +------------------------------------------------+ | | | |<----------------------------------------------+ | | +------------------V-------------+ | | +---------------V-----------+ | | | | RFC3413| | | | | SNMP通知MIB| | | | +--------+--------------+-+-+ | | | | | | | | | | | +------------------+ | | | | | | | | | | | +----------V--------------+ | | | | | | +--------V---------+ | | | +---------V------------+ | | | | アラームモデル化| | | | | RFC3014| | | | | (記述) | | | | | 通知ログMIB| | | | +--------+---------+ | | | +----------------------+ | | | | | | | | | | +--------V------------+ | | | +------------------------V-+| | | ジェネリック: モデル| | | | | RFC3413| | | | アクティブ: 特定| | | | | SNMP目標MIB| | | | アラーム: 拡大| | | | +----------+---------------+ | | +--------+------------+ | | | | | | | | | +------------|-------------------+ +----------|--------------+ | | | | | +------------------+ Vは知らせて、捕らえられます。
3.3. Features of this Architecture
3.3. このArchitectureの特徴
3.3.1. Modular Alarm Architecture
3.3.1. モジュールのアラーム構造
The subject of alarm management can potentially cover a large number of topics including real-time alarms, historical alarms, alarm correlation, and alarm suppression, to name a few. Within each of these topics, there are a number of established models that could be
アラーム管理の対象は潜在的にいくつかを命名するためにリアルタイムのアラーム、歴史的なアラーム、アラーム相関関係、およびアラーム抑圧を含む多くの話題をカバーできます。 それぞれのこれらの話題の中に、それが多くの確立したモデルであることができたことがあります。
Chisholm & Romascanu Standards Track [Page 5] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[5ページ]RFC3877はMIB2004年9月に驚かせます。
supported. This memo focuses on a subset of this problem space, but describes a modular SNMP alarm management framework. Alarms SHOULD be modelled so Notifications are sent on alarm Clear.
支持にされる。 このメモは、この問題スペースの部分集合に焦点を合わせますが、モジュールのSNMPアラーム管理枠組みについて説明します。 Notificationsが送られるモデル化されたそうがアラームClearであったならSHOULDを驚かせます。
The framework defines a generic Alarm MIB that can be supported on its own, or with additional alarm modelling information such as the provided ITU Alarm MIB. In addition, the active alarm tables could also be extended to support additional information about active alarm instances. This framework can also be expanded in the future to support such features as alarm correlation and alarm suppression. This modular architecture means that the cost of supporting alarm management features is proportional to the number of features an implementation supports.
枠組みはそれ自身か追加アラームが提供されたITU Alarm MIBなどの情報をモデル化している状態で支持できる一般的なAlarm MIBを定義します。 また、さらに、アクティブなアラーム例に関する追加情報を支持するためにアクティブなアラームテーブルを広げることができました。 また、将来、相関関係とアラーム抑圧を驚かせるような特徴を支持するためにこの枠組みを広げることができます。 このモジュールの構造は、アラーム管理機能を支持する費用が実現が支持する特徴の数に比例していることを意味します。
3.3.2. Flexible Alarm Modelling
3.3.2. フレキシブルなアラームモデル化
Alarm models document an understanding between a manager and an agent as to what problems will be reported on a system, how these problems will be reported, and what might possibly happen over the lifetime of this problem.
どんな問題がシステムに関して報告されるだろうか、そして、これらの問題がどのように報告されるだろうか、そして、何がことによるとこの問題の生涯起こるかもしれないかに関してアラームモデルはマネージャとエージェントの間の理解を記録します。
The alarm modelling method provided in this memo provides flexibility to support implementations with different modelling requirements. All alarms are modelled as a series of states that are related together using an alarm ID. Alarm states can be modelled using traditional Notifications, generic alarm Notifications, or without the use of Notifications.
このメモに提供されたアラームモデル化方法は、異なったモデル化要件で実現を支持するために柔軟性を提供します。 すべてのアラームがアラームIDを使用することで一緒に関係づけられる一連の州としてモデル化されます。 アラーム州が伝統的なNotifications、一般的なアラームNotificationsを使用することでモデル化されるか、Notificationsの使用なしであることができます。
Alarm states modelled using traditional Notifications would specify a Notification Object Identifier, and optionally an (offset, value) pair of one of the Notification varbinds to identify the state. This alarm state would be entered when the entity generated a Notification that matched this information and the alarm would be added to the active alarm table. This Notification would also get sent on the wire to any destinations, as indicated in the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413].
伝統的なNotificationsを使用することでモデル化されたアラーム州は任意にNotification Object Identifierを指定するでしょう。状態を特定するNotification varbindsの1(オフセット、値)組のひとり。 実体がこの情報に合っていたNotificationを発生させたとき、このアラーム状態は入れられるでしょう、そして、アラームはアクティブなアラームテーブルに加えられるでしょう。 また、このNotificationは、SNMP-TARGET-MIBとSNMP-NOTIFICATION-MIB[RFC3413]にみられるようにワイヤに送るようにどんな目的地にも到着させるでしょう。
Alarm states modelled using generic Notifications use the alarmActiveState or alarmClearState Notifications defined in this memo. These alarm states would be entered after being triggered by a stimulus outside the scope of this memo, the alarm would be added to the active alarm table and these generic Notifications would then be sent on the wire to any destinations, as indicated in the SNMP- TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413].
アラーム州は、alarmActiveStateかalarmClearState Notificationsがこのメモで定義した一般的なNotifications使用を使用することでモデル化されました。 このメモの範囲の外での刺激によって引き起こされた後にこれらのアラーム州に入るでしょう、そして、アクティブなアラームテーブルにアラームを加えるでしょう、そして、次に、これらの一般的なNotificationsをどんな目的地へのワイヤにも送るでしょう、SNMP- TARGET-MIBとSNMP-NOTIFICATION-MIB[RFC3413]にみられるように。
Chisholm & Romascanu Standards Track [Page 6] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[6ページ]RFC3877はMIB2004年9月に驚かせます。
Alarm states modelled without any Notifications would be triggered by some stimulus outside the scope of this memo, the alarm would be added to the active alarm table, but no Notifications would be sent to interested managers.
このメモの範囲の外での何らかの刺激で少しもNotificationsなしでモデル化されたアラーム州を引き起こすでしょうが、アクティブなアラームテーブルにアラームを加えるでしょうが、Notificationsを全く関心があるマネージャに送らないでしょう。
3.3.3. Problem Indication
3.3.3. 問題指示
The Alarm MIB provides a means to determine whether a given notification is of interest to managers for purposes of alarm management by permitting inspection of the alarm models. If no entries in the alarmModelTable could match a particular notification, then that notification is not relevant to the alarm models defined. In addition, information in the alarm model, such as the Notification ID and the description tell exactly what error or warning condition this alarm is indicating. If the ITU-ALARM-MIB is also supported, additional information is provided via the probable cause.
Alarm MIBはアラーム管理の目的のためにマネージャにとって、与えられた通知が興味深いかどうかアラームモデルの点検を可能にすることによって決定する手段を提供します。 alarmModelTableでどんなエントリーも特定の通知に合うことができないなら、その通知はモデルが定義したアラームに関連していません。 添加、アラームモデルのNotification IDや記述の情報では、このアラームがどんな誤りか警告状態を示しているかまさに言ってください。 また、ITU-ALARM-MIBを支持するなら、推定原因で追加情報を提供します。
3.3.5. Identifying Resource under Alarm
3.3.5. アラームの下でリソースを特定します。
An important goal of alarm management is to ensure that any detected problems get fixed, so it is necessary to know exactly where this problem is occurring. In addition, it is necessary to be able to tell when alarm instances are raised against the same component, as well as to be able to tell what instance of an alarm is cleared by an instance of an alarm clear.
アラーム管理の重要な目標がどんな検出された問題も修理されているのを保証することであるので、この問題がちょうどどこに起こっているかを知るのが必要です。 さらに、アラーム例がいつ同じコンポーネントに対して提起されるかを言って、アラームのどんな例は例によってアラームをきれいにされるかがクリアされると言うことができるのが必要です。
The Alarm MIB provides a generic method for identifying the resource by extracting and building a resource ID from the Notification varbinds. It records the relevant information needed to locate the source of the alarm.
Alarm MIBはNotification varbindsからリソースIDを抜粋して、築き上げることによってリソースを特定するための一般的方法を提供します。 それはアラームの源の場所を見つけるのに必要である関連情報を記録します。
3.3.6. Means of obtaining ITU alarm information
3.3.6. ITUアラーム情報を得る手段
Alarm Information, as defined in ITU alarm models [M.3100], is optionally available to implementations through the optional support of the ITU-ALARM-MIB.
ITUアラームモデル[M.3100]で定義されるアラーム情報はITU-ALARM-MIBの任意のサポートで実現に任意に利用可能です。
3.3.7. Configuration of Alarm Models
3.3.7. アラームモデルの構成
An alarm model can be added and removed during runtime. It can be modified assuming it is not being referenced by any active alarm instance.
ランタイムの間、アラームモデルを加えて、免職できます。 それがどんなアクティブなアラーム例によっても参照をつけられていないと仮定しながら、それを変更できます。
3.3.8. Active Alarm Management
3.3.8. 活発なアラーム管理
A list of currently active alarms and supporting statistics on the SNMP entity can be obtained.
SNMP実体の現在活性のアラームとサポート統計のリストを得ることができます。
Chisholm & Romascanu Standards Track [Page 7] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[7ページ]RFC3877はMIB2004年9月に驚かせます。
This allows the network management station to find out about any problems that may have occurred before it started managing a particular network element, or while it was out of contact with it.
これで、ネットワークマネージメントステーションは特定のネットワーク要素を管理し始める前かそれとの接触の外にそれがあった間起こっているどんな問題も見つけることができます。
3.3.9. Distributed Alarm Management
3.3.9. 分配されたアラーム管理
All aspects of the Alarm MIB can be supported both on the device experiencing the alarms and on any mid-level managers that might be monitoring such devices.
アラームを経験する装置の上と、そして、そのような装置をモニターしているかもしれないどんな中間レベルのマネージャの上でもAlarm MIBの全面を支持できます。
3.3.10. Historical Alarm Management
3.3.10. 歴史的なアラーム管理
Some systems may have a requirement that information on alarms that are no longer active is available. This memo provides a clear table to support this requirement.
いくつかのシステムには、もう活性でないアラームの情報が利用可能であるという要件があるかもしれません。 このメモは、この要件を支持するために明確なテーブルを提供します。
This can also be achieved through the support of the Notification Log MIB [RFC3014] to store alarm state transitions.
また、アラーム状態遷移を格納するためにNotification Log MIB[RFC3014]のサポートでこれを達成できます。
3.4. Security
3.4. セキュリティ
Given the nature of VACM, security for alarms is awkward since access control for the objects in the underlying Notifications can be checked only where the Notification is created. Thus such checking is possible only for locally generated Notifications, and even then only when security credentials are available.
VACMの自然を考えて、アラームのためのセキュリティは、Notificationが作成されるだけであるところで基本的なNotificationsの物のためのアクセス管理をチェックできるので、まずいです。 したがって、そのような照合は、局所的に発生したNotificationsだけに可能であり、セキュリティー証明書がその時でさえ利用可能であるときにだけ、可能です。
For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC3411] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC3413].
この議論の目的のために、「セキュリティー証明書」は抽象的なサービスインタフェース機能isAccessAllowed[RFC3411]のために入力値を意味して、それらの信任状を使用するのは、それらの信任状が問題のMIB物へのアクセスを許すことを確認するのに概念的にその機能を使用することを意味します、Notification Originatorのように[RFC3413]で作動して。
The Alarm MIB has the notion of a named alarm list. By using alarm list names and view-based access control [RFC3415] a network administrator can provide different access for different users. When an application creates an alarm model (indexed in part by the alarm list name) the security credentials of the creator remain associated with that alarm model and constrain what information is allowed to be placed in the active alarm table, the active alarm variable table, the cleared alarm table, and the ITU alarm table.
Alarm MIBには、命名されたアラームリストの考えがあります。 アラームリスト名と視点ベースのアクセス管理[RFC3415]を使用することによって、ネットワーク管理者は異なったアクセスを異なったユーザに提供できます。 アプリケーションがアラームモデル(アラームリスト名によって一部索引をつけられる)を創造するとき、創造者のセキュリティー証明書は、そのアラームモデルに関連していたままで残っていて、情報が許容されているものがアクティブなアラームテーブル(可変テーブル、クリアされたアラームテーブル、およびITUアラームが見送る活性アラーム)に置かれるのを抑制します。
When processing locally-generated Notifications, the managed system MUST use the security credentials associated with each alarm model respectively, and MUST apply the same access control rules as described for a Notification Originator in [RFC3413].
処理がNotificationsを局所的に発生させたとき、管理されたシステムは、それぞれそれぞれのアラームモデルに関連しているセキュリティー証明書を使用しなければならなくて、[RFC3413]のNotification Originatorのために説明されるのと同じアクセス制御規則を当てはまらなければなりません。
Chisholm & Romascanu Standards Track [Page 8] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[8ページ]RFC3877はMIB2004年9月に驚かせます。
The managed system SHOULD NOT apply access control when processing remotely-generated Notifications using the alarm models. In those cases the security of the information in the alarm tables SHOULD be left to the normal, overall access control for those tables.
処理がアラームモデルを使用することでNotificationsを離れて発生させたとき、管理されたシステムSHOULD NOTはアクセス管理を適用します。 それらの場合では、アラームにおける、情報のセキュリティは正常で、総合的なアクセスへの左がそれらのテーブルのための制御装置であったならSHOULDをテーブルの上に置きます。
3.5. Relationship between Alarm and Notifications
3.5. アラームと通知との関係
It is important to understand the relationship between alarms and Notifications, as both are traditional fault management methods. This relationship is modelled using the alarmModelTable to define the alarmModelNotificationId for each alarm state.
アラームとNotificationsとの関係を理解しているのは、両方が伝統的な障害管理方法であるので、重要です。 この関係は、それぞれのアラーム状態とalarmModelNotificationIdを定義するのにalarmModelTableを使用することでモデル化されます。
Not all Notifications signal an alarm state transition. Some Notifications are simply informational in nature, such as those that indicate that a configuration operation has been performed on an entity. These sorts of Notifications would not be represented in the Alarm MIB.
すべてのNotificationsがアラーム状態遷移に合図するというわけではありません。 いくつかのNotificationsが単に現実に情報です、構成操作が実体に実行されたのを示すものなどのように。 Notificationsのこれらの種類はAlarm MIBに表されないでしょう。
The Alarm MIB allows the use of the Notification space as defined in [RFC2578] in order to identify the Notifications that are related with the specific alarm state transitions. However there is no assumption that the respective Notifications must be sent for all or any of the alarm state transitions. It is also possible to model alarms using no Notifications at all. This architecture allows for both the efficient exploitation of the body of defined Notification and for the use of non-Notification based systems.
Alarm MIBは特定のアラーム状態遷移に関連づけられるNotificationsを特定するために[RFC2578]で定義されるようにNotificationスペースの使用を許します。 しかしながら、アラーム状態遷移のすべてかどれかのためにそれぞれのNotificationsを送らなければならないという仮定が全くありません。 また、Notificationsを全く使用しないアラームをモデル化するのも可能です。 この構造は両方のためにNotificationと非通知のベースのシステムの使用のために定義されることのボディーの効率的な開発を許します。
3.6. Notification Varbind Storage and Reference
3.6. 通知Varbind格納と参照
In SNMPv1 [RFC1157], the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined [RFC1215]. In the case of linkDown trap, the first varbind can unambiguously be identified as ifIndex. With the introduction of the InformRequest-PDU and SNMPv2-Trap-PDU types, which send sysUptime and snmpTrapOID as the first two varbinds, while the SMI in the MIB where the Notification is defined only lists additional varbinds, the meaning of "first varbind" becomes less clear. In the case of the linkDown Notification, referring to the first varbind could potentially be interpreted as either the sysUptime or ifIndex.
SNMPv1[RFC1157]では、Trap-PDUのvarbindsは1〜1にそれが定義されたMIB[RFC1215]の罠のSMIに記載されたそれらのvarbindsにワイヤ地図を移動しました。 linkDown罠の場合では、ifIndexとして明白に最初のvarbindを特定できます。 Notificationが定義されるMIBのSMIが追加varbindsを記載するだけである間のInformRequest-PDUとSNMPv2罠PDUタイプの導入によると、「最初に、varbind」の意味は、より明確でなくなります。(タイプは最初の2varbindsとしてsysUptimeとsnmpTrapOIDを送ります)。 linkDown Notificationの場合では、sysUptimeかifIndexのどちらかとして潜在的に最初のvarbindについて言及するのを解釈できました。
The varbind storage approach taken in the Alarm MIB is that sysUptime and snmpTrapOID SHALL always be stored in the active alarm variable table as entry 1 and 2 respectively, regardless of whether the transport was the Trap-PDU, the InformRequest-PDU or the SNMPv2- Trap-PDU. If the incoming Notification is an SNMPv1 Trap-PDU then an appropriate value for sysUpTime.0 or snmpTrapOID.0 shall be determined by using the rules in section 3.1 of [RFC3584].
Alarm MIBで取られたvarbind格納アプローチはsysUptimeとsnmpTrapOID SHALLがエントリー1と2としてアクティブなアラーム可変テーブルにそれぞれいつも格納されるということです、輸送がTrap-PDU、InformRequest-PDUまたはSNMPv2罠-PDUであったことにかかわらず。 入って来るNotificationがSNMPv1 Trap-PDUであるなら、sysUpTime.0かsnmpTrapOID.0のための適切な値は、[RFC3584]のセクション3.1で規則を使用することによって、決定するものとします。
Chisholm & Romascanu Standards Track [Page 9] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[9ページ]RFC3877はMIB2004年9月に驚かせます。
The varbind reference approach taken in the Alarm MIB is that, for variables such as the alarmModelVarbindIndex, the first two obligatory varbinds of the InformRequest-PDU and SNMPv2-Trap-PDU need to be considered so the index values of the Trap-PDU and the SMI need be adjusted by two. In the case of linkDown, the third varbind would always be ifIndex.
Alarm MIBで取られたvarbind参照アプローチはそれです、alarmModelVarbindIndex、InformRequest-PDUとSNMPv2罠PDUの義務的なvarbindsがTrap-PDUとSMIのインデックス値が2時までに調整されなければならないために考えられる必要がある最初の2つのなどものの変数のために。 linkDownの場合では、いつも3番目のvarbindはifIndexでしょう。
3.7. Relation to Notification Log MIB
3.7. 通知ログMIBとの関係
The Alarm MIB is intended to complement the Notification Log MIB [RFC3014], but can be used independently. The alarmActiveTable is defined in manner similar to that of the nlmLogTable. This format allows for the storage of any Trap or Notification type that can be defined using the SMI, or can be carried by SNMP. Using the same format as the Notification Log MIB also simplifies operations for systems choosing to implement both MIBs.
Alarm MIBをNotification Log MIB[RFC3014]の補足となることを意図しますが、独自に使用できます。 alarmActiveTableはnlmLogTableのものと同様の方法で定義されます。 この形式はSMIを使用することで定義できるか、またはSNMPが運ぶことができるどんなTrapやNotificationタイプの格納も考慮します。 また、Notification Log MIBと同じ形式を使用すると、両方のMIBsを実行するのを選ぶシステムのための操作は簡略化します。
The object alarmActiveLogPointer points, for each entry in the alarmActiveLogTable, to the log index in the Notification Log MIB, if used.
物のalarmActiveLogPointerは指します、alarmActiveLogTableの各エントリーに、Notification Log MIBのログインデックスに、使用されるなら。
If the Notification Log MIB is supported, it can be monitored by a management system as a hedge against lost alarms. The Notification Log can also be used to support historical alarm management.
Notification Log MIBが支持されるなら、マネージメントシステムは生垣として無くなっているアラームに対してそれをモニターできます。また、歴史的なアラーム管理を支持するのにNotification Logを使用できます。
3.8. Relationship with the Event MIB
3.8. イベントMIBとの関係
During the work and discussions in the Working Group, the issue of the relationship between the MIB modules and the Event MIB [RFC2981] was raised. There is no direct relation or dependency between the Alarm MIB and the Event MIB. Some common terms (like 'event') are being used in both MIB modules, and the user is directed to the sections that define terminology in the two documents for clarification.
作業部会における仕事と議論の間、MIBモジュールの間の関係の問題とEvent MIB[RFC2981]は上げられました。 Alarm MIBとEvent MIBの間には、どんなダイレクト関係も依存もありません。 いくつかの一般的な用語('出来事'のような)が両方のMIBモジュールで使用されています、そして、ユーザは明確化のための2通のドキュメントで用語を定義するセクションに向けられます。
4. Generic Alarm MIB
4. 一般的なアラームMIB
4.1. Overview
4.1. 概観
The ALARM-MIB consists of alarm models and lists of active and cleared alarms.
ALARM-MIBはアクティブでクリアされたアラームのアラームモデルとリストから成ります。
The alarmModelTable contains information that is applicable to all instances of an alarm. It can be populated at start-up with all alarms that could happen on a system or later configured by a management application. It contains all the alarms for a given system. If a Notification is not represented in the alarmModelTable, it is not an alarm state transition. The alarmModelTable provides a
alarmModelTableはアラームのすべての例に適切な情報を含んでいます。 それを上にから始まるところでシステムの上で起こることができたすべてのアラームで居住するか、または後で管理アプリケーションで構成できます。 それは与えられたシステムのためのすべてのアラームを含んでいます。 NotificationがalarmModelTableに表されないなら、それはアラーム状態遷移ではありません。 alarmModelTableはaを提供します。
Chisholm & Romascanu Standards Track [Page 10] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[10ページ]RFC3877はMIB2004年9月に驚かせます。
means of defining the raise/clear and other state transition relationships between alarm states. The alarmModelIndex acts as a unique identifier for an alarm. An alarm model consists of definitions of the possible states an alarm can assume as well as the Object Identifier (OID) of the Notification associated with this alarm state. The object alarmModelState defines the states of an alarm.
アラーム州の間の昇給/明確で他の状態遷移関係を定義する手段。 alarmModelIndexはアラームのためのユニークな識別子として機能します。 アラームモデルはアラームがこのアラーム状態に関連しているNotificationのObject Identifier(OID)と同様に仮定できる可能な州の定義から成ります。 物のalarmModelStateはアラームの州を定義します。
The alarmActiveTable contains a list of alarms that are currently occurring on a system. It is intended that this table be queried upon device discovery and rediscovery to determine which alarms are currently active on the device.
alarmActiveTableは現在システムの上に現れているアラームのリストを含んでいます。 このテーブルが装置発見と再発見のときにどのアラームが現在装置で活性であるかを決定するために質問されることを意図します。
The alarmActiveVariableTable contains the Notification variable bindings associated with the alarms in the alarmActiveTable.
alarmActiveVariableTableはalarmActiveTableのアラームに関連しているNotification変項束縛を含んでいます。
The alarmActiveStatsTable contains current and total raised alarm counts as well as the time of the last alarm raise and alarm clears per named alarm list.
alarmActiveStatsTableは最後のアラームの時間と同様にカウントが上げる現在の、そして、総高くしているアラームを含んでいます、そして、アラームは命名されたアラームリスト単位できれいにされます。
The alarmClearTable contains recently cleared alarms. It contains up to alarmClearMaximum cleared alarms.
alarmClearTableは最近クリアされたアラームを含んでいます。それはクリアされたアラームをalarmClearMaximumまで含んでいます。
The MIB also defines generic alarm Notifications that can be used when there is not an existing applicable Notification to signal the alarm state transition - alarmActiveState and alarmClearState.
また、MIBはアラーム状態遷移に合図するために既存の適切なNotificationがないとき使用できる一般的なアラームNotificationsを定義します--alarmActiveStateとalarmClearState。
4.1.1. Extensibility
4.1.1. 伸展性
The relationship between the Alarm MIB and the other alarm model MIB modules is expressed by the following: The alarmModelTable has a corresponding table in the specific MIB. For each row in the specific MIB alarm model table there is one row in the alarmModelTable. The alarmActiveTable has a corresponding table in the specific MIBs. For each row in the specific MIB active alarm table, there is one row in the alarmActiveTable. The alarmModelSpecificPointer object in the alarmModelTable points to the specific model entry in an extended alarm model table corresponding to this particular alarm. The alarmActiveSpecificPointer object in the alarmActiveTable points to the specific active alarm entry in an extended active alarm table corresponding to this particular alarm instance.
Alarm MIBと他のアラームモデルMIBモジュールとの関係は以下によって言い表されます: alarmModelTableは特定のMIBに対応するテーブルを持っています。 特定のMIBアラームモデルテーブルの各列には、1つの列がalarmModelTableにあります。 alarmActiveTableは特定のMIBsに対応するテーブルを持っています。 特定のMIBアクティブなアラームテーブルの各列には、1つの列がalarmActiveTableにあります。 alarmModelTableのalarmModelSpecificPointer物はこの特定のアラームに対応する拡張アラームモデルテーブルに特定のモデルエントリーを示します。 alarmActiveTableのalarmActiveSpecificPointer物はこの特定のアラーム例に対応する拡張アクティブなアラームテーブルに特定の活発なアラームエントリーを示します。
Additional extensions can be defined by defining an AUGMENTATION of either the Alarm or ITU Alarm tables. As the alarm model table only provides a mechanism to point at one specific alarm model, additional specific models SHOULD define another mechanism to map from the generic alarm model to the additional model.
AlarmかITU Alarmがテーブルの上に置くどちらかのAUGMENTATIONを定義することによって、追加拡大を定義できます。 アラームモデルテーブルが1つの特定のアラームモデルを指し示すためにメカニズムを提供するだけであるとき、SHOULDが一般的なアラームから写像するために別のメカニズムを定義する追加特定のモデルは追加モデルにモデル化します。
Chisholm & Romascanu Standards Track [Page 11] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[11ページ]RFC3877はMIB2004年9月に驚かせます。
4.1.2. Problem Indication
4.1.2. 問題指示
The problem that each alarm indicates is identified through the Object Identifier of the NotificationId of the state transition, and, optionally, the ITU parameters. alarmModelDescription provides a description of the alarm state suitable for displaying to an operator.
各アラームが示す問題は状態遷移のNotificationIdのObject Identifier、および任意にITUパラメタを通して特定されます。alarmModelDescriptionはオペレータに表示するのに適当なアラーム状態の記述を提供します。
4.1.3. Alarm State Transition Notification
4.1.3. アラーム状態遷移通知
The SNMP-TARGET-MIB [RFC3413] provides the ability to specify which
managers, if any, receive Notifications of problems. Solutions can
therefore use the features of this MIB to change the Notification
behaviour of their implementations. Specifying target hosts in this
MIB along with specifying notifications in the
alarmModelNotificationId would allow Notifications to be logged and
sent out to management stations in an architecture as described in
section 3.2. Specifying no target hosts in this MIB along with
specifying notifications in the alarmModelNotificationId would allow
Notifications to be logged but not sent out to management stations in
an architecture as described in section 3.2. Regardless of what is
defined in the SNMP-TARGET-MIB, specifying { 0 0 } in the
alarmModelNotificationId would result in no notifications being
logged or sent to management stations as a consequence of this
particular alarm state transition.
問題のNotificationsは、SNMP-TARGET-MIB[RFC3413]はどのマネージャを指定するか能力を提供します、もしあれば受け取ります。したがって、ソリューションはこのMIBが彼らの実現のNotificationのふるまいを変える特徴を使用できます。 alarmModelNotificationIdの通知を指定すると共にこのMIBで目標ホストを指定するのは、セクション3.2で説明されるようにNotificationsが構造で管理局に登録されて、出されるのを許容するでしょう。 alarmModelNotificationIdの通知を指定すると共にこのMIBで目標ホストを全く指定しないのは、セクション3.2で説明されるようにNotificationsが登録されますが、構造では管理局に出されないのを許容するでしょう。 SNMP-TARGET-MIBで定義されることにかかわらず、alarmModelNotificationIdで0 0を指定すると、この特定のアラーム状態遷移の結果として管理局に登録されるか、または送られない通知は全くもたらされるでしょう。
Alarms are modelled by defining all possible states in the alarmModelTable, as well as defining alarmModelNotificationId, alarmModelVarbindIndex, and alarmModelVarbindValue for each of the possible alarm states. Optionally, ituAlarmPerceivedSeverity models the states in terms of ITU perceived severity.
アラームはalarmModelTableのすべての可能な州を定義することによって、モデル化されます、それぞれの可能なアラーム州へのalarmModelNotificationIdを定義する、alarmModelVarbindIndex、およびalarmModelVarbindValueと同様に。 任意に、ituAlarmPerceivedSeverityは厳しさであると知覚されたITUに関して州をモデル化します。
4.1.4. Active Alarm Resource Identifier
4.1.4. アクティブなアラームリソース識別子
Resources under alarm can be identified using the alarmActiveResourceId. This OBJECT IDENTIFIER points to an appropriate object to identify the given resource, depending on the type of the resource.
alarmActiveResourceIdを使用することでアラームの下におけるリソースを特定できます。 リソースのタイプに頼っていて、このOBJECT IDENTIFIERは、与えられたリソースを特定するために適切な物を示します。
The consumer of the alarmActiveResourceId does not necessarily need to know the type of the resource in the resource ID, but if they want to know this, examining the content of the resource ID can derive it - 1.3.6.1.2.1.2.2.1.1.something is an interface, for example. It is therefore good practice to use resource IDs that can be consistently used across technologies, such as ifIndex, entPhysicalIndex or sysApplRunIndex, to minimize the number of resource prefixes a manager interested in a resource type needs to learn.
彼らがこれを知りたいなら、リソースIDの内容を調べると、それを引き出すことができます--alarmActiveResourceIdの消費者は、必ずリソースIDにおける、リソースのタイプを知る必要があるというわけではありませんが、例えば、1.3.6.1.2.1.2.2.1.1.somethingはインタフェースです。 したがって、技術の向こう側に一貫して使用できるリソースIDを使用するのは、良い習慣です、リソースに興味を持っているマネージャが学ぶのが必要であることをタイプするリソース接頭語の数を最小にするためにifIndex、entPhysicalIndexまたはsysApplRunIndexなどのように。
Chisholm & Romascanu Standards Track [Page 12] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[12ページ]RFC3877はMIB2004年9月に驚かせます。
Resource ID can be calculated using the alarmModelResourcePrefix, alarmModelVarbindSubtree and the Notification varbinds. This allows for both the managed element to be able to compute and populate the alarmActiveResourceId object and for the manager to be able to determine when two separate alarm instances are referring to the same resource.
alarmModelResourcePrefix、alarmModelVarbindSubtree、およびNotification varbindsを使用することでリソースIDについて計算できます。 これは、両方のために管理された要素が、alarmActiveResourceId物を計算して、居住して、マネージャが、2つの個別警報例がいつ同じリソースを示しているかを決定できるのを許容します。
If alarmModelResourcePrefix has a value of 0.0, then alarmActiveResourceId is simply the variable identifier of the first Notification varbind that matches the prefix defined in alarmModelVarbindSubtree. Otherwise, alarmActiveResourceId is calculated by appending the instance information from the first Notification varbind that matches alarmModelVarbindSubtree to the prefix defined in alarmModelResourcePrefix. The instance information is the portion of the variable identifier following the part that matched alarmModelVarbindSubtree. If no match is found, then alarmActiveResourceId is simply the value of alarmModelResourcePrefix.
alarmModelResourcePrefixに0.0の値があるなら、alarmActiveResourceIdは単にalarmModelVarbindSubtreeで定義された接頭語に合っている最初のNotification varbindの変数名です。 さもなければ、alarmActiveResourceIdは、alarmModelVarbindSubtreeに合っている最初のNotification varbindからalarmModelResourcePrefixで定義された接頭語まで例の情報を追加することによって、計算されます。 例の情報はalarmModelVarbindSubtreeに合っていた部分に続く変数名の部分です。 マッチが全く見つけられないなら、alarmActiveResourceIdは単にalarmModelResourcePrefixの値です。
In addition to this, the variable bindings from the Notifications that signal the alarm state transitions are stored in the active alarm variable table. This allows for implementations familiar with the particular Notifications to implement other forms of resource identification.
これに加えて、Notificationsからのそれがアクティブに格納されるとアラーム状態遷移に合図する変項束縛は可変テーブルを驚かせます。 これは、特定のNotificationsに身近な実現が他の形式のリソース識別を実行するのを許容します。
For Example:
例えば:
A) Consider an alarm modelled using the authenticationFailure [RFC3418] Notification.
a) authenticationFailure[RFC3418]通知を使用することでモデル化されたアラームを考えてください。
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"An authenticationFailure trap signifies that the SNMPv2
entity, acting in an agent role, has received a protocol
message that is not properly authenticated. While all
implementations of the SNMPv2 must be capable of generating
this trap, the snmpEnableAuthenTraps object indicates
whether this trap will be generated."
::= { snmpTraps 5 }
authenticationFailure NOTIFICATION-TYPE STATUSの現在の記述、「authenticationFailure罠は、エージェントの役割で行動して、SNMPv2実体が適切に認証されないプロトコルメッセージを受け取ったのを意味します」。 「SNMPv2のすべての実現がこの罠を発生させることができなければなりませんが、snmpEnableAuthenTraps物は、この罠が発生するかどうかを示します。」 ::= snmpTraps5
To set the resource ID to be usmStats, 1.3.6.1.6.3.15.1.1,
configure as follows:
alarmModelVarbindSubtree = 0.0
alarmModelResourcePrefix = usmStats (1.3.6.1.6.3.15.1.1)
リソースIDにusmStatsであるように設定するために構成する、1.3 .6 .1 .6 .3 .15 .1 .1 以下の通り以下を構成してください。 0.0alarmModelVarbindSubtree=alarmModelResourcePrefixはusmStatsと等しいです。(1.3.6.1.6.3.15.1.1)
Chisholm & Romascanu Standards Track [Page 13] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[13ページ]RFC3877はMIB2004年9月に驚かせます。
B) Consider an alarm modelled using linkDown [RFC2863]
B) linkDownを使用することでモデル化されたアラームを考えてください。[RFC2863]
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
""
::= { snmpTraps 3 }
linkDown NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「「:、:、」= snmpTraps3
To set the resource Id to be the ifIndex, configure as follows:
alarmModelVarbindSubtree = ifIndex (1.3.6.1.2.1.2.2.1.1)
alarmModelResourcePrefix = 0.0
リソースIdにifIndexであるように設定するために、以下の通り以下を構成してください。 alarmModelVarbindSubtreeがifIndexと等しい、(1.3.6.1.2.1.2.2.1.1)alarmModelResourcePrefix=0.0
Alternatively, since ifIndex is the first varbind, the following
would also work, but might be less meaningful to a human reader
of the MIB table:
alarmModelVarbindSubtree = 0.0
alarmModelResourcePrefix = 0.0
あるいはまた、ifIndexが最初のvarbindであるので、以下は、また、働いているでしょうが、MIBテーブルの人間の読者には、それほど重要でないかもしれません: 0.0alarmModelVarbindSubtree=alarmModelResourcePrefixは0.0と等しいです。
C) Consider an alarm modelled using the bgpBackwardTransition [RFC1657] Notification.
C) bgpBackwardTransition[RFC1657]通知を使用することでモデル化されたアラームを考えてください。
bgpBackwardTransition NOTIFICATION-TYPE
OBJECTS { bgpPeerLastError,
bgpPeerState }
STATUS current
DESCRIPTION
"The BGPBackwardTransition Event is generated
when the BGP FSM moves from a higher numbered
state to a lower numbered state."
::= { bgpTraps 2 }
bgpBackwardTransition NOTIFICATION-TYPE OBJECTS、bgpPeerLastError、bgpPeerState、STATUSの現在の記述、「BGP FSMが、より高い番号付の状態から下側の番号付の状態まで動くとき、BGPBackwardTransition Eventは発生します」。 ::= bgpTraps2
To set the resource Id to be the bgpPeerRemoteAddr, the index to
the bgpTable, where bgpPeerState resides, configure as follows:
alarmModelVarbindSubtree = bgpPeerState
(1.3.6.1.2.1.15.3.1.2)
alarmModelResourcePrefix = bgpPeerRemoteAddr
(1.3.6.1.2.1.15.3.1.7)
リソースIdにbgpPeerRemoteAddr、bgpPeerStateが住んでいるbgpTableへのインデックスであるように設定するために、以下の通り以下を構成してください。 alarmModelVarbindSubtreeがbgpPeerStateと等しい、(1.3.6.1.2.1.15.3.1.2)alarmModelResourcePrefix=bgpPeerRemoteAddr(1.3.6.1.2.1.15.3.1.7)
4.1.5. Configurable Alarm Models
4.1.5. 構成可能なアラームモデル
The alarm model table SHOULD be initially populated by the system. The objects in alarmModelTable and ituAlarmTable have a MAX-ACCESS of read-create, which allows managers to modify the alarm models to suit their requirements.
システムによって居住されて、初めは、アラームモデルテーブルSHOULDはそうです。 alarmModelTableとituAlarmTableの物にはマックス-ACCESSがある、読書する作成、マネージャが彼らの要件に合うようにアラームモデルを変更できる。
Chisholm & Romascanu Standards Track [Page 14] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[14ページ]RFC3877はMIB2004年9月に驚かせます。
4.1.6. Active Alarm Management
4.1.6. 活発なアラーム管理
Lists of alarms currently active on an SNMP entity are stored in the alarmActiveTable and, optionally, a model specific alarmTable, e.g., the ituAlarmActiveTable.
現在SNMP実体の活性のアラームのリストはalarmActiveTableと任意にモデルの特定のalarmTable(例えば、ituAlarmActiveTable)に格納されます。
4.1.7. Distributed Alarm Management
4.1.7. 分配されたアラーム管理
Distributed alarm management can be achieved by support of the Alarm MIB on both the alarm detection point and on the mid-level manager. This is facilitated by the ability to be able to store different named alarm lists. A mid-level manager could create an alarmListName for each of the devices it manages and therefore store separate lists for each device. In addition, the context and IP addresses of the alarm detection point are stored in the alarmActiveTable.
アラーム検出ポイントと中間レベルのマネージャの上で両方におけるAlarm MIBのサポートで分配されたアラーム管理を達成できます。 これは異なった命名されたアラームリストを格納できる能力によって容易にされます。 中間レベルのマネージャは、それが管理するそれぞれの装置のためにalarmListNameを作成して、したがって、各装置のために別々のリストを格納できました。 さらに、アラーム検出ポイントの文脈とIPアドレスはalarmActiveTableに格納されます。
4.2. Definitions
4.2. 定義
ALARM-MIB DEFINITIONS ::= BEGIN
アラーム-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Unsigned32, Gauge32,
TimeTicks, Counter32, Counter64,
IpAddress, Opaque, mib-2,
zeroDotZero
FROM SNMPv2-SMI -- [RFC2578]
DateAndTime,
RowStatus, RowPointer,
TEXTUAL-CONVENTION
FROM SNMPv2-TC -- [RFC2579]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB -- [RFC3291]
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
ZeroBasedCounter32
FROM RMON2-MIB; -- [RFC2021]
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、Integer32、Unsigned32、Gauge32、TimeTicks、Counter32、Counter64、IpAddress、Opaque mib-2、zeroDotZero FROM SNMPv2-SMI--[RFC2578]DateAndTime、RowStatus RowPointer、TEXTUAL-CONVENTION FROM SNMPv2-TC--[RFC2579]SnmpAdminString FROM SNMP-FRAMEWORK-MIB--[RFC3411]InetAddressType、InetAddress FROM INET-ADDRESS-MIB--[RFC3291]MODULE-COMPLIANCE、OBJECT-GROUP、NOTIFICATION-GROUP FROM SNMPv2-CONF--[RFC2580]ZeroBasedCounter32 FROM RMON2-MIB。 -- [RFC2021]
alarmMIB MODULE-IDENTITY
LAST-UPDATED "200409090000Z" -- September 09, 2004
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"WG EMail: disman@ietf.org
Subscribe: disman-request@ietf.org
http://www.ietf.org/html.charters/disman-charter.html
alarmMIBモジュールアイデンティティ最終更新日の"200409090000Z"--「WGは以下をメールする」という2004年9月9日組織「IETF分散管理作業部会」コンタクトインフォメーション disman@ietf.org は申し込まれます: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html
Chisholm & Romascanu Standards Track [Page 15] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[15ページ]RFC3877はMIB2004年9月に驚かせます。
Chair: Randy Presuhn
randy_presuhn@mindspring.com
議長: ランディPresuhn randy_presuhn@mindspring.com
Editors: Sharon Chisholm
Nortel Networks
PO Box 3511 Station C
Ottawa, Ont. K1Y 4H7
Canada
schishol@nortelnetworks.com
エディターズ: シャロンチスホルムノーテルは私書箱3511駅のCオタワ、Ontをネットワークでつなぎます。 K1Y 4H7カナダ schishol@nortelnetworks.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com"
DESCRIPTION
"The MIB module describes a generic solution
to model alarms and to store the current list
of active alarms.
ダンRomascanu Avaya Atidim技術公園、ビルディング #3 テルアビブ、61131イスラエルTel: +972-3-645-8414 メールしてください: 「MIBモジュールはアラームとアクティブの現在のリストが驚かせる店にモデル化するために一般的な解決策を説明する」" dromasca@avaya.com "記述。
Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC
itself. Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html"
REVISION "200409090000Z" -- September 09, 2004
DESCRIPTION
"Initial version, published as RFC 3877."
::= { mib-2 118 }
Copyright(C)インターネット協会(2004)。 このMIBモジュールの初期のバージョンはRFC3877で発行されました。 完全な法定の通知に関しては、RFC自身を見てください。 補助情報は以下で利用可能であるかもしれません。 " http://www.ietf.org/copyrights/ianamib.html "REVISION"200409090000Z"--「初期のバージョンであって、RFC3877として発行された」2004年9月9日記述。 ::= mib-2 118
alarmObjects OBJECT IDENTIFIER ::= { alarmMIB 1 }
alarmObjects物の識別子:、:= alarmMIB1
alarmNotifications OBJECT IDENTIFIER ::= { alarmMIB 0 }
alarmNotifications物の識別子:、:= alarmMIB0
alarmModel OBJECT IDENTIFIER ::= { alarmObjects 1 }
alarmModel物の識別子:、:= alarmObjects1
alarmActive OBJECT IDENTIFIER ::= { alarmObjects 2 }
alarmActive物の識別子:、:= alarmObjects2
alarmClear OBJECT IDENTIFIER ::= { alarmObjects 3 }
alarmClear物の識別子:、:= alarmObjects3
-- Textual Conventions
-- 原文のコンベンション
-- ResourceId is intended to be a general textual convention -- that can be used outside of the set of MIBs related to -- Alarm Management.
-- ResourceIdは一般的な原文のコンベンション(関連するMIBsのセットの外で使用できる)であることを意図します--アラームManagement。
Chisholm & Romascanu Standards Track [Page 16] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[16ページ]RFC3877はMIB2004年9月に驚かせます。
ResourceId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for this resource.
ResourceId:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このリソースのためのユニークな識別子。」
The type of the resource can be determined by looking
at the OID that describes the resource.
リソースのタイプは、リソースについて説明するOIDを見ることによって、決定できます。
Resources must be identified in a consistent manner.
For example, if this resource is an interface, this
object MUST point to an ifIndex and if this resource
is a physical entity [RFC2737], then this MUST point
to an entPhysicalDescr, given that entPhysicalIndex
is not accessible. In general, the value is the
name of the instance of the first accessible columnar
object in the conceptual row of a table that is
meaningful for this resource type, which SHOULD
be defined in an IETF standard MIB."
SYNTAX OBJECT IDENTIFIER
一貫した方法でリソースを特定しなければなりません。 例えば、この物はこのリソースがインタフェースであるなら、ifIndexを示さなければなりません、そして、これはこのリソースが物理的実体[RFC2737]であるならentPhysicalDescrを示さなければなりません、entPhysicalIndexがアクセスしやすくないなら。 「一般に、値はこのリソースタイプに、重要なテーブルの概念的な列における最初のアクセスしやすい円柱状の物の例の名前であり、どのSHOULDがIETFの標準のMIBで定義されるか」? 構文物の識別子
-- LocalSnmpEngineOrZeroLenStr is intended to be a general -- textual convention that can be used outside of the set of -- MIBs related to Alarm Management.
-- セットの外で使用されて、LocalSnmpEngineOrZeroLenStrがaがそれのように一般--原文のコンベンションであるかもしれないなら意図する、--MIBsはAlarm Managementに関連しました。
LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An SNMP Engine ID or a zero-length string. The
instantiation of this textual convention will provide
guidance on when this will be an SNMP Engine ID and
when it will be a zero lengths string"
SYNTAX OCTET STRING (SIZE(0 | 5..32))
LocalSnmpEngineOrZeroLenStr:、:= 「SNMP Engine IDかゼロ・レングスが結ぶ」TEXTUAL-CONVENTION STATUSの現在の記述。 「この原文のコンベンションの具体化はこれがいつSNMP Engine IDになるだろうか、そして、いつゼロ・レングスストリングになるかときの指導を提供する」SYNTAX OCTET STRING(サイズ(0| 5 .32))
-- Alarm Model
-- アラームモデル
alarmModelLastChanged OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation, deletion or modification of an entry in
the alarmModelTable.
alarmModelLastChanged OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「alarmModelTableでのエントリーの最後の創造時点のsysUpTimeの値、削除または変更。」
If the number and content of entries has been unchanged
since the last re-initialization of the local network
management subsystem, then the value of this object
MUST be zero."
「企業内情報通信網管理サブシステムの最後の再初期化以来エントリーの数と内容が変わりがないなら、この物の値はゼロでなければなりません。」
Chisholm & Romascanu Standards Track [Page 17] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[17ページ]RFC3877はMIB2004年9月に驚かせます。
::= { alarmModel 1 }
::= alarmModel1
alarmModelTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmModelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of information about possible alarms on the system,
and how they have been modelled."
::= { alarmModel 2 }
「システムと、彼らがどうモデル化されたかに関して可能の情報のテーブルは驚かせる」alarmModelTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmModelEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= alarmModel2
alarmModelEntry OBJECT-TYPE
SYNTAX AlarmModelEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table for each possible alarm state.
This table MUST be persistent across system reboots."
INDEX { alarmListName, alarmModelIndex, alarmModelState }
::= { alarmModelTable 1 }
「エントリーはこのテーブルでそれぞれの可能なアラーム状態に見える」alarmModelEntry OBJECT-TYPE SYNTAX AlarmModelEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「このテーブルはシステムリブートの向こう側にしつこいに違いありません。」 alarmListName、alarmModelIndex、alarmModelStateに索引をつけてください:、:= alarmModelTable1
AlarmModelEntry ::= SEQUENCE {
alarmModelIndex Unsigned32,
alarmModelState Unsigned32,
alarmModelNotificationId OBJECT IDENTIFIER,
alarmModelVarbindIndex Unsigned32,
alarmModelVarbindValue Integer32,
alarmModelDescription SnmpAdminString,
alarmModelSpecificPointer RowPointer,
alarmModelVarbindSubtree OBJECT IDENTIFIER,
alarmModelResourcePrefix OBJECT IDENTIFIER,
alarmModelRowStatus RowStatus
}
AlarmModelEntry:、:= 系列alarmModelIndex Unsigned32、alarmModelState Unsigned32、alarmModelNotificationId物の識別子、alarmModelVarbindIndex Unsigned32、alarmModelVarbindValue Integer32、alarmModelDescription SnmpAdminString、alarmModelSpecificPointer RowPointer、alarmModelVarbindSubtree物の識別子、alarmModelResourcePrefix物の識別子、alarmModelRowStatus RowStatus
alarmModelIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An integer that acts as an alarm Id
to uniquely identify each alarm
within the named alarm list. "
::= { alarmModelEntry 1 }
alarmModelIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「唯一命名されたアラームリストの中の各アラームを特定するためにアラームIdとして機能する整数。」 " ::= alarmModelEntry1
alarmModelState OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current
alarmModelState OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS海流
Chisholm & Romascanu Standards Track [Page 18] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[18ページ]RFC3877はMIB2004年9月に驚かせます。
DESCRIPTION
"A value of 1 MUST indicate a clear alarm state.
The value of this object MUST be less than the
alarmModelState of more severe alarm states for
this alarm. The value of this object MUST be more
than the alarmModelState of less severe alarm states
for this alarm."
::= { alarmModelEntry 2 }
記述、「1の値は明確なアラーム状態を示さなければなりません」。 このアラームには、この物の値は、より厳しいアラーム州のalarmModelStateより少ないに違いありません。 「このアラームには、この物の値はそれほど厳しくないアラーム州のalarmModelStateより多いに違いありません。」 ::= alarmModelEntry2
alarmModelNotificationId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of this alarm
state transition. If there is no notification associated
with this alarm state, the value of this object MUST be
'0.0'"
DEFVAL { zeroDotZero }
::= { alarmModelEntry 3 }
alarmModelNotificationId OBJECT-TYPE SYNTAX OBJECT IDENTIFIERマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このアラーム状態遷移に関するNOTIFICATION-TYPE物の識別子。」 「」 '0.0'がDEFVAL zeroDotZeroであり、このアラーム状態に関連しているどんな通知もなければ、この物の値はなければなりません:、:= alarmModelEntry3
alarmModelVarbindIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The index into the varbind listing of the notification
indicated by alarmModelNotificationId which helps
signal that the given alarm has changed state.
If there is no applicable varbind, the value of this
object MUST be zero.
alarmModelVarbindIndex OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSは「通知のvarbindリストへのインデックスは当然のことのアラームが状態を変えたと合図するのを助けるalarmModelNotificationIdで示した」STATUSの現在の記述を読書して作成します。 どんな適切なvarbindもなければ、この物の値はゼロでなければなりません。
Note that the value of alarmModelVarbindIndex acknowledges
the existence of the first two obligatory varbinds in
the InformRequest-PDU and SNMPv2-Trap-PDU (sysUpTime.0
and snmpTrapOID.0). That is, a value of 2 refers to
the snmpTrapOID.0.
alarmModelVarbindIndexの値がInformRequest-PDUとSNMPv2罠PDU(sysUpTime.0とsnmpTrapOID.0)の最初の2の義務的なvarbindsの存在を承認することに注意してください。 すなわち、2の値はsnmpTrapOID.0について言及します。
If the incoming notification is instead an SNMPv1 Trap-PDU,
then an appropriate value for sysUpTime.0 or snmpTrapOID.0
shall be determined by using the rules in section 3.1 of
[RFC3584]"
DEFVAL { 0 }
::= { alarmModelEntry 4 }
「入って来る通知が代わりにSNMPv1 Trap-PDUであるなら、sysUpTime.0かsnmpTrapOID.0のための適切な値は[RFC3584]のセクション3.1で規則を使用することによって、決定するものとする」DEFVAL0:、:= alarmModelEntry4
alarmModelVarbindValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create
alarmModelVarbindValue OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは読書して作成します。
Chisholm & Romascanu Standards Track [Page 19] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[19ページ]RFC3877はMIB2004年9月に驚かせます。
STATUS current
DESCRIPTION
"The value that the varbind indicated by
alarmModelVarbindIndex takes to indicate
that the alarm has entered this state.
STATUSの現在の記述、「varbindがalarmModelVarbindIndexで示した値はアラームがこの状態に入ったのを示すために取ります」。
If alarmModelVarbindIndex has a value of 0, so
MUST alarmModelVarbindValue.
"
DEFVAL { 0 }
::= { alarmModelEntry 5 }
alarmModelVarbindIndexに0の値があるなら、alarmModelVarbindValueもそうしなければなりません。 「DEFVAL0:、:、」= alarmModelEntry5
alarmModelDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A brief description of this alarm and state suitable
to display to operators."
DEFVAL { "" }
::= { alarmModelEntry 6 }
alarmModelDescription OBJECT-TYPE SYNTAX SnmpAdminStringマックス-ACCESSは「Aはオペレータに表示するために適当なこのアラームと状態の記述に事情を知らせる」STATUSの現在の記述を読書して作成します。 DEFVAL、「「:、:、」= alarmModelEntry6
alarmModelSpecificPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If no additional, model-specific Alarm MIB is supported by
the system the value of this object is `0.0'and attempts
to set it to any other value MUST be rejected appropriately.
alarmModelSpecificPointer OBJECT-TYPE SYNTAX RowPointerマックス-ACCESSはSTATUSの現在の記述「どんな追加していて、モデル特有のAlarm MIBも支持されないなら、システムで、この物の値はそうです'0.0を読書して作成します、そして、'適切にいかなる他の値にもそれを設定する試みを拒絶しなければなりません」。
When a model-specific Alarm MIB is supported, this object
MUST refer to the first accessible object in a corresponding
row of the model definition in one of these model-specific
MIB and attempts to set this object to { 0 0 } or any other
value MUST be rejected appropriately."
DEFVAL { zeroDotZero }
::= { alarmModelEntry 7 }
「モデル特有のAlarm MIBが支持されるとき、この物がこの物を0 0に設定するこれらのモデル特有のMIBと試みの1つとのモデル定義の対応する列における最初のアクセスしやすい物を示さなければなりませんか、または適切にいかなる他の値も拒絶しなければなりません。」 DEFVAL zeroDotZero:、:= alarmModelEntry7
alarmModelVarbindSubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The name portion of each VarBind in the notification,
in order, is compared to the value of this object.
If the name is equal to or a subtree of the value
of this object, for purposes of computing the value
alarmModelVarbindSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIERマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「通知におけるそれぞれのVarBindの整然としている名前部分はこの物の値にたとえられます」。 名前が等しくて、値を計算する目的のためのこの物の値の下位木であるなら
Chisholm & Romascanu Standards Track [Page 20] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[20ページ]RFC3877はMIB2004年9月に驚かせます。
of AlarmActiveResourceID the 'prefix' will be the
matching portion, and the 'indexes' will be any
remainder. The examination of varbinds ends with
the first match. If the value of this object is 0.0,
then the first varbind, or in the case of v2, the
first varbind after the timestamp and the trap
OID, will always be matched.
"
DEFVAL { zeroDotZero }
::= { alarmModelEntry 8 }
AlarmActiveResourceIDでは、'接頭語'は合っている部分になるでしょう、そして、'インデックス'はどんな残りにもなるでしょう。 varbindsの試験は初戦で終わります。 この物の値が0.0、当時最初のvarbindですかそれともv2の場合でそうであるか、そして、タイムスタンプの後の最初のvarbindと罠OIDはいつも合わせられるでしょう。 「DEFVAL zeroDotZero:、:、」= alarmModelEntry8
alarmModelResourcePrefix OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of AlarmActiveResourceId is computed
by appending any indexes extracted in accordance
with the description of alarmModelVarbindSubtree
onto the value of this object. If this object's
value is 0.0, then the 'prefix' extracted is used
instead.
"
DEFVAL { zeroDotZero }
::= { alarmModelEntry 9 }
alarmModelResourcePrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIERマックス-ACCESSは「AlarmActiveResourceIdの値はこの物の値へのalarmModelVarbindSubtreeの記述によると、抜粋されたどんなインデックスも追加しながら、計算される」STATUSの現在の記述を読書して作成します。 この物の値が0.0であるなら、抽出された'接頭語'は代わりに使用されます。 「DEFVAL zeroDotZero:、:、」= alarmModelEntry9
alarmModelRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Control for creating and deleting entries. Entries may be
modified while active. Alarms whose alarmModelRowStatus is
not active will not appear in either the alarmActiveTable
or the alarmClearTable. Setting this object to notInService
cannot be used as an alarm suppression mechanism. Entries
that are notInService will disappear as described in RFC2579.
alarmModelRowStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは現在の記述が「エントリーを作成して、削除するために制御する」STATUSを読書して作成します。 エントリーはアクティブである間、変更されるかもしれません。 alarmModelRowStatusがアクティブでないアラームはalarmActiveTableかalarmClearTableのどちらかに現れないでしょう。 アラーム抑圧メカニズムとしてこの物をnotInServiceに設定するのを使用できません。 notInServiceであるエントリーはRFC2579で説明されるように見えなくなるでしょう。
This row can not be modified while it is being
referenced by a value of alarmActiveModelPointer. In these
cases, an error of `inconsistentValue' will be returned to
the manager.
それがalarmActiveModelPointerの値によって参照をつけられている間、この列を変更できません。 これらの場合では、'inconsistentValue'の誤りはマネージャに返されるでしょう。
This entry may be deleted while it is being
referenced by a value of alarmActiveModelPointer. This results
in the deletion of this entry and entries in the active alarms
referencing this entry via an alarmActiveModelPointer.
それがalarmActiveModelPointerの値によって参照をつけられている間、このエントリーは削除されるかもしれません。 これは、alarmActiveModelPointerを通してこのエントリーに参照をつけながら、活性アラームでこのエントリーとエントリーの削除をもたらします。
Chisholm & Romascanu Standards Track [Page 21] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[21ページ]RFC3877はMIB2004年9月に驚かせます。
As all read-create objects in this table have a DEFVAL clause,
there is no requirement that any object be explicitly set
before this row can become active. Note that a row consisting
only of default values is not very meaningful."
::= { alarmModelEntry 10 }
すべてがこのテーブルの物を読書して作成するように、DEFVAL節を持ってください、そして、この列がアクティブになることができる前にどんな物も明らかに設定されるという要件が全くありません。 「デフォルト値だけから成る列がそれほど重要でないことに注意してください。」 ::= alarmModelEntry10
-- Active Alarm Table --
-- アクティブなアラームテーブル--
alarmActiveLastChanged OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation or deletion of an entry in the alarmActiveTable.
If the number of entries has been unchanged since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActive 1 }
alarmActiveLastChanged OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「最後の創造時点のsysUpTimeの値かalarmActiveTableでのエントリーの削除。」 「企業内情報通信網管理サブシステムの最後の再初期化以来エントリーの数が変わりがないなら、この物はaゼロ値を含んでいます。」 ::= alarmActive1
alarmActiveOverflow OBJECT-TYPE
SYNTAX Counter32
UNITS "active alarms"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of active alarms that have not been put into
the alarmActiveTable since system restart as a result
of extreme resource constraints."
::= { alarmActive 5 }
能動態は」 マックス-ACCESSの書き込み禁止のSTATUSの現在の記述を驚かせます。alarmActiveOverflow OBJECT-TYPE SYNTAX Counter32 UNITS、「「システムリスタート以来極端なリソース規制の結果、alarmActiveTableに入れられていない活性アラームの数。」 ::= alarmActive5
alarmActiveTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of Active Alarms entries."
::= { alarmActive 2 }
alarmActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmActiveEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Active Alarmsエントリーのテーブル。」 ::= alarmActive2
alarmActiveEntry OBJECT-TYPE
SYNTAX AlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table when alarms are raised. They
are removed when the alarm is cleared.
「アラームが高くしているときエントリーはこのテーブルに現れる」alarmActiveEntry OBJECT-TYPE SYNTAX AlarmActiveEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 アラームをきれいにするとき、それらを取り除きます。
If under extreme resource constraint the system is unable to
極端なリソース規制で下システムであることができない
Chisholm & Romascanu Standards Track [Page 22] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[22ページ]RFC3877はMIB2004年9月に驚かせます。
add any more entries into this table, then the
alarmActiveOverflow statistic will be increased by one."
INDEX { alarmListName, alarmActiveDateAndTime,
alarmActiveIndex }
::= { alarmActiveTable 1 }
「このテーブルにそれ以上のエントリーを加えてください、そして、次に、alarmActiveOverflow統計値は1つ増加するでしょう。」 alarmListName、alarmActiveDateAndTime、alarmActiveIndexに索引をつけてください:、:= alarmActiveTable1
AlarmActiveEntry ::= SEQUENCE {
alarmListName SnmpAdminString,
alarmActiveDateAndTime DateAndTime,
alarmActiveIndex Unsigned32,
alarmActiveEngineID LocalSnmpEngineOrZeroLenStr,
alarmActiveEngineAddressType InetAddressType,
alarmActiveEngineAddress InetAddress,
alarmActiveContextName SnmpAdminString,
alarmActiveVariables Unsigned32,
alarmActiveNotificationID OBJECT IDENTIFIER,
alarmActiveResourceId ResourceId,
alarmActiveDescription SnmpAdminString,
alarmActiveLogPointer RowPointer,
alarmActiveModelPointer RowPointer,
alarmActiveSpecificPointer RowPointer }
AlarmActiveEntry:、:= 系列{ alarmListName SnmpAdminString、alarmActiveDateAndTime DateAndTime、alarmActiveIndex Unsigned32、alarmActiveEngineID LocalSnmpEngineOrZeroLenStr、alarmActiveEngineAddressType InetAddressType、alarmActiveEngineAddress InetAddress、alarmActiveContextName SnmpAdminString; alarmActiveVariables Unsigned32、alarmActiveNotificationID物の識別子、alarmActiveResourceId ResourceId、alarmActiveDescription SnmpAdminString、alarmActiveLogPointer RowPointer、alarmActiveModelPointer RowPointer、alarmActiveSpecificPointer RowPointer; }
alarmListName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the list of alarms. This SHOULD be the same as
nlmLogName if the Notification Log MIB [RFC3014] is supported.
This SHOULD be the same as, or contain as a prefix, the
applicable snmpNotifyFilterProfileName if the
SNMP-NOTIFICATION-MIB DEFINITIONS [RFC3413] is supported.
alarmListName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「名前、Notification Log MIB[RFC3014]が支持されるならアラームこのSHOULDのリストでは、nlmLogNameと同じにしてください、」 または、このSHOULD、同じである、接頭語、適切なsnmpNotifyFilterProfileNameとして、SNMP-NOTIFICATION-MIB DEFINITIONS[RFC3413]が支持されるなら、含んでいます。
An implementation may allow multiple named alarm lists, up to
some implementation-specific limit (which may be none). A
zero-length list name is reserved for creation and deletion
by the managed system, and MUST be used as the default log
name by systems that do not support named alarm lists."
::= { alarmActiveEntry 1 }
実現は複数の命名されたアラームリストを何らかの実現特有の限界(なにもであるかもしれない)まで許容するかもしれません。 「ゼロ・レングスリスト名は、創造と削除のために管理されたシステムによって予約されて、命名されたアラームを支えないシステムによるデフォルトログ名が記載するように使用されているに違いありません。」 ::= alarmActiveEntry1
alarmActiveDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local date and time when the error occurred.
「誤りが発生したとき、ローカルは、日付を入れて、調節する」alarmActiveDateAndTime OBJECT-TYPE SYNTAX DateAndTimeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This object facilitates retrieving all instances of
この物は、すべての例を検索するのを容易にします。
Chisholm & Romascanu Standards Track [Page 23] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[23ページ]RFC3877はMIB2004年9月に驚かせます。
alarms that have been raised or have changed state
since a given point in time.
それがアラームであったのは、時間内にの与えられたポイント以来の状態を上げられるか、または変えました。
Implementations MUST include the offset from UTC,
if available. Implementation in environments in which
the UTC offset is not available is NOT RECOMMENDED."
::= { alarmActiveEntry 2 }
利用可能であるなら、実現はUTCからのオフセットを含まなければなりません。 「UTCオフセットが利用可能でない環境における実現はNOT RECOMMENDEDです。」 ::= alarmActiveEntry2
alarmActiveIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A strictly monotonically increasing integer which
acts as the index of entries within the named alarm
list. It wraps back to 1 after it reaches its
maximum value."
::= { alarmActiveEntry 3 }
alarmActiveIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「エントリーのインデックスとして命名されたアラームリストの中で機能する厳密に単調に増加する整数。」 「最大値に達した後に1への後部を包装します。」 ::= alarmActiveEntry3
alarmActiveEngineID OBJECT-TYPE
SYNTAX LocalSnmpEngineOrZeroLenStr
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The identification of the SNMP engine at which the alarm
originated. If the alarm is from an SNMPv1 system this
object is a zero length string."
::= { alarmActiveEntry 4 }
alarmActiveEngineID OBJECT-TYPE SYNTAX LocalSnmpEngineOrZeroLenStrのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが由来したSNMPエンジンの識別。」 「アラームがSNMPv1システムから来ているなら、この物はゼロ長ストリングです。」 ::= alarmActiveEntry4
alarmActiveEngineAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates what type of address is stored in
the alarmActiveEngineAddress object - IPv4, IPv6, DNS, etc."
::= { alarmActiveEntry 5 }
alarmActiveEngineAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「タイプするアドレスのものがalarmActiveEngineAddress物に格納されます--IPv4、IPv6、DNSなどを示これが反対するします」。 ::= alarmActiveEntry5
alarmActiveEngineAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The address of the SNMP engine on which the alarm is
occurring.
alarmActiveEngineAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが現れているSNMPエンジンのアドレス。」
This object MUST always be instantiated, even if the list
can contain alarms from only one engine."
「リストが1台のエンジンだけからのアラームを入れてあることができても、いつもこの物を例示しなければなりません。」
Chisholm & Romascanu Standards Track [Page 24] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[24ページ]RFC3877はMIB2004年9月に驚かせます。
::= { alarmActiveEntry 6 }
::= alarmActiveEntry6
alarmActiveContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the SNMP MIB context from which the alarm came.
For SNMPv1 alarms this is the community string from the Trap.
Note that care MUST be taken when selecting community
strings to ensure that these can be represented as a
well-formed SnmpAdminString. Community or Context names
that are not well-formed SnmpAdminStrings will be mapped
to zero length strings.
alarmActiveContextName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが来たSNMP MIB文脈の名前。」 SNMPv1アラームに関しては、これはTrapからの共同体ストリングです。 よく形成されたSnmpAdminStringとしてこれらを表すことができるのを保証するために共同体ストリングを選択するとき、注意しなければならないことに注意してください。 よく形成されたSnmpAdminStringsでない共同体かContext名が、長さのストリングのゼロを合わせるために写像されるでしょう。
If the alarm's source SNMP engine is known not to support
multiple contexts, this object is a zero length string."
::= { alarmActiveEntry 7 }
「アラームのソースSNMPエンジンが複数の文脈を支持しないのが知られているなら、この物はゼロ長ストリングです。」 ::= alarmActiveEntry7
alarmActiveVariables OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of variables in alarmActiveVariableTable for this
alarm."
::= { alarmActiveEntry 8 }
「これのためのalarmActiveVariableTableの変数の数は驚かせる」alarmActiveVariables OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= alarmActiveEntry8
alarmActiveNotificationID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of the alarm
state transition that is occurring."
::= { alarmActiveEntry 9 }
alarmActiveNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「起こっているアラーム状態遷移に関するNOTIFICATION-TYPE物の識別子。」 ::= alarmActiveEntry9
alarmActiveResourceId OBJECT-TYPE
SYNTAX ResourceId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the resource under alarm.
alarmActiveResourceId OBJECT-TYPE SYNTAX ResourceIdのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「アラームの下でリソースを特定これが反対するします」。
If there is no corresponding resource, then
the value of this object MUST be 0.0."
::= { alarmActiveEntry 10 }
「どんな対応するリソースもなければ、この物の値は0.0でなければなりません。」 ::= alarmActiveEntry10
Chisholm & Romascanu Standards Track [Page 25] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[25ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveDescription OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object provides a textual description of the
active alarm. This text is generated dynamically by the
notification generator to provide useful information
to the human operator. This information SHOULD
provide information allowing the operator to locate
the resource for which this alarm is being generated.
This information is not intended for consumption by
automated tools."
::= { alarmActiveEntry 11 }
「この物は活性アラームの原文の記述を提供する」alarmActiveDescription OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 本稿は通知ジェネレータでダイナミックに発生して、人間のオペレータに役に立つ情報を提供します。 この情報SHOULDはオペレータがこのアラームが発生しているリソースの場所を見つけることができる情報を提供します。 「この情報は消費で自動化されたツールで意図しません。」 ::= alarmActiveEntry11
alarmActiveLogPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A pointer to the corresponding row in a
notification logging MIB where the state change
notification for this active alarm is logged.
If no log entry applies to this active alarm,
then this object MUST have the value of 0.0"
::= { alarmActiveEntry 12 }
alarmActiveLogPointer OBJECT-TYPE SYNTAX RowPointerのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この活性アラームのための州の変更届出書が登録されるMIBを登録する通知における対応する列へのポインタ。」 ログエントリーが全くこの活性アラームに適用されないなら、この物には、0インチの値がなければなりません:、:= alarmActiveEntry12
alarmActiveModelPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A pointer to the corresponding row in the
alarmModelTable for this active alarm. This
points not only to the alarm model being
instantiated, but also to the specific alarm
state that is active."
::= { alarmActiveEntry 13 }
「これに、アクティブなalarmModelTableの対応する列へのポインタは驚かせる」alarmActiveModelPointer OBJECT-TYPE SYNTAX RowPointerのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「これは例示されているアラームモデルに指すだけではなく、活動的な特定のアラーム状態にも指します。」 ::= alarmActiveEntry13
alarmActiveSpecificPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If no additional, model-specific, Alarm MIB is supported by
the system this object is `0.0'. When a model-specific Alarm
MIB is supported, this object is the instance pointer to the
specific model-specific active alarm list."
alarmActiveSpecificPointer OBJECT-TYPE SYNTAX RowPointerのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述「どんな追加していて、モデル特有のAlarm MIBも支持されないなら、システムで、この物はそうです'0.0、'、」 「モデル特有のAlarm MIBが支持されるとき、この物は特定のモデル特有のアクティブなアラームリストへの例のポインタです。」
Chisholm & Romascanu Standards Track [Page 26] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[26ページ]RFC3877はMIB2004年9月に驚かせます。
::= { alarmActiveEntry 14 }
::= alarmActiveEntry14
-- Active Alarm Variable Table --
-- アクティブなアラーム可変テーブル--
alarmActiveVariableTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmActiveVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of variables to go with active alarm entries."
::= { alarmActive 3 }
alarmActiveVariableTable OBJECT-TYPEのSYNTAX SEQUENCE OF AlarmActiveVariableEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「活発なアラームエントリーと共に行く変数のテーブル。」 ::= alarmActive3
alarmActiveVariableEntry OBJECT-TYPE
SYNTAX AlarmActiveVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table when there are variables in
the varbind list of a corresponding alarm in
alarmActiveTable.
「対応するアラームのvarbindリストに変数がalarmActiveTableにあるときエントリーはこのテーブルに現れる」alarmActiveVariableEntry OBJECT-TYPE SYNTAX AlarmActiveVariableEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Entries appear in this table as though
the trap/notification had been transported using a
SNMPv2-Trap-PDU, as defined in [RFC3416] - i.e., the
alarmActiveVariableIndex 1 will always be sysUpTime
and alarmActiveVariableIndex 2 will always be
snmpTrapOID.
エントリーはまるで罠/通知がSNMPv2罠PDUを使用することで輸送されたかのようにこのテーブルで見えます、[RFC3416]で定義されるように--すなわち、alarmActiveVariableIndex1はいつもsysUpTimeになるでしょう、そして、alarmActiveVariableIndex2はいつもsnmpTrapOIDになるでしょう。
If the incoming notification is instead an SNMPv1 Trap-PDU and
the value of alarmModelVarbindIndex is 1 or 2, an appropriate
value for sysUpTime.0 or snmpTrapOID.0 shall be determined
by using the rules in section 3.1 of [RFC3584]."
INDEX { alarmListName, alarmActiveIndex,
alarmActiveVariableIndex }
::= { alarmActiveVariableTable 1 }
「alarmModelVarbindIndexの値が入って来る通知が代わりにSNMPv1 Trap-PDUであり、1か2であるなら、sysUpTime.0かsnmpTrapOID.0のための適切な値は[RFC3584]のセクション3.1で規則を使用することによって、決定するものとします。」 alarmListName、alarmActiveIndex、alarmActiveVariableIndexに索引をつけてください:、:= alarmActiveVariableTable1
AlarmActiveVariableEntry ::= SEQUENCE {
alarmActiveVariableIndex Unsigned32,
alarmActiveVariableID OBJECT IDENTIFIER,
alarmActiveVariableValueType INTEGER,
alarmActiveVariableCounter32Val Counter32,
alarmActiveVariableUnsigned32Val Unsigned32,
alarmActiveVariableTimeTicksVal TimeTicks,
alarmActiveVariableInteger32Val Integer32,
alarmActiveVariableOctetStringVal OCTET STRING,
alarmActiveVariableIpAddressVal IpAddress,
alarmActiveVariableOidVal OBJECT IDENTIFIER,
alarmActiveVariableCounter64Val Counter64,
AlarmActiveVariableEntry:、:= 系列、alarmActiveVariableIndex Unsigned32、alarmActiveVariableID物の識別子、alarmActiveVariableValueType整数、alarmActiveVariableCounter32Val Counter32、alarmActiveVariableUnsigned32Val Unsigned32、alarmActiveVariableTimeTicksVal TimeTicks、alarmActiveVariableInteger32Val Integer32、alarmActiveVariableOctetStringVal八重奏ストリング、alarmActiveVariableIpAddressVal IpAddress、alarmActiveVariableOidVal物の識別子、alarmActiveVariableCounter64Val Counter64
Chisholm & Romascanu Standards Track [Page 27] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[27ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveVariableOpaqueVal Opaque }
alarmActiveVariableOpaqueValは不透明にします。
alarmActiveVariableIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A strictly monotonically increasing integer, starting at
1 for a given alarmActiveIndex, for indexing variables
within the active alarm variable list. "
::= { alarmActiveVariableEntry 1 }
alarmActiveVariableIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「1時に与えられたalarmActiveIndexのために始まって、アクティブなアラーム変数の中で変数に索引をつけるために、厳密に単調に増加する整数に記載してください。」 " ::= alarmActiveVariableEntry1
alarmActiveVariableID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The alarm variable's object identifier."
::= { alarmActiveVariableEntry 2 }
alarmActiveVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラーム変数の物の識別子。」 ::= alarmActiveVariableEntry2
alarmActiveVariableValueType OBJECT-TYPE
SYNTAX INTEGER {
counter32(1),
unsigned32(2),
timeTicks(3),
integer32(4),
ipAddress(5),
octetString(6),
objectId(7),
counter64(8),
opaque(9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of the value. One and only one of the value
objects that follow is used for a given row in this table,
based on this type."
::= { alarmActiveVariableEntry 3 }
alarmActiveVariableValueType OBJECT-TYPE SYNTAX INTEGER、counter32(1)、unsigned32(2)、timeTicks(3)、integer32(4)、ipAddress(5)、octetString(6)、objectId(7)(counter64(8))が(9)について不透明にする、マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「価値のタイプ。」 「従う値の物の唯一無二の1つはこのテーブルの与えられた列に使用されます、このタイプに基づいて。」 ::= alarmActiveVariableEntry3
alarmActiveVariableCounter32Val OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'counter32'."
::= { alarmActiveVariableEntry 4 }
「alarmActiveVariableTypeであるときに、値は'counter32alarmActiveVariableCounter32Val OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry4
Chisholm & Romascanu Standards Track [Page 28] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[28ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveVariableUnsigned32Val OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'unsigned32'."
::= { alarmActiveVariableEntry 5 }
「alarmActiveVariableTypeであるときに、値は'unsigned32alarmActiveVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry5
alarmActiveVariableTimeTicksVal OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'timeTicks'."
::= { alarmActiveVariableEntry 6 }
「alarmActiveVariableTypeであるときに、値は'timeTicks alarmActiveVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry6
alarmActiveVariableInteger32Val OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'integer32'."
::= { alarmActiveVariableEntry 7 }
「alarmActiveVariableTypeであるときに、値は'integer32alarmActiveVariableInteger32Val OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry7
alarmActiveVariableOctetStringVal OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..65535))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'octetString'."
::= { alarmActiveVariableEntry 8 }
「alarmActiveVariableTypeであるときに、値は'octetString alarmActiveVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0 .65535))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry8
alarmActiveVariableIpAddressVal OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'ipAddress'."
::= { alarmActiveVariableEntry 9 }
「alarmActiveVariableTypeであるときに、値は'ipAddress alarmActiveVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry9
alarmActiveVariableOidVal OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'objectId'."
::= { alarmActiveVariableEntry 10 }
「alarmActiveVariableTypeであるときに、値は'objectId alarmActiveVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry10
Chisholm & Romascanu Standards Track [Page 29] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[29ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveVariableCounter64Val OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'counter64'."
::= { alarmActiveVariableEntry 11 }
「alarmActiveVariableTypeであるときに、値は'counter64alarmActiveVariableCounter64Val OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= alarmActiveVariableEntry11
alarmActiveVariableOpaqueVal OBJECT-TYPE
SYNTAX Opaque (SIZE(0..65535))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when alarmActiveVariableType is 'opaque'.
「値のいつalarmActiveVariableTypeはそうであるか'が不透明にするalarmActiveVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque(SIZE(0 .65535))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、'、」
Note that although RFC2578 [RFC2578] forbids the use
of Opaque in 'standard' MIB modules, this particular
usage is driven by the need to be able to accurately
represent any well-formed notification, and justified
by the need for backward compatibility."
::= { alarmActiveVariableEntry 12 }
「この特定の用法がRFC2578[RFC2578]が'標準'のMIBモジュールにおけるOpaqueの使用を禁じますが、正確にどんなよく形成された通知も表すことができる必要性によって動かされて、後方の互換性の必要性によって正当化されることに注意してください。」 ::= alarmActiveVariableEntry12
-- Statistics --
-- 統計--
alarmActiveStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the alarm statistics
information."
::= { alarmActive 4 }
alarmActiveStatsTable OBJECT-TYPEのSYNTAX SEQUENCE OF AlarmActiveStatsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルはアラーム統計情報を表します」。 ::= alarmActive4
alarmActiveStatsEntry OBJECT-TYPE
SYNTAX AlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics on the current active alarms."
INDEX { alarmListName }
. alarmActiveStatsEntry OBJECT-TYPE SYNTAX AlarmActiveStatsEntryのマックス-ACCESSのアクセスしやすくないSTATUSの現在の記述「電流でアクティブな統計は驚かせ」INDEXalarmListName
::= { alarmActiveStatsTable 1 }
::= alarmActiveStatsTable1
AlarmActiveStatsEntry ::=
SEQUENCE {
alarmActiveStatsActiveCurrent Gauge32,
alarmActiveStatsActives ZeroBasedCounter32,
alarmActiveStatsLastRaise TimeTicks,
AlarmActiveStatsEntry:、:= 系列、alarmActiveStatsActiveCurrent Gauge32、alarmActiveStatsActives ZeroBasedCounter32、alarmActiveStatsLastRaise TimeTicks
Chisholm & Romascanu Standards Track [Page 30] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[30ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveStatsLastClear TimeTicks
}
alarmActiveStatsLastClear TimeTicks
alarmActiveStatsActiveCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of currently active alarms on the system."
::= { alarmActiveStatsEntry 1 }
「現在アクティブの総数はシステムの上で驚かせる」alarmActiveStatsActiveCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= alarmActiveStatsEntry1
alarmActiveStatsActives OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of active alarms since system restarted."
::= { alarmActiveStatsEntry 2 }
「システム以来の活性アラームの総数は再開した」alarmActiveStatsActives OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= alarmActiveStatsEntry2
alarmActiveStatsLastRaise OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
alarm raise for this alarm list.
If no alarm raises have occurred since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActiveStatsEntry 3 }
「最後のアラーム時点のsysUpTimeの値はこのアラームリストのために上げる」alarmActiveStatsLastRaise OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「企業内情報通信網管理サブシステムの最後の再初期化以来アラーム昇給が全く起こっていないなら、この物はaゼロ値を含んでいます。」 ::= alarmActiveStatsEntry3
alarmActiveStatsLastClear OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
alarm clear for this alarm list.
If no alarm clears have occurred since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { alarmActiveStatsEntry 4 }
「最後のアラーム時点のsysUpTimeの値はこのアラームリストのためにクリアする」alarmActiveStatsLastClear OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「企業内情報通信網管理サブシステムの最後の再初期化以来いいえがアラームがクリアする起こっているなら、この物はaゼロ値を含んでいます。」 ::= alarmActiveStatsEntry4
-- Alarm Clear
-- はっきりと驚かせてください。
alarmClearMaximum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write
alarmClearMaximum OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSは読書して書きます。
Chisholm & Romascanu Standards Track [Page 31] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[31ページ]RFC3877はMIB2004年9月に驚かせます。
STATUS current
DESCRIPTION
"This object specifies the maximum number of cleared
alarms to store in the alarmClearTable. When this
number is reached, the cleared alarms with the
earliest clear time will be removed from the table."
::= { alarmClear 1 }
STATUSの現在の記述は「alarmClearTableに格納するクリアされたアラームの最大数を指定これが反対するします」。 「この数に達しているとき、時間がある晴れている最も前半クリアされたアラームはテーブルから取り除かれるでしょう。」 ::= alarmClear1
alarmClearTable OBJECT-TYPE
SYNTAX SEQUENCE OF AlarmClearEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains information on
cleared alarms."
::= { alarmClear 2 }
alarmClearTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmClearEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルはクリアされたアラームの情報を含んでいる」、:、:= alarmClear2
alarmClearEntry OBJECT-TYPE
SYNTAX AlarmClearEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a cleared alarm."
INDEX { alarmListName, alarmClearDateAndTime,
alarmClearIndex }
alarmClearEntry OBJECT-TYPE SYNTAX AlarmClearEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「クリアされたアラームに関する情報。」 インデックスalarmListName、alarmClearDateAndTime、alarmClearIndex
::= { alarmClearTable 1 }
::= alarmClearTable1
AlarmClearEntry ::=
SEQUENCE {
alarmClearIndex Unsigned32,
alarmClearDateAndTime DateAndTime,
alarmClearEngineID LocalSnmpEngineOrZeroLenStr,
alarmClearEngineAddressType InetAddressType,
alarmClearEngineAddress InetAddress,
alarmClearContextName SnmpAdminString,
alarmClearNotificationID OBJECT IDENTIFIER,
alarmClearResourceId ResourceId,
alarmClearLogIndex Unsigned32,
alarmClearModelPointer RowPointer
}
AlarmClearEntry:、:= 系列alarmClearIndex Unsigned32、alarmClearDateAndTime DateAndTime、alarmClearEngineID LocalSnmpEngineOrZeroLenStr、alarmClearEngineAddressType InetAddressType、alarmClearEngineAddress InetAddress、alarmClearContextName SnmpAdminString、alarmClearNotificationID物の識別子、alarmClearResourceId ResourceId、alarmClearLogIndex Unsigned32、alarmClearModelPointer RowPointer
alarmClearIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An integer which acts as the index of entries within
alarmClearIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「エントリーのインデックスとして中で機能する整数」です。
Chisholm & Romascanu Standards Track [Page 32] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[32ページ]RFC3877はMIB2004年9月に驚かせます。
the named alarm list. It wraps back to 1 after it
reaches its maximum value.
命名されたアラームリスト。 最大値に達した後にそれは1への後部を包装します。
This object has the same value as the alarmActiveIndex that
this alarm instance had when it was active."
::= { alarmClearEntry 1 }
「この物には、それがアクティブであったときに、このアラーム例が持っていたalarmActiveIndexと同じ値があります。」 ::= alarmClearEntry1
alarmClearDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local date and time when the alarm cleared.
「アラームがきれいにされたとき、ローカルは、日付を入れて、調節する」alarmClearDateAndTime OBJECT-TYPE SYNTAX DateAndTimeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This object facilitates retrieving all instances of
alarms that have been cleared since a given point in time.
この物は、時間内に以来与えられたポイントきれいにされているアラームのすべての例を検索するのを容易にします。
Implementations MUST include the offset from UTC,
if available. Implementation in environments in which
the UTC offset is not available is NOT RECOMMENDED."
::= { alarmClearEntry 2 }
利用可能であるなら、実現はUTCからのオフセットを含まなければなりません。 「UTCオフセットが利用可能でない環境における実現はNOT RECOMMENDEDです。」 ::= alarmClearEntry2
alarmClearEngineID OBJECT-TYPE
SYNTAX LocalSnmpEngineOrZeroLenStr
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The identification of the SNMP engine at which the alarm
originated. If the alarm is from an SNMPv1 system this
object is a zero length string."
::= { alarmClearEntry 3 }
alarmClearEngineID OBJECT-TYPE SYNTAX LocalSnmpEngineOrZeroLenStrのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが由来したSNMPエンジンの識別。」 「アラームがSNMPv1システムから来ているなら、この物はゼロ長ストリングです。」 ::= alarmClearEntry3
alarmClearEngineAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates what type of address is stored in
the alarmActiveEngineAddress object - IPv4, IPv6, DNS, etc."
::= { alarmClearEntry 4 }
alarmClearEngineAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「タイプするアドレスのものがalarmActiveEngineAddress物に格納されます--IPv4、IPv6、DNSなどを示これが反対するします」。 ::= alarmClearEntry4
alarmClearEngineAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Address of the SNMP engine on which the alarm was
occurring. This is used to identify the source of an SNMPv1
alarmClearEngineAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが現れていたSNMPエンジンのAddress。」 これは、SNMPv1の源を特定するのに使用されます。
Chisholm & Romascanu Standards Track [Page 33] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[33ページ]RFC3877はMIB2004年9月に驚かせます。
trap, since an alarmActiveEngineId cannot be extracted from the
SNMPv1 trap PDU.
SNMPv1罠PDUからalarmActiveEngineIdを抽出できないので、捕らえてください。
This object MUST always be instantiated, even if the list
can contain alarms from only one engine."
::= { alarmClearEntry 5 }
「リストが1台のエンジンだけからのアラームを入れてあることができても、いつもこの物を例示しなければなりません。」 ::= alarmClearEntry5
alarmClearContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the SNMP MIB context from which the alarm came.
For SNMPv1 traps this is the community string from the Trap.
Note that care needs to be taken when selecting community
strings to ensure that these can be represented as a
well-formed SnmpAdminString. Community or Context names
that are not well-formed SnmpAdminStrings will be mapped
to zero length strings.
alarmClearContextName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アラームが来たSNMP MIB文脈の名前。」 SNMPv1罠のために、これはTrapからの共同体ストリングです。 注意が、よく形成されたSnmpAdminStringとしてこれらを表すことができるのを保証するために共同体ストリングを選択するとき、取られる必要に注意してください。 よく形成されたSnmpAdminStringsでない共同体かContext名が、長さのストリングのゼロを合わせるために写像されるでしょう。
If the alarm's source SNMP engine is known not to support
multiple contexts, this object is a zero length string."
::= { alarmClearEntry 6 }
「アラームのソースSNMPエンジンが複数の文脈を支持しないのが知られているなら、この物はゼロ長ストリングです。」 ::= alarmClearEntry6
alarmClearNotificationID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of the alarm
clear."
::= { alarmClearEntry 7 }
「アラームに関するNOTIFICATION-TYPE物の識別子はクリアする」alarmClearNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= alarmClearEntry7
alarmClearResourceId OBJECT-TYPE
SYNTAX ResourceId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the resource that was under alarm.
alarmClearResourceId OBJECT-TYPE SYNTAX ResourceIdのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「アラームの下にあったリソースを特定これが反対するします」。
If there is no corresponding resource, then
the value of this object MUST be 0.0."
::= { alarmClearEntry 8 }
「どんな対応するリソースもなければ、この物の値は0.0でなければなりません。」 ::= alarmClearEntry8
alarmClearLogIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current
alarmClearLogIndex OBJECT-TYPE SYNTAX Unsigned32(0 .4294967295)マックス-ACCESS書き込み禁止STATUS海流
Chisholm & Romascanu Standards Track [Page 34] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[34ページ]RFC3877はMIB2004年9月に驚かせます。
DESCRIPTION
"This number MUST be the same as the log index of the
applicable row in the notification log MIB, if it exists.
If no log index applies to the trap, then this object
MUST have the value of 0."
::= { alarmClearEntry 9 }
「この数は通知における、適切な列のログインデックスと同じくらいがログMIBであったなら存在しているならそうしなければなりません」記述。 「ログインデックスが全く罠に適用されないなら、この物には、0の値がなければなりません。」 ::= alarmClearEntry9
alarmClearModelPointer OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A pointer to the corresponding row in the
alarmModelTable for this cleared alarm."
::= { alarmClearEntry 10 }
alarmClearModelPointer OBJECT-TYPE SYNTAX RowPointerのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「これのためのalarmModelTableの対応する列へのポインタはアラームをきれいにしました」。 ::= alarmClearEntry10
-- Notifications
-- 通知
alarmActiveState NOTIFICATION-TYPE
OBJECTS { alarmActiveModelPointer,
alarmActiveResourceId }
STATUS current
DESCRIPTION
"An instance of the alarm indicated by
alarmActiveModelPointer has been raised
against the entity indicated by
alarmActiveResourceId.
alarmActiveState NOTIFICATION-TYPE OBJECTS、alarmActiveModelPointer、alarmActiveResourceId、STATUSの現在の記述は「alarmActiveResourceIdによって示された実体に対してalarmActiveModelPointerによって上げアラームの例が示したされました」。
The agent must throttle the generation of
consecutive alarmActiveState traps so that there is at
least a two-second gap between traps of this
type against the same alarmActiveModelPointer and
alarmActiveResourceId. When traps are throttled,
they are dropped, not queued for sending at a future time.
エージェントは、少なくとも2秒のギャップがこのタイプの罠の間に同じalarmActiveModelPointerとalarmActiveResourceIdに反対しているように、連続したalarmActiveState罠の世代を阻止しなければなりません。 罠が阻止されるとき、それらは将来の時間に発信するために列に並ばせられるのではなく、落とされます。
A management application should periodically check
the value of alarmActiveLastChanged to detect any
missed alarmActiveState notification-events, e.g.,
due to throttling or transmission loss."
::= { alarmNotifications 2 }
「管理アプリケーションはどんな逃されたalarmActiveState通知イベントも検出するために定期的にalarmActiveLastChangedの値をチェックするべきです、例えば、阻止か動作減衰量のため。」 ::= alarmNotifications2
alarmClearState NOTIFICATION-TYPE
OBJECTS { alarmActiveModelPointer,
alarmActiveResourceId }
STATUS current
DESCRIPTION
"An instance of the alarm indicated by
alarmActiveModelPointer has been cleared against
alarmClearState NOTIFICATION-TYPE OBJECTS、alarmActiveModelPointer、alarmActiveResourceId、STATUSの現在の記述に「alarmActiveModelPointerによってクリアアラームの例が示したされました」。
Chisholm & Romascanu Standards Track [Page 35] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[35ページ]RFC3877はMIB2004年9月に驚かせます。
the entity indicated by alarmActiveResourceId.
alarmActiveResourceIdによって示された実体。
The agent must throttle the generation of
consecutive alarmActiveClear traps so that there is at
least a two-second gap between traps of this
type against the same alarmActiveModelPointer and
alarmActiveResourceId. When traps are throttled,
they are dropped, not queued for sending at a future time.
エージェントは、少なくとも2秒のギャップがこのタイプの罠の間に同じalarmActiveModelPointerとalarmActiveResourceIdに反対しているように、連続したalarmActiveClear罠の世代を阻止しなければなりません。 罠が阻止されるとき、それらは将来の時間に発信するために列に並ばせられるのではなく、落とされます。
A management application should periodically check
the value of alarmActiveLastChanged to detect any
missed alarmClearState notification-events, e.g.,
due to throttling or transmission loss."
::= { alarmNotifications 3 }
「管理アプリケーションはどんな逃されたalarmClearState通知イベントも検出するために定期的にalarmActiveLastChangedの値をチェックするべきです、例えば、阻止か動作減衰量のため。」 ::= alarmNotifications3
-- Conformance
-- 順応
alarmConformance OBJECT IDENTIFIER ::= { alarmMIB 2 }
alarmConformance物の識別子:、:= alarmMIB2
alarmCompliances OBJECT IDENTIFIER ::= { alarmConformance 1 }
alarmCompliances物の識別子:、:= alarmConformance1
alarmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems supporting
the Alarm MIB."
MODULE -- this module
MANDATORY-GROUPS {
alarmActiveGroup,
alarmModelGroup
}
GROUP alarmActiveStatsGroup
DESCRIPTION
"This group is optional."
GROUP alarmClearGroup
DESCRIPTION
"This group is optional."
GROUP alarmNotificationsGroup
DESCRIPTION
"This group is optional."
::= { alarmCompliances 1 }
alarmCompliance MODULE-COMPLIANCE STATUSの現在の記述、「Alarm MIBを支持するシステムのための承諾声明。」 MODULE--、このモジュールMANDATORY-GROUPS、alarmActiveGroup、alarmModelGroup、GROUP alarmActiveStatsGroup記述、「このグループは任意です」。 GROUP alarmClearGroup記述、「このグループは任意です」。 GROUP alarmNotificationsGroup記述、「このグループは任意です」。 ::= alarmCompliances1
alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }
alarmGroups物の識別子:、:= alarmConformance2
alarmModelGroup OBJECT-GROUP
OBJECTS {
alarmModelLastChanged,
alarmModelNotificationId,
alarmModelGroup物群対象、alarmModelLastChanged、alarmModelNotificationId
Chisholm & Romascanu Standards Track [Page 36] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[36ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelVarbindIndex,
alarmModelVarbindValue,
alarmModelDescription,
alarmModelSpecificPointer,
alarmModelVarbindSubtree,
alarmModelResourcePrefix,
alarmModelRowStatus
}
STATUS current
DESCRIPTION
"Alarm model group."
::= { alarmGroups 1}
alarmModelVarbindIndex、alarmModelVarbindValue、alarmModelDescription、alarmModelSpecificPointer、alarmModelVarbindSubtree、alarmModelResourcePrefix、alarmModelRowStatus STATUSの現在の記述「アラームモデルグループ。」 ::= alarmGroups1
alarmActiveGroup OBJECT-GROUP
OBJECTS {
alarmActiveLastChanged,
alarmActiveOverflow,
alarmActiveEngineID,
alarmActiveEngineAddressType,
alarmActiveEngineAddress,
alarmActiveContextName,
alarmActiveVariables,
alarmActiveNotificationID,
alarmActiveResourceId,
alarmActiveDescription,
alarmActiveLogPointer,
alarmActiveModelPointer,
alarmActiveSpecificPointer,
alarmActiveVariableID,
alarmActiveVariableValueType,
alarmActiveVariableCounter32Val,
alarmActiveVariableUnsigned32Val,
alarmActiveVariableTimeTicksVal,
alarmActiveVariableInteger32Val,
alarmActiveVariableOctetStringVal,
alarmActiveVariableIpAddressVal,
alarmActiveVariableOidVal,
alarmActiveVariableCounter64Val,
alarmActiveVariableOpaqueVal
}
STATUS current
DESCRIPTION
"Active Alarm list group."
::= { alarmGroups 2}
alarmActiveGroup物群対象; { alarmActiveLastChanged、alarmActiveOverflow、alarmActiveEngineID、alarmActiveEngineAddressType、alarmActiveEngineAddress、alarmActiveContextName、alarmActiveVariables、alarmActiveNotificationID、alarmActiveResourceId、alarmActiveDescription、alarmActiveLogPointer、alarmActiveModelPointer、alarmActiveSpecificPointer、alarmActiveVariableID; alarmActiveVariableValueType、alarmActiveVariableCounter32Val、alarmActiveVariableUnsigned32Val、alarmActiveVariableTimeTicksVal、alarmActiveVariableInteger32Val、alarmActiveVariableOctetStringVal、alarmActiveVariableIpAddressVal、alarmActiveVariableOidVal、alarmActiveVariableCounter64Val、alarmActiveVariableOpaqueVal; } STATUSの現在の記述「活動的なAlarmリストグループ。」 ::= alarmGroups2
alarmActiveStatsGroup OBJECT-GROUP
OBJECTS {
alarmActiveStatsActives,
alarmActiveStatsGroup物群対象、alarmActiveStatsActives
Chisholm & Romascanu Standards Track [Page 37] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[37ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveStatsActiveCurrent,
alarmActiveStatsLastRaise,
alarmActiveStatsLastClear
}
STATUS current
DESCRIPTION
"Active alarm summary group."
::= { alarmGroups 3}
alarmActiveStatsActiveCurrent、alarmActiveStatsLastRaise、alarmActiveStatsLastClear STATUSの現在の記述「活動的なアラーム概要グループ。」 ::= alarmGroups3
alarmClearGroup OBJECT-GROUP
OBJECTS {
alarmClearMaximum,
alarmClearEngineID,
alarmClearEngineAddressType,
alarmClearEngineAddress,
alarmClearContextName,
alarmClearNotificationID,
alarmClearResourceId,
alarmClearLogIndex,
alarmClearModelPointer
}
STATUS current
DESCRIPTION
"Cleared alarm group."
::= { alarmGroups 4}
alarmClearGroup OBJECT-GROUP OBJECTS、alarmClearMaximum、alarmClearEngineID、alarmClearEngineAddressType、alarmClearEngineAddress、alarmClearContextName、alarmClearNotificationID、alarmClearResourceId、alarmClearLogIndex、alarmClearModelPointer、STATUSの現在の記述は「アラームグループをクリアしました」。 ::= alarmGroups4
alarmNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { alarmActiveState, alarmClearState }
STATUS current
DESCRIPTION
"The collection of notifications that can be used to
model alarms for faults lacking pre-existing
notification definitions."
::= { alarmGroups 6 }
alarmNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS、alarmActiveState、alarmClearState、STATUSの現在の記述、「モデル化するのに使用できる通知の収集は通知定義を先在させながら欠けている欠点に驚かせます」。 ::= alarmGroups6
END
終わり
5. ITU Alarm
5. ITUアラーム
5.1. Overview
5.1. 概観
This MIB module defines alarm information specific to the alarm model defined in ITU M.3100 [M.3100], X.733 [X.733], and X.736 [X.736]. This MIB module follows the modular architecture defined by the Alarm MIB, in which the generic Alarm MIB can be augmented by other alarm information defined according to more specific models that define additional behaviour and characteristics.
このMIBモジュールはITU M.3100[M.3100]、X.733[X.733]、およびX.736[X.736]で定義されたアラームモデルに、特定のアラーム情報を定義します。 このMIBモジュールはAlarm MIBによって定義されたモジュールの構造に従います。そこでは、追加ふるまいと特性を定義するより特定のモデルに従って定義された他のアラーム情報で一般的なAlarm MIBは増大させられることができます。
Chisholm & Romascanu Standards Track [Page 38] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[38ページ]RFC3877はMIB2004年9月に驚かせます。
The ituAlarmTable contains information from the ITU Alarm Model about possible alarms in the system.
ituAlarmTableはシステムに可能なアラームに関してITU Alarm Modelからの情報を含んでいます。
The ituAlarmActiveTable contains information from the ITU Alarm Model about alarms modelled using the ituAlarmTable that are currently occurring on the system.
ituAlarmActiveTableは現在システムの上に起こっているituAlarmTableを使用することでモデル化されたアラームに関してITU Alarm Modelからの情報を含んでいます。
The ituAlarmActiveStatsTable provides statistics on current and total alarms.
ituAlarmActiveStatsTableは現在の、そして、総アラームにおける統計を提供します。
5.2. IANA Considerations
5.2. IANA問題
Over time, there will be a need to add new IANAITUEventType and IANAItuProbableCause enumerated values. The Internet Assigned Number Authority (IANA) is responsible for the assignment of the enumerations in these TCs.
時間がたつにつれて、新しいIANAITUEventTypeとIANAItuProbableCauseが値を列挙したと言い足す必要があるでしょう。 ISOCの機関の一つで(IANA)はこれらのTCsの列挙の課題に責任があります。
IANAItuProbableCause value of 0 is reserved for special purposes and MUST NOT be assigned. Values of IANAItuProbableCause in the range 1 to 1023 are reserved for causes that correspond to ITU-T probable cause. All other requests for new causes will be handled on a first-come basis, with 1025.
0のIANAItuProbableCause値を、特別な目的のために予約して、割り当ててはいけません。 範囲1〜1023のIANAItuProbableCauseの値はITU-Tありえそうな原因に対応する原因のために予約されます。 新しい原因を求める他のすべての要求が1025で最初に来ているベースで扱われるでしょう。
Request should come in the form of well-formed SMI [RFC2578] for enumeration names that are unique and sufficiently descriptive.
要求はユニークで十分描写的である列挙名のためによく形成されたSMI[RFC2578]のフォームに入るべきです。
While some effort will be taken to ensure that new enumerations do not conceptually duplicate existing enumerations it is acknowledged that the existence of conceptual duplicates in the starting probable cause list is an known industry reality.
新しい列挙が概念的に既存の列挙をコピーしないのを保証するために何らかの努力を取るでしょうが、始めの推定原因リストの概念的な写しの存在が知られている産業現実のものであると認めます。
To aid IANA in the administration of probable cause names and values, the OPS Area Director will appoint one or more experts to help review requests.
推定原因名と値の管理でIANAを支援すると、OPS Areaディレクターは、レビュー要求を助けるために1人以上の専門家を任命するでしょう。
See http://www.iana.org
http://www.iana.org を見てください。
The following shall be used as the initial values, but the latest values for these textual conventions should be obtained from IANA:
初期の値として以下を使用するものとしますが、IANAからこれらの原文のコンベンションのための最新の値を得るべきです:
IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN
IANA ITUアラームTc MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC2579]
IMPORTS MODULE-IDENTITY、mib-2 FROM SNMPv2-SMI--[RFC2578]TEXTUAL-CONVENTION FROM SNMPv2-TC。 -- [RFC2579]
Chisholm & Romascanu Standards Track [Page 39] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[39ページ]RFC3877はMIB2004年9月に驚かせます。
ianaItuAlarmNumbers MODULE-IDENTITY
LAST-UPDATED "200409090000Z" -- September 09, 2004
ORGANIZATION "IANA"
CONTACT-INFO
"Postal: Internet Assigned Numbers Authority
Internet Corporation for Assigned Names
and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601
USA
ianaItuAlarmNumbersモジュールアイデンティティは"200409090000Z"をアップデートしました--2004年9月9日組織"IANA"、コンタクトインフォメーション、「郵便:、」 インターネットAssigned民数記Authorityアイキャン4676海軍本部Way、Suite330マリナデルレイ、カリフォルニア90292-6601米国
Tel: +1 310-823-9358
E-Mail: iana@iana.org"
DESCRIPTION
"The MIB module defines the ITU Alarm
textual convention for objects expected to require
regular extension.
Tel: +1 310-823-9358 メールしてください: " iana@iana.org "記述、「MIBモジュールは定期的な拡大を必要とすると予想された物のためにITUのAlarmの原文のコンベンションを定義します」。
Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC
itself. Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html"
REVISION "200409090000Z" -- September 09, 2004
DESCRIPTION
"Initial version, published as RFC 3877."
::= { mib-2 119 }
Copyright(C)インターネット協会(2004)。 このMIBモジュールの初期のバージョンはRFC3877で発行されました。 完全な法定の通知に関しては、RFC自身を見てください。 補助情報は以下で利用可能であるかもしれません。 " http://www.ietf.org/copyrights/ianamib.html "REVISION"200409090000Z"--「初期のバージョンであって、RFC3877として発行された」2004年9月9日記述。 ::= mib-2 119
IANAItuProbableCause ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"ITU-T probable cause values. Duplicate values defined in
X.733 are appended with X733 to ensure syntactic uniqueness.
Probable cause value 0 is reserved for special purposes.
IANAItuProbableCause:、:= TEXTUAL-CONVENTION STATUSの現在の記述「ITU-T推定原因値。」 構文のユニークさを確実にするためにX733と共にX.733で定義された写し値を追加します。 推定原因値0は特別な目的のために予約されます。
The Internet Assigned Number Authority (IANA) is responsible
for the assignment of the enumerations in this TC.
IANAItuProbableCause value of 0 is reserved for special
purposes and MUST NOT be assigned.
ISOCの機関の一つで(IANA)はこのTCの列挙の課題に責任があります。 0のIANAItuProbableCause値を、特別な目的のために予約して、割り当ててはいけません。
Values of IANAItuProbableCause in the range 1 to 1023 are
reserved for causes that correspond to ITU-T probable cause.
範囲1〜1023のIANAItuProbableCauseの値はITU-Tありえそうな原因に対応する原因のために予約されます。
All other requests for new causes will be handled on a
first-come, first served basis and will be assigned
enumeration values starting with 1025.
新しい原因を求める他のすべての要求は先着順のベースで扱われて、1025から始まる列挙値を割り当てられるでしょう。
Request should come in the form of well-formed
要求はよく形成されることのフォームに入るべきです。
Chisholm & Romascanu Standards Track [Page 40] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[40ページ]RFC3877はMIB2004年9月に驚かせます。
SMI [RFC2578] for enumeration names that are unique and
sufficiently descriptive.
列挙がそれを命名するので、SMI[RFC2578]はユニークであって、十分描写的です。
While some effort will be taken to ensure that new probable
causes do not conceptually duplicate existing probable
causes it is acknowledged that the existence of conceptual
duplicates in the starting probable cause list is an known
industry reality.
新しい推定原因が概念的に既存の推定原因をコピーしないのを保証するために何らかの努力を取るでしょうが、始めの推定原因リストの概念的な写しの存在が知られている産業現実のものであると認めます。
To aid IANA in the administration of probable cause names
and values, the OPS Area Director will appoint one or more
experts to help review requests.
推定原因名と値の管理でIANAを支援すると、OPS Areaディレクターは、レビュー要求を助けるために1人以上の専門家を任命するでしょう。
See http://www.iana.org"
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992
ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
「 http://www.iana.org を見てください」が「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'に参照をつける、」 '情報技術--オープン・システム・インターコネクション--'アラーム報告機能'、1992年のITU推薦X.736、システム管理:、' 「'警報機報告機能'、1992」
SYNTAX INTEGER
{
-- The following probable causes were defined in M.3100
aIS (1),
callSetUpFailure (2),
degradedSignal (3),
farEndReceiverFailure (4),
framingError (5),
lossOfFrame (6),
lossOfPointer (7),
lossOfSignal (8),
payloadTypeMismatch (9),
transmissionError (10),
remoteAlarmInterface (11),
excessiveBER (12),
pathTraceMismatch (13),
unavailable (14),
signalLabelMismatch (15),
lossOfMultiFrame (16),
receiveFailure (17),
transmitFailure (18),
modulationFailure (19),
demodulationFailure (20),
broadcastChannelFailure (21),
構文整数; 以下の推定原因はM.3100 aIS(1)で定義されました、callSetUpFailure(2)、degradedSignal(3)、farEndReceiverFailure(4)、framingError(5)、lossOfFrame(6)、lossOfPointer(7)、lossOfSignal(8)、payloadTypeMismatch(9)、transmissionError(10)、remoteAlarmInterface(11)、excessiveBER(12)、pathTraceMismatch(13)、入手できない(14)、signalLabelMismatch(15)、lossOfMultiFrame(16)、receiveFailure(17)、transmitFailure(18)、modulationFailure(19)、demodulationFailure(20)、broadcastChannelFailure(21)
Chisholm & Romascanu Standards Track [Page 41] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[41ページ]RFC3877はMIB2004年9月に驚かせます。
connectionEstablishmentError (22),
invalidMessageReceived (23),
localNodeTransmissionError (24),
remoteNodeTransmissionError (25),
routingFailure (26),
connectionEstablishmentError(22)、invalidMessageReceived(23)、localNodeTransmissionError(24)、remoteNodeTransmissionError(25)、routingFailure(26)
--Values 27-50 are reserved for communications alarm related --probable causes -- The following are used with equipment alarm.
--値27-50はアラームが話したコミュニケーション(推定原因)のために予約されて、以下が設備アラームと共に使用されるということです。
backplaneFailure (51),
dataSetProblem (52),
equipmentIdentifierDuplication (53),
externalIFDeviceProblem (54),
lineCardProblem (55),
multiplexerProblem (56),
nEIdentifierDuplication (57),
powerProblem (58),
processorProblem (59),
protectionPathFailure (60),
receiverFailure (61),
replaceableUnitMissing (62),
replaceableUnitTypeMismatch (63),
synchronizationSourceMismatch (64),
terminalProblem (65),
timingProblem (66),
transmitterFailure (67),
trunkCardProblem (68),
replaceableUnitProblem (69),
realTimeClockFailure (70),
--An equipment alarm to be issued if the system detects that the
--real time clock has failed
antennaFailure (71),
batteryChargingFailure (72),
diskFailure (73),
frequencyHoppingFailure (74),
iODeviceError (75),
lossOfSynchronisation (76),
lossOfRedundancy (77),
powerSupplyFailure (78),
signalQualityEvaluationFailure (79),
tranceiverFailure (80),
protectionMechanismFailure (81),
protectingResourceFailure (82),
-- Values 83-100 are reserved for equipment alarm related probable
-- causes
-- The following are used with environmental alarm.
airCompressorFailure (101),
backplaneFailure(51)、dataSetProblem(52)、equipmentIdentifierDuplication(53)、externalIFDeviceProblem(54)、lineCardProblem(55)、multiplexerProblem(56)、nEIdentifierDuplication(57)、powerProblem(58)、processorProblem(59)、protectionPathFailure(60)、receiverFailure(61)、replaceableUnitMissing(62)、replaceableUnitTypeMismatch(63)、synchronizationSourceMismatch(64)、terminalProblem(65)、timingProblem(66)、transmitterFailure(67)、trunkCardProblem(68); replaceableUnitProblem(69)、realTimeClockFailure(70)、--、発行される設備アラームがシステムであるならそれを検出する--リアルタイムクロックはantennaFailure(71)、batteryChargingFailure(72)、diskFailure(73)、frequencyHoppingFailure(74)、iODeviceError(75)、lossOfSynchronisation(76)、lossOfRedundancy(77)、powerSupplyFailure(78)、signalQualityEvaluationFailure(79)、tranceiverFailure(80)、protectionMechanismFailure(81)、protectingResourceFailure(82)に失敗しました; 値83-100はありえそうな状態で話された設備アラーム(原因)のために予約されます。 次の事柄は環境アラームairCompressorFailure(101)と共に使用されます。
Chisholm & Romascanu Standards Track [Page 42] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[42ページ]RFC3877はMIB2004年9月に驚かせます。
airConditioningFailure (102),
airDryerFailure (103),
batteryDischarging (104),
batteryFailure (105),
commercialPowerFailure (106),
coolingFanFailure (107),
engineFailure (108),
fireDetectorFailure (109),
fuseFailure (110),
generatorFailure (111),
lowBatteryThreshold (112),
pumpFailure (113),
rectifierFailure (114),
rectifierHighVoltage (115),
rectifierLowFVoltage (116),
ventilationsSystemFailure (117),
enclosureDoorOpen (118),
explosiveGas (119),
fire (120),
flood (121),
highHumidity (122),
highTemperature (123),
highWind (124),
iceBuildUp (125),
intrusionDetection (126),
lowFuel (127),
lowHumidity (128),
lowCablePressure (129),
lowTemperatue (130),
lowWater (131),
smoke (132),
toxicGas (133),
coolingSystemFailure (134),
externalEquipmentFailure (135),
externalPointFailure (136),
-- Values 137-150 are reserved for environmental alarm related
-- probable causes
-- The following are used with Processing error alarm.
storageCapacityProblem (151),
memoryMismatch (152),
corruptData (153),
outOfCPUCycles (154),
sfwrEnvironmentProblem (155),
sfwrDownloadFailure (156),
lossOfRealTimel (157),
--A processing error alarm to be issued after the system has
--reinitialised. This will indicate
--to the management systems that the view they have of the managed
airConditioningFailure(102)、airDryerFailure(103)、batteryDischarging(104)、batteryFailure(105)、commercialPowerFailure(106)、coolingFanFailure(107)、engineFailure(108)、fireDetectorFailure(109)、fuseFailure(110)、generatorFailure(111)、lowBatteryThreshold(112)、pumpFailure(113)、rectifierFailure(114)、rectifierHighVoltage(115)、rectifierLowFVoltage(116)、ventilationsSystemFailure(117); enclosureDoorOpen(118)、explosiveGas(119)、炎(120)、洪水(121)、highHumidity(122)、highTemperature(123)、highWind(124)、iceBuildUp(125)、intrusionDetection(126)、lowFuel(127)、lowHumidity(128)、lowCablePressure(129)、lowTemperatue(130)(lowWater(131))は(132)、toxicGas(133)、coolingSystemFailure(134)、externalEquipmentFailure(135)、externalPointFailure(136)を煙らせます; 値137-150は話された環境アラーム(推定原因)のために予約されて、以下がProcessing誤りアラームstorageCapacityProblem(151)と共に使用されます、memoryMismatch(152)、corruptData(153)、outOfCPUCycles(154)ということです。 sfwrEnvironmentProblem(155)、sfwrDownloadFailure(156)、lossOfRealTimel(157)--システムの後に発行される整理過程の誤差アラームは--reinitialisedを持っています。 これが示す、マネージメントシステム、それ、それらにはある管理の視点
Chisholm & Romascanu Standards Track [Page 43] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[43ページ]RFC3877はMIB2004年9月に驚かせます。
--system may no longer
--be valid. Usage example: The managed
--system issues this alarm after a reinitialization with severity
--warning to inform the
--management system about the event. No clearing notification will
--be sent.
applicationSubsystemFailure (158),
configurationOrCustomisationError (159),
databaseInconsistency (160),
fileError (161),
outOfMemory (162),
softwareError (163),
timeoutExpired (164),
underlayingResourceUnavailable (165),
versionMismatch (166),
--Values 168-200 are reserved for processing error alarm related
-- probable causes.
bandwidthReduced (201),
congestion (202),
excessiveErrorRate (203),
excessiveResponseTime (204),
excessiveRetransmissionRate (205),
reducedLoggingCapability (206),
systemResourcesOverload (207 ),
-- The following were defined X.733
adapterError (500),
applicationSubsystemFailture (501),
bandwidthReducedX733 (502),
callEstablishmentError (503),
communicationsProtocolError (504),
communicationsSubsystemFailure (505),
configurationOrCustomizationError (506),
congestionX733 (507),
coruptData (508),
cpuCyclesLimitExceeded (509),
dataSetOrModemError (510),
degradedSignalX733 (511),
dteDceInterfaceError (512),
enclosureDoorOpenX733 (513),
equipmentMalfunction (514),
excessiveVibration (515),
fileErrorX733 (516),
fireDetected (517),
framingErrorX733 (518),
heatingVentCoolingSystemProblem (519),
humidityUnacceptable (520),
inputOutputDeviceError (521),
inputDeviceError (522),
--システムはもうそうするかもしれません--有効であってください。 使用例: システムが再初期化の後に厳しさでこのアラームを発行するという知らせると警告する管理、--出来事に関するマネージメントシステム。 通知がそうするクリアしないこと--. applicationSubsystemFailure(158)を送ってください、configurationOrCustomisationError(159)、databaseInconsistency(160)、fileError(161)、outOfMemory(162)、softwareError(163)、timeoutExpired(164)、underlayingResourceUnavailable(165)、versionMismatch(166)--値168-200はアラームが関係づけた整理過程の誤差によって予約されます; 推定原因bandwidthReduced(201)、混雑(202)、excessiveErrorRate(203)、excessiveResponseTime(204)、excessiveRetransmissionRate(205)、reducedLoggingCapability(206)、systemResourcesOverload(207 ); ↓これは定義されたX.733 adapterError(500)でした、applicationSubsystemFailture(501)、bandwidthReducedX733(502)、callEstablishmentError(503)、communicationsProtocolError(504)、communicationsSubsystemFailure(505)、configurationOrCustomizationError(506)、congestionX733(507)、coruptData(508)、cpuCyclesLimitExceeded(509)、dataSetOrModemError(510)、degradedSignalX733(511)、dteDceInterfaceError(512)、enclosureDoorOpenX733(513)、equipmentMalf油を塗ること(514)、excessiveVibration(515)、fileErrorX733(516)、fireDetected(517)、framingErrorX733(518)、heatingVentCoolingSystemProblem(519)、humidityUnacceptable(520)、inputOutputDeviceError(521)、inputDeviceError(522)
Chisholm & Romascanu Standards Track [Page 44] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[44ページ]RFC3877はMIB2004年9月に驚かせます。
lanError (523),
leakDetected (524),
localNodeTransmissionErrorX733 (525),
lossOfFrameX733 (526),
lossOfSignalX733 (527),
materialSupplyExhausted (528),
multiplexerProblemX733 (529),
outOfMemoryX733 (530),
ouputDeviceError (531),
performanceDegraded (532),
powerProblems (533),
pressureUnacceptable (534),
processorProblems (535),
pumpFailureX733 (536),
queueSizeExceeded (537),
receiveFailureX733 (538),
receiverFailureX733 (539),
remoteNodeTransmissionErrorX733 (540),
resourceAtOrNearingCapacity (541),
responseTimeExecessive (542),
retransmissionRateExcessive (543),
softwareErrorX733 (544),
softwareProgramAbnormallyTerminated (545),
softwareProgramError (546),
storageCapacityProblemX733 (547),
temperatureUnacceptable (548),
thresholdCrossed (549),
timingProblemX733 (550),
toxicLeakDetected (551),
transmitFailureX733 (552),
transmiterFailure (553),
underlyingResourceUnavailable (554),
versionMismatchX733 (555),
-- The following are defined in X.736
authenticationFailure (600),
breachOfConfidentiality (601),
cableTamper (602),
delayedInformation (603),
denialOfService (604),
duplicateInformation (605),
informationMissing (606),
informationModificationDetected (607),
informationOutOfSequence (608),
keyExpired (609),
nonRepudiationFailure (610),
outOfHoursActivity (611),
outOfService (612),
proceduralError (613),
lanError(523)、leakDetected(524)、localNodeTransmissionErrorX733(525)、lossOfFrameX733(526)、lossOfSignalX733(527)、materialSupplyExhausted(528)、multiplexerProblemX733(529)、outOfMemoryX733(530)、ouputDeviceError(531)、performanceDegraded(532)、powerProblems(533)、pressureUnacceptable(534)、processorProblems(535)pumpFailureX733(536)、queueSizeExceeded(537)、receiveFailureX733(538)、receiverFailureX733(539)、remoteNodeTransmissionErrorX733(540); resourceAtOrNearingCapacity(541)、responseTimeExecessive(542)、retransmissionRateExcessive(543)、softwareErrorX733(544)、softwareProgramAbnormallyTerminated(545)、softwareProgramError(546)、storageCapacityProblemX733(547)、temperatureUnacceptable(548)、thresholdCrossed(549)、timingProblemX733(550)、toxicLeakDetected(551)、transmitFailureX733(552)、transmiterFailure(553)、underlyingResourceUnavailable(554)、versionMismatchX733(555); 以下はX.736 authenticationFailure(600)、breachOfConfidentiality(601)、cで定義されます。ableTamper(602)、delayedInformation(603)、denialOfService(604)、duplicateInformation(605)、informationMissing(606)、informationModificationDetected(607)、informationOutOfSequence(608)、keyExpired(609)、nonRepudiationFailure(610)、outOfHoursActivity(611)、outOfService(612)、proceduralError(613)
Chisholm & Romascanu Standards Track [Page 45] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[45ページ]RFC3877はMIB2004年9月に驚かせます。
unauthorizedAccessAttempt (614),
unexpectedInformation (615),
unauthorizedAccessAttempt(614)、unexpectedInformation(615)
other (1024)
}
他の(1024)
IANAItuEventType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The ITU event Type values.
IANAItuEventType:、:= 「ITUイベントTypeは評価する」TEXTUAL-CONVENTION STATUSの現在の記述。
The Internet Assigned Number Authority (IANA) is
responsible for the assignment of the enumerations
in this TC.
ISOCの機関の一つで(IANA)はこのTCの列挙の課題に責任があります。
Request should come in the form of well-formed
SMI [RFC2578] for enumeration names that are unique
and sufficiently descriptive.
要求はユニークで十分描写的である列挙名のためによく形成されたSMI[RFC2578]のフォームに入るべきです。
See http://www.iana.org "
REFERENCE
"ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
SYNTAX INTEGER
{
other (1),
communicationsAlarm (2),
qualityOfServiceAlarm (3),
processingErrorAlarm (4),
equipmentAlarm (5),
environmentalAlarm (6),
integrityViolation (7),
operationalViolation (8),
physicalViolation (9),
securityServiceOrMechanismViolation (10),
timeDomainViolation (11)
}
http://www.iana.org を見てください、「参照、「'情報技術--オープン・システム・インターコネクション--ITU推薦X.736、システム管理:、'、」 '「機能を報告して、セキュリティは驚かせる'1992年のインチ構文整数他の(1)、communicationsAlarm(2)、qualityOfServiceAlarm(3)、processingErrorAlarm(4)、equipmentAlarm(5)、environmentalAlarm(6)、integrityViolation(7)、operationalViolation(8)、physicalViolation(9)、securityServiceOrMechanismViolation(10)、timeDomainViolation(11)
END
終わり
Chisholm & Romascanu Standards Track [Page 46] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[46ページ]RFC3877はMIB2004年9月に驚かせます。
5.3. Textual Conventions
5.3. 原文のコンベンション
ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN
ITUアラームTc MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION
FROM SNMPv2-TC; -- [RFC2579]
IMPORTS MODULE-IDENTITY、mib-2 FROM SNMPv2-SMI--[RFC2578]TEXTUAL-CONVENTION FROM SNMPv2-TC。 -- [RFC2579]
ituAlarmTc MODULE-IDENTITY
LAST-UPDATED "200409090000Z" -- September 09, 2004
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
" WG EMail: disman@ietf.org
Subscribe: disman-request@ietf.org
http://www.ietf.org/html.charters/disman-charter.html
ituAlarmTcモジュールアイデンティティ最終更新日の"200409090000Z"--「WGは以下をメールする」という2004年9月9日組織「IETF分散管理作業部会」コンタクトインフォメーション disman@ietf.org は申し込まれます: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html
Chair: Randy Presuhn
randy_presuhn@mindspring.com
議長: ランディPresuhn randy_presuhn@mindspring.com
Editors: Sharon Chisholm
Nortel Networks
PO Box 3511 Station C
Ottawa, Ont. K1Y 4H7
Canada
schishol@nortelnetworks.com
エディターズ: シャロンチスホルムノーテルは私書箱3511駅のCオタワ、Ontをネットワークでつなぎます。 K1Y 4H7カナダ schishol@nortelnetworks.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com"
DESCRIPTION
"This MIB module defines the ITU Alarm
textual convention for objects not expected to require
regular extension.
ダンRomascanu Avaya Atidim技術公園、ビルディング #3 テルアビブ、61131イスラエルTel: +972-3-645-8414 メールしてください: " dromasca@avaya.com "記述、「このMIBモジュールは定期的な拡大を必要としないと予想された物のためにITUのAlarmの原文のコンベンションを定義します」。
Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC
itself. Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html"
REVISION "200409090000Z" -- September 09, 2004
DESCRIPTION
"Initial version, published as RFC 3877."
Copyright(C)インターネット協会(2004)。 このMIBモジュールの初期のバージョンはRFC3877で発行されました。 完全な法定の通知に関しては、RFC自身を見てください。 補助情報は以下で利用可能であるかもしれません。 " http://www.ietf.org/copyrights/ianamib.html "REVISION"200409090000Z"--「初期のバージョンであって、RFC3877として発行された」2004年9月9日記述。
Chisholm & Romascanu Standards Track [Page 47] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[47ページ]RFC3877はMIB2004年9月に驚かせます。
::= { mib-2 120 }
::= mib-2 120
ItuPerceivedSeverity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"ITU perceived severity values"
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992"
SYNTAX INTEGER
{
cleared (1),
indeterminate (2),
critical (3),
major (4),
minor (5),
warning (6)
}
ItuPerceivedSeverity:、:= TEXTUAL-CONVENTION STATUSの現在の記述「ITUは厳しさ値を知覚した」REFERENCE「ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733'情報技術--オープン・システム・インターコネクション--システム管理:、'、」 「アラーム'報告機能'、1992年のインチ構文整数(1)、不確定の(2)、批判的な(3)、少佐(4)、未成年者(5)、警告(6)をクリアします。
ItuTrendIndication ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"ITU trend indication values for alarms."
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992"
SYNTAX INTEGER
{
moreSevere (1),
noChange (2),
lessSevere (3)
}
ItuTrendIndication:、:= 「ITU傾向指示は. 」 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'というアラームREFERENCEのために評価する」TEXTUAL-CONVENTION STATUSの現在の記述 「アラーム'報告機能'、1992年のインチ構文整数moreSevere(1)、noChange(2)、lessSevere(3)
END
終わり
Chisholm & Romascanu Standards Track [Page 48] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[48ページ]RFC3877はMIB2004年9月に驚かせます。
5.4. Definitions
5.4. 定義
ITU-ALARM-MIB DEFINITIONS ::= BEGIN
ITUアラームMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Gauge32, mib-2
FROM SNMPv2-SMI -- [RFC2578]
AutonomousType, RowPointer
FROM SNMPv2-TC -- [RFC2579]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
alarmListName, alarmModelIndex,
alarmActiveDateAndTime, alarmActiveIndex
FROM ALARM-MIB -- [RFC3877]
ItuPerceivedSeverity,
ItuTrendIndication
FROM ITU-ALARM-TC-MIB -- [RFC3877]
IANAItuProbableCause,
IANAItuEventType
FROM IANA-ITU-ALARM-TC-MIB -- [RFC3877]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
ZeroBasedCounter32
FROM RMON2-MIB; -- [RFC2021]
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Gauge32、mib-2 FROM SNMPv2-SMI--RFC2578 AutonomousType、RowPointer FROM SNMPv2-TC--RFC2579 SnmpAdminString FROM SNMP-FRAMEWORK-MIB--RFC3411 alarmListName、alarmModelIndex、alarmActiveDateAndTime(alarmActiveIndex FROM ALARM-MIB); RFC3877 ItuPerceivedSeverity(ITUアラームTc MIB--IANA ITUアラームTc MIBからのRFC3877 IANAItuProbableCause、IANAItuEventType--RFC3877モジュールコンプライアンスからのItuTrendIndication)はSNMPv2-CONFから物で分類します--RMON2-MIBからのRFC2580 ZeroBasedCounter32 -- [RFC2021]
ituAlarmMIB MODULE-IDENTITY
LAST-UPDATED "200409090000Z" -- September 09, 2004
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO
"WG EMail: disman@ietf.org
Subscribe: disman-request@ietf.org
http://www.ietf.org/html.charters/disman-charter.html
ituAlarmMIBモジュールアイデンティティ最終更新日の"200409090000Z"--「WGは以下をメールする」という2004年9月9日組織「IETF分散管理作業部会」コンタクトインフォメーション disman@ietf.org は申し込まれます: disman-request@ietf.org http://www.ietf.org/html.charters/disman-charter.html
Chair: Randy Presuhn
randy_presuhn@mindspring.com
議長: ランディPresuhn randy_presuhn@mindspring.com
Editors: Sharon Chisholm
Nortel Networks
PO Box 3511 Station C
Ottawa, Ont. K1Y 4H7
Canada
schishol@nortelnetworks.com
エディターズ: シャロンチスホルムノーテルは私書箱3511駅のCオタワ、Ontをネットワークでつなぎます。 K1Y 4H7カナダ schishol@nortelnetworks.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
ダンRomascanu Avaya Atidim技術公園、ビルディング #3 テルアビブ、61131
Chisholm & Romascanu Standards Track [Page 49] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[49ページ]RFC3877はMIB2004年9月に驚かせます。
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com"
DESCRIPTION
"The MIB module describes ITU Alarm information
as defined in ITU Recommendation M.3100 [M.3100],
X.733 [X.733] and X.736 [X.736].
イスラエルTel: +972-3-645-8414 メールしてください: " dromasca@avaya.com "記述、「MIBモジュールはITU Recommendation M.3100[M.3100]、X.733[X.733]、およびX.736[X.736]で定義されるようにITU Alarm情報について説明します」。
Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC
itself. Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html"
REVISION "200409090000Z" -- September 09, 2004
DESCRIPTION
"Initial version, published as RFC 3877."
::= { mib-2 121 }
Copyright(C)インターネット協会(2004)。 このMIBモジュールの初期のバージョンはRFC3877で発行されました。 完全な法定の通知に関しては、RFC自身を見てください。 補助情報は以下で利用可能であるかもしれません。 " http://www.ietf.org/copyrights/ianamib.html "REVISION"200409090000Z"--「初期のバージョンであって、RFC3877として発行された」2004年9月9日記述。 ::= mib-2 121
ituAlarmObjects OBJECT IDENTIFIER ::= { ituAlarmMIB 1 }
ituAlarmObjects物の識別子:、:= ituAlarmMIB1
ituAlarmModel OBJECT IDENTIFIER ::= { ituAlarmObjects 1 }
ituAlarmModel物の識別子:、:= ituAlarmObjects1
ituAlarmActive OBJECT IDENTIFIER ::= { ituAlarmObjects 2 }
ituAlarmActive物の識別子:、:= ituAlarmObjects2
ituAlarmTable OBJECT-TYPE
SYNTAX SEQUENCE OF ItuAlarmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of ITU Alarm information for possible alarms
on the system."
::= { ituAlarmModel 1 }
ituAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「システムの上の可能なアラームのためのITU Alarm情報のテーブル。」 ::= ituAlarmModel1
ituAlarmEntry OBJECT-TYPE
SYNTAX ItuAlarmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table whenever an entry is created
in the alarmModelTable with a value of alarmModelState in
the range from 1 to 6. Entries disappear from this table
whenever the corresponding entries are deleted from the
alarmModelTable, including in cases where those entries
have been deleted due to local system action. The value of
alarmModelSpecificPointer has no effect on the creation
or deletion of entries in this table. Values of
alarmModelState map to values of ituAlarmPerceivedSeverity
as follows:
「alarmModelStateの値が1〜6までの範囲にある状態でalarmModelTableで作成されるときはいつも、エントリーはこのテーブルに現れる」ituAlarmEntry OBJECT-TYPE SYNTAX ItuAlarmEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 alarmModelTableから削除されるときはいつも、エントリーはこのテーブルから見えなくなります、ケースにそれらのエントリーがローカルシステム動作のためどこで削除されたかを含んでいて。 alarmModelSpecificPointerの値はこのテーブルでのエントリーの創造か削除のときに効き目がありません。 alarmModelStateの値は以下のituAlarmPerceivedSeverityの値に以下を写像します。
Chisholm & Romascanu Standards Track [Page 50] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[50ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelState -> ituAlarmPerceivedSeverity
1 -> clear (1)
2 -> indeterminate (2)
3 -> warning (6)
4 -> minor (5)
5 -> major (4)
6 -> critical (3)
明確な不確定のalarmModelState->ituAlarmPerceivedSeverity1の(2)3->警告->(1)2->(6)4の小さい方の(5)5->主要な(4)6->->批判的です。(3)
All other values of alarmModelState MUST NOT appear
in this table.
alarmModelStateの他のすべての値がこのテーブルに現れなければならないというわけではありません。
This table MUST be persistent across system reboots."
INDEX { alarmListName, alarmModelIndex,
ituAlarmPerceivedSeverity }
::= { ituAlarmTable 1 }
「このテーブルはシステムリブートの向こう側にしつこいに違いありません。」 alarmListName、alarmModelIndex、ituAlarmPerceivedSeverityに索引をつけてください:、:= ituAlarmTable1
ItuAlarmEntry ::= SEQUENCE {
ituAlarmPerceivedSeverity ItuPerceivedSeverity,
ituAlarmEventType IANAItuEventType,
ituAlarmProbableCause IANAItuProbableCause,
ituAlarmAdditionalText SnmpAdminString,
ituAlarmGenericModel RowPointer }
ItuAlarmEntry:、:= 系列ituAlarmPerceivedSeverity ItuPerceivedSeverity、ituAlarmEventType IANAItuEventType、ituAlarmProbableCause IANAItuProbableCause、ituAlarmAdditionalText SnmpAdminString、ituAlarmGenericModel RowPointer
ituAlarmPerceivedSeverity OBJECT-TYPE
SYNTAX ItuPerceivedSeverity
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"ITU perceived severity values."
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992"
::= { ituAlarmEntry 1 }
ituAlarmPerceivedSeverity OBJECT-TYPE SYNTAX ItuPerceivedSeverityのマックス-ACCESSのアクセスしやすくないSTATUSの現在の記述「厳しさ値であると知覚されたITU。」 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'に参照をつけてください、」 「'アラーム報告機能'、1992」:、:= ituAlarmEntry1
ituAlarmEventType OBJECT-TYPE
SYNTAX IANAItuEventType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Represents the event type values for the alarms"
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
マックス-ACCESSが「」 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'というアラームREFERENCEのためにイベントタイプ値を表す」とSTATUSの現在の記述に読書して書くituAlarmEventType OBJECT-TYPE SYNTAX IANAItuEventType アラーム
Chisholm & Romascanu Standards Track [Page 51] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[51ページ]RFC3877はMIB2004年9月に驚かせます。
Reporting Function', 1992
ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmEntry 2 }
'情報技術--オープン・システム・インターコネクション--'報告機能'、1992年のITU推薦X.736、システム管理:、' 「'警報機報告機能'、1992」:、:= ituAlarmEntry2
ituAlarmProbableCause OBJECT-TYPE
SYNTAX IANAItuProbableCause
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"ITU probable cause values."
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992
ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmEntry 3 }
ituAlarmProbableCause OBJECT-TYPE SYNTAX IANAItuProbableCauseマックス-ACCESSは「ITU推定原因値」をSTATUSの現在の記述に読書して書きます。 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'に参照をつけてください、」 '情報技術--オープン・システム・インターコネクション--'アラーム報告機能'、1992年のITU推薦X.736、システム管理:、' 「'警報機報告機能'、1992」:、:= ituAlarmEntry3
ituAlarmAdditionalText OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Represents the additional text field for the alarm."
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992"
::= { ituAlarmEntry 4}
マックス-ACCESSが「アラームのための追加テキストフィールドを表す」とSTATUSの現在の記述に読書して書くituAlarmAdditionalText OBJECT-TYPE SYNTAX SnmpAdminString。 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'に参照をつけてください、」 「'アラーム報告機能'、1992」:、:= ituAlarmEntry4
ituAlarmGenericModel OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object points to the corresponding
row in the alarmModelTable for this alarm severity.
ituAlarmGenericModel OBJECT-TYPE SYNTAX RowPointerマックス-ACCESSは「この物はこのアラームの厳しさのためにalarmModelTableの対応する列を示すこと」をSTATUSの現在の記述に読書して書きます。
This corresponding entry to alarmModelTable could also
be derived by performing the reverse of the mapping
from alarmModelState to ituAlarmPerceivedSeverity defined
また、マッピングのalarmModelStateから定義されたituAlarmPerceivedSeverityまでの逆を実行することによって、alarmModelTableへのこの対応するエントリーを引き出すことができるでしょう。
Chisholm & Romascanu Standards Track [Page 52] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[52ページ]RFC3877はMIB2004年9月に驚かせます。
in the description of ituAlarmEntry to determine the
appropriate { alarmListName, alarmModelIndex, alarmModelState }
for this { alarmListName, alarmModelIndex,
ituAlarmPerceivedSeverity }."
::= { ituAlarmEntry 5 }
「決定するituAlarmEntryの記述、これのためにalarmListName、alarmModelIndex、alarmModelStateを当ててください、alarmListName、alarmModelIndex、ituAlarmPerceivedSeverity、」 ::= ituAlarmEntry5
-- ITU Active Alarm Table --
-- ITUのアクティブなアラームテーブル--
ituAlarmActiveTable OBJECT-TYPE
SYNTAX SEQUENCE OF ItuAlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of ITU information for active alarms entries."
::= { ituAlarmActive 1 }
ituAlarmActiveTable OBJECT-TYPE SYNTAX SEQUENCE OF ItuAlarmActiveEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「活発なアラームエントリーのためのITU情報のテーブル。」 ::= ituAlarmActive1
ituAlarmActiveEntry OBJECT-TYPE
SYNTAX ItuAlarmActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries appear in this table when alarms are active. They
are removed when the alarm is no longer occurring."
INDEX { alarmListName, alarmActiveDateAndTime,
alarmActiveIndex }
::= { ituAlarmActiveTable 1 }
「アラームが活性であるときにエントリーはこのテーブルに現れる」ituAlarmActiveEntry OBJECT-TYPE SYNTAX ItuAlarmActiveEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「アラームがもう現れていないとき、それらを取り除きます。」 alarmListName、alarmActiveDateAndTime、alarmActiveIndexに索引をつけてください:、:= ituAlarmActiveTable1
ItuAlarmActiveEntry ::= SEQUENCE {
ituAlarmActiveTrendIndication ItuTrendIndication,
ituAlarmActiveDetector AutonomousType,
ituAlarmActiveServiceProvider AutonomousType,
ituAlarmActiveServiceUser AutonomousType
}
ItuAlarmActiveEntry:、:= 系列ituAlarmActiveTrendIndication ItuTrendIndication、ituAlarmActiveDetector AutonomousType、ituAlarmActiveServiceProvider AutonomousType、ituAlarmActiveServiceUser AutonomousType
ituAlarmActiveTrendIndication OBJECT-TYPE
SYNTAX ItuTrendIndication
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Represents the trend indication values for the alarms."
REFERENCE
"ITU Recommendation M.3100, 'Generic Network Information
Model', 1995
ITU Recommendation X.733, 'Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function', 1992"
::= { ituAlarmActiveEntry 1 }
ituAlarmActiveTrendIndication OBJECT-TYPE SYNTAX ItuTrendIndicationのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「. 」 「'情報技術--オープン・システム・インターコネクション--ITU推薦M.3100、'一般的なネットワーク情報はモデル化します'、1995ITU推薦X.733、システム管理'というアラームREFERENCEのために傾向指示値を表します」。 「'アラーム報告機能'、1992」:、:= ituAlarmActiveEntry1
Chisholm & Romascanu Standards Track [Page 53] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[53ページ]RFC3877はMIB2004年9月に驚かせます。
ituAlarmActiveDetector OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Represents the SecurityAlarmDetector object."
REFERENCE
"ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmActiveEntry 2 }
ituAlarmActiveDetector OBJECT-TYPE SYNTAX AutonomousTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「SecurityAlarmDetector物を表します」。 参照、「'情報技術--オープン・システム・インターコネクション--ITU推薦X.736、システム管理:、'、」 「'警報機報告機能'、1992」:、:= ituAlarmActiveEntry2
ituAlarmActiveServiceProvider OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Represents the ServiceProvider object."
REFERENCE
"ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmActiveEntry 3 }
ituAlarmActiveServiceProvider OBJECT-TYPE SYNTAX AutonomousTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「ServiceProvider物を表します」。 参照、「'情報技術--オープン・システム・インターコネクション--ITU推薦X.736、システム管理:、'、」 「'警報機報告機能'、1992」:、:= ituAlarmActiveEntry3
ituAlarmActiveServiceUser OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Represents the ServiceUser object."
REFERENCE
"ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmActiveEntry 4 }
ituAlarmActiveServiceUser OBJECT-TYPE SYNTAX AutonomousTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「ServiceUser物を表します」。 参照、「'情報技術--オープン・システム・インターコネクション--ITU推薦X.736、システム管理:、'、」 「'警報機報告機能'、1992」:、:= ituAlarmActiveEntry4
-- Statistics and Counters
-- 統計とカウンタ
ituAlarmActiveStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF ItuAlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table represents the ITU alarm statistics
information."
::= { ituAlarmActive 2 }
ituAlarmActiveStatsTable OBJECT-TYPEのSYNTAX SEQUENCE OF ItuAlarmActiveStatsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルはITUアラーム統計情報を表します」。 ::= ituAlarmActive2
Chisholm & Romascanu Standards Track [Page 54] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[54ページ]RFC3877はMIB2004年9月に驚かせます。
ituAlarmActiveStatsEntry OBJECT-TYPE
SYNTAX ItuAlarmActiveStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics on the current active ITU alarms."
INDEX { alarmListName }
. ituAlarmActiveStatsEntry OBJECT-TYPE SYNTAX ItuAlarmActiveStatsEntryのマックス-ACCESSのアクセスしやすくないSTATUSの現在の記述「現在の活動的なITUにおける統計は驚かせ」INDEXalarmListName
::= { ituAlarmActiveStatsTable 1 }
::= ituAlarmActiveStatsTable1
ItuAlarmActiveStatsEntry ::=
SEQUENCE {
ituAlarmActiveStatsIndeterminateCurrent Gauge32,
ituAlarmActiveStatsCriticalCurrent Gauge32,
ituAlarmActiveStatsMajorCurrent Gauge32,
ituAlarmActiveStatsMinorCurrent Gauge32,
ituAlarmActiveStatsWarningCurrent Gauge32,
ituAlarmActiveStatsIndeterminates ZeroBasedCounter32,
ituAlarmActiveStatsCriticals ZeroBasedCounter32,
ituAlarmActiveStatsMajors ZeroBasedCounter32,
ituAlarmActiveStatsMinors ZeroBasedCounter32,
ituAlarmActiveStatsWarnings ZeroBasedCounter32
}
ItuAlarmActiveStatsEntry:、:= 系列ituAlarmActiveStatsIndeterminateCurrent Gauge32、ituAlarmActiveStatsCriticalCurrent Gauge32、ituAlarmActiveStatsMajorCurrent Gauge32、ituAlarmActiveStatsMinorCurrent Gauge32、ituAlarmActiveStatsWarningCurrent Gauge32、ituAlarmActiveStatsIndeterminates ZeroBasedCounter32、ituAlarmActiveStatsCriticals ZeroBasedCounter32、ituAlarmActiveStatsMajors ZeroBasedCounter32、ituAlarmActiveStatsMinors ZeroBasedCounter32、ituAlarmActiveStatsWarnings ZeroBasedCounter32
ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the current number of active alarms with a
ituAlarmPerceivedSeverity of indeterminate."
::= { ituAlarmActiveStatsEntry 1 }
「アクティブの最新号のカウントは不確定のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry1
ituAlarmActiveStatsCriticalCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the current number of active alarms with a
ituAlarmPerceivedSeverity of critical."
::= { ituAlarmActiveStatsEntry 2 }
「アクティブの最新号のカウントは批判的のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsCriticalCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry2
ituAlarmActiveStatsMajorCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the current number of active alarms with a
「アクティブの最新号のカウントはaで驚かせる」ituAlarmActiveStatsMajorCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Chisholm & Romascanu Standards Track [Page 55] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[55ページ]RFC3877はMIB2004年9月に驚かせます。
ituAlarmPerceivedSeverity of major."
::= { ituAlarmActiveStatsEntry 3 }
「少佐のituAlarmPerceivedSeverity。」 ::= ituAlarmActiveStatsEntry3
ituAlarmActiveStatsMinorCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the current number of active alarms with a
ituAlarmPerceivedSeverity of minor."
::= { ituAlarmActiveStatsEntry 4 }
「アクティブの最新号のカウントは未成年者のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsMinorCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry4
ituAlarmActiveStatsWarningCurrent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the current number of active alarms with a
ituAlarmPerceivedSeverity of warning."
::= { ituAlarmActiveStatsEntry 5 }
「アクティブの最新号のカウントは警告のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsWarningCurrent OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry5
ituAlarmActiveStatsIndeterminates OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of active alarms with a
ituAlarmPerceivedSeverity of indeterminate since system
restart."
::= { ituAlarmActiveStatsEntry 6 }
「アクティブの総数のカウントはシステムリスタート以来の不確定のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsIndeterminates OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry6
ituAlarmActiveStatsCriticals OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of active alarms with a
ituAlarmPerceivedSeverity of critical since system restart."
::= { ituAlarmActiveStatsEntry 7 }
「アクティブの総数のカウントは批判的のシステムリスタート以来ituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsCriticals OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry7
ituAlarmActiveStatsMajors OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of active alarms with a
ituAlarmPerceivedSeverity of major since system restart."
::= { ituAlarmActiveStatsEntry 8 }
「システムリスタート以来アクティブの総数のカウントは少佐のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsMajors OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry8
Chisholm & Romascanu Standards Track [Page 56] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[56ページ]RFC3877はMIB2004年9月に驚かせます。
ituAlarmActiveStatsMinors OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of active alarms with a
ituAlarmPerceivedSeverity of minor since system restart."
::= { ituAlarmActiveStatsEntry 9 }
「システムリスタート以来アクティブの総数のカウントは未成年者のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsMinors OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry9
ituAlarmActiveStatsWarnings OBJECT-TYPE
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of active alarms with a
ituAlarmPerceivedSeverity of warning since system restart."
::= { ituAlarmActiveStatsEntry 10 }
「システムリスタート以来アクティブの総数のカウントは警告のituAlarmPerceivedSeverityと共に驚かせる」ituAlarmActiveStatsWarnings OBJECT-TYPE SYNTAX ZeroBasedCounter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ituAlarmActiveStatsEntry10
-- Conformance
-- 順応
ituAlarmConformance OBJECT IDENTIFIER ::= { ituAlarmMIB 2 }
ituAlarmCompliances OBJECT IDENTIFIER ::= { ituAlarmConformance 1 }
ituAlarmConformance物の識別子:、:= ituAlarmMIB2ituAlarmCompliances物の識別子:、:= ituAlarmConformance1
ituAlarmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems supporting
the ITU Alarm MIB."
MODULE -- this module
MANDATORY-GROUPS {
ituAlarmGroup
}
GROUP ituAlarmServiceUserGroup
DESCRIPTION
"This group is optional."
GROUP ituAlarmSecurityGroup
DESCRIPTION
"This group is optional."
GROUP ituAlarmStatisticsGroup
DESCRIPTION
"This group is optional."
::= { ituAlarmCompliances 1 }
ituAlarmCompliance MODULE-COMPLIANCE STATUSの現在の記述、「ITU Alarm MIBを支持するシステムのための承諾声明。」 MODULE--、このモジュールMANDATORY-GROUPS ituAlarmGroup、GROUP ituAlarmServiceUserGroup記述、「このグループは任意です」。 GROUP ituAlarmSecurityGroup記述、「このグループは任意です」。 GROUP ituAlarmStatisticsGroup記述、「このグループは任意です」。 ::= ituAlarmCompliances1
ituAlarmGroups OBJECT IDENTIFIER ::= { ituAlarmConformance 2 }
ituAlarmGroups物の識別子:、:= ituAlarmConformance2
ituAlarmGroup OBJECT-GROUP
OBJECTS {
ituAlarmEventType,
ituAlarmGroup物群対象、ituAlarmEventType
Chisholm & Romascanu Standards Track [Page 57] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[57ページ]RFC3877はMIB2004年9月に驚かせます。
ituAlarmProbableCause,
ituAlarmGenericModel
}
STATUS current
DESCRIPTION
"ITU alarm details list group."
::= { ituAlarmGroups 1}
ituAlarmProbableCause、ituAlarmGenericModel 「ITUアラーム詳細リストは分類する」STATUSの現在の記述。 ::= ituAlarmGroups1
ituAlarmServiceUserGroup OBJECT-GROUP
OBJECTS {
ituAlarmAdditionalText,
ituAlarmActiveTrendIndication
}
STATUS current
DESCRIPTION
"The use of these parameters is a service-user option."
::= { ituAlarmGroups 2 }
ituAlarmServiceUserGroup OBJECT-GROUP OBJECTS、ituAlarmAdditionalText、ituAlarmActiveTrendIndication、STATUSの現在の記述、「これらのパラメタの使用はサービス利用者オプションです」。 ::= ituAlarmGroups2
ituAlarmSecurityGroup OBJECT-GROUP
OBJECTS {
ituAlarmActiveDetector,
ituAlarmActiveServiceProvider,
ituAlarmActiveServiceUser
}
STATUS current
DESCRIPTION
"Security Alarm Reporting Function"
REFERENCE
"ITU Recommendation X.736, 'Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function', 1992"
::= { ituAlarmGroups 3 }
ituAlarmSecurityGroup OBJECT-GROUP OBJECTS、ituAlarmActiveDetector、ituAlarmActiveServiceProvider、ituAlarmActiveServiceUser、STATUSの現在の記述「警報機報告機能」REFERENCE、「'情報技術--オープン・システム・インターコネクション--ITU推薦X.736、システム管理:、'、」 「'警報機報告機能'、1992」:、:= ituAlarmGroups3
ituAlarmStatisticsGroup OBJECT-GROUP
OBJECTS {
ituAlarmActiveStatsIndeterminateCurrent,
ituAlarmActiveStatsCriticalCurrent,
ituAlarmActiveStatsMajorCurrent,
ituAlarmActiveStatsMinorCurrent,
ituAlarmActiveStatsWarningCurrent,
ituAlarmActiveStatsIndeterminates,
ituAlarmActiveStatsCriticals,
ituAlarmActiveStatsMajors,
ituAlarmActiveStatsMinors,
ituAlarmActiveStatsWarnings
}
STATUS current
DESCRIPTION
ituAlarmStatisticsGroup OBJECT-GROUP OBJECTS、ituAlarmActiveStatsIndeterminateCurrent、ituAlarmActiveStatsCriticalCurrent、ituAlarmActiveStatsMajorCurrent、ituAlarmActiveStatsMinorCurrent、ituAlarmActiveStatsWarningCurrent、ituAlarmActiveStatsIndeterminates、ituAlarmActiveStatsCriticals、ituAlarmActiveStatsMajors、ituAlarmActiveStatsMinors、ituAlarmActiveStatsWarnings、STATUSの現在の記述
Chisholm & Romascanu Standards Track [Page 58] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[58ページ]RFC3877はMIB2004年9月に驚かせます。
"ITU Active Alarm Statistics."
::= { ituAlarmGroups 4 }
「ITUのアクティブなアラーム統計。」 ::= ituAlarmGroups4
END
終わり
6. Examples
6. 例
6.1. Alarms Based on linkUp/linkDown Notifications
6.1. 結合/linkDown通知に基づくアラーム
This example demonstrates an interface-based alarm that goes into a state of "warning" when a linkDown Notification [RFC2863] occurs but the ifAdminStatus indicates the interface was taken down administratively. If IfAdminStatus is "up" when the linkDown Notification occurs, then there is a problem, so the state of the alarm is critical. A linkUp alarm clears the alarm.
この例はいつlinkDown Notification[RFC2863]が起こりますが、ifAdminStatusが、インタフェースが行政上降ろされたのを示すかを「警告」である状態に入るインタフェースベースのアラームのデモをします。 問題がlinkDown Notificationが起こるとき、IfAdminStatusが“up"であるならあるので、アラームの状態はきわどいです。 linkUpアラームはアラームをきれいにします。
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
""
::= { snmpTraps 3 }
linkDown NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「「:、:、」= snmpTraps3
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
""
::= { snmpTraps 4 }
linkUp NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「「:、:、」= snmpTraps4
alarmModelIndex 3 alarmModelState 1 alarmModelNotificationId linkUp alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "linkUp" alarmModelSpecificPointer ituAlarmEntry.3.1 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.3.1
alarmModelIndex3alarmModelState1alarmModelNotificationId linkUp alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「結合」alarmModelSpecificPointer ituAlarmEntry.3.1 alarmModelVarbindSubtree ifIndex、(1.3.6.1.2.1.2.2.1.1)alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType communicationsAlarm(2)ituAlarmPerceivedSeverityは(1) ituAlarmGenericModel alarmModelEntry.3.1を儲けました。
alarmModelIndex 3 alarmModelState 2 alarmModelNotificationId linkDown alarmModelVarbindIndex 2
alarmModelIndex3alarmModelState2alarmModelNotificationId linkDown alarmModelVarbindIndex2
Chisholm & Romascanu Standards Track [Page 59] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[59ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelVarbindValue down (2) alarmModelDescription "linkDown administratively" alarmModelSpecificPointer ituAlarmEntry.3.6 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity warning (6) ituAlarmGenericModel alarmModelEntry.3.2
alarmModelVarbindValue下に(2)alarmModelDescription、「linkDown、行政上、」 alarmModelSpecificPointer ituAlarmEntry.3.6 alarmModelVarbindSubtree ifIndex、(1.3.6.1.2.1.2.2.1.1)alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType communicationsAlarm(2)ituAlarmPerceivedSeverity警告(6)ituAlarmGenericModel alarmModelEntry.3.2
alarmModelIndex 3 alarmModelState 3 alarmModelNotificationId linkDown alarmModelVarbindIndex 2 alarmModelVarbindValue up (1) alarmModelDescription "linkDown - confirmed problem" alarmModelSpecificPointer ituAlarmEntry.3.3 alarmModelVarbindSubtree ifIndex (1.3.6.1.2.1.2.2.1.1) alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.3.3
(1) alarmModelDescription「linkDown--問題を確認する」alarmModelSpecificPointer ituAlarmEntry.3.3 alarmModelVarbindSubtree ifIndexへのalarmModelIndex3alarmModelState3alarmModelNotificationId linkDown alarmModelVarbindIndex2alarmModelVarbindValue、(1.3.6.1.2.1.2.2.1.1)alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType communicationsAlarm(2)ituAlarmPerceivedSeverity重要な(3)ituAlarmGenericModel alarmModelEntry.3.3
alarmActiveIndex 1 alarmActiveDateAndTime 2342464573 alarmActiveDateAndTime DateAndTime, alarmActiveEngineID SnmpEngineID, alarmActiveEngineAddressType ipV4 alarmActiveEngineAddress 10.10.10.10 alarmActiveContextName SnmpAdminString, alarmActiveVariables 3 alarmActiveNotificationID 1.3.6.1.6.3.1.1.5.3 alarmActiveResourceId 1.3.6.1.2.1.2.2.1.1.346 alarmActiveLogPointer 0.0 alarmActiveModelPointer alarmModelEntry.3.3 alarmActiveSpecificPointer ituAlarmActiveEntry.1.3 ituAlarmActiveTrendIndication moreSevere (1) ituAlarmDetector 0.0 ituAlarmServiceProvider 0.0 ituAlarmServiceUser 0.0
alarmActiveIndex1alarmActiveDateAndTime2342464573alarmActiveDateAndTime DateAndTime、alarmActiveEngineID SnmpEngineID、alarmActiveEngineAddressType ipV4 alarmActiveEngineAddress10.10.10、.10alarmActiveContextName SnmpAdminString、alarmActiveVariables3alarmActiveNotificationID1.3.6、.1 .6; 3.1.1.5.3 alarmActiveResourceId1.3.6.1.2.1.2.2.1.1.346alarmActiveLogPointer0.0alarmActiveModelPointer alarmModelEntry.3.3 alarmActiveSpecificPointer ituAlarmActiveEntry.1.3 ituAlarmActiveTrendIndication moreSevere(1)ituAlarmDetector0.0ituAlarmServiceProvider0.0ituAlarmServiceUser0.0
alarmActiveVariableIndex 1 alarmActiveVariableID sysUpTime.0 alarmActiveVariableValueType timeTicks(3) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 46754
alarmActiveVariableIndex1alarmActiveVariableID sysUpTime.0 alarmActiveVariableValueType timeTicks(3) alarmActiveVariableCounter32Val0alarmActiveVariableUnsigned32Val0alarmActiveVariableTimeTicksVal46754
Chisholm & Romascanu Standards Track [Page 60] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[60ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveVariableInteger32Val 0 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 2 alarmActiveVariableID snmpTrapOID.0 alarmActiveVariableValueType objectId(7) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val 0 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 1.3.6.1.6.3.1.1.5.3 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 3 alarmActiveVariableID ifIndex alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val 346 alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 4 alarmActiveVariableID ifAdminStatus alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val up (1) alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0 alarmActiveVariableCounter64Val 0 alarmActiveVariableIndex 5 alarmActiveVariableID ifOperStatus alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val 0 alarmActiveVariableUnsigned32Val 0 alarmActiveVariableTimeTicksVal 0 alarmActiveVariableInteger32Val down(2) alarmActiveVariableOctetStringVal "" alarmActiveVariableIpAddressVal 0 alarmActiveVariableOidVal 0.0
alarmActiveVariableInteger32Val0alarmActiveVariableOctetStringVal、「「alarmActiveVariableIpAddressVal0alarmActiveVariableOidVal0.0alarmActiveVariableCounter64Val0alarmActiveVariableIndex2alarmActiveVariableID snmpTrapOID.0 alarmActiveVariableValueType objectId(7) alarmActiveVariableCounter32Val0alarmActiveVariableUnsigned32Val0alarmActiveVariableTimeTicksVal0alarmActiveVariableInteger32Val0alarmActiveVariableOctetStringVal、「「alarmActiveVariableIpAddressVal0alarmActiveVariableOidVal1.3。」; 6.1.6.3.1.1.5.3 alarmActiveVariableCounter64Val0alarmActiveVariableIndex3alarmActiveVariableID ifIndex alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val0alarmActiveVariableUnsigned32Val0alarmActiveVariableTimeTicksVal0alarmActiveVariableInteger32Val346alarmActiveVariableOctetStringVal、「「alarmActiveVariableIpAddressVal0alarmActiveVariableOidVal0.0alarmActiveVariableCounter64Val0alarmActiveVariableIndex4alarmActiveVariableID ifAdminStatus alarmActiveVariableValu」(1) alarmActiveVariableOctetStringValへのeType integer32(4) alarmActiveVariableCounter32Val0alarmActiveVariableUnsigned32Val0alarmActiveVariableTimeTicksVal0alarmActiveVariableInteger32Val、「「alarmActiveVariableIpAddressVal0alarmActiveVariableOidVal0。」; (2) alarmActiveVariableOctetStringValの下側への0alarmActiveVariableCounter64Val0alarmActiveVariableIndex5alarmActiveVariableID ifOperStatus alarmActiveVariableValueType integer32(4) alarmActiveVariableCounter32Val0alarmActiveVariableUnsigned32Val0alarmActiveVariableTimeTicksVal0alarmActiveVariableInteger32Val、「「alarmActiveVariableIpAddressVal0alarmActiveVariableOidVal0.0」
Chisholm & Romascanu Standards Track [Page 61] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[61ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveVariableCounter64Val 0 alarmActiveVariableOpaqueVal
alarmActiveVariableCounter64Val0alarmActiveVariableOpaqueVal
6.2. Temperature Alarms Using Generic Notifications
6.2. 一般的な通知を使用する温度アラーム
Consider a system able to detect four different temperature states for a widget - normal, minor, major, critical. The system does not have any Notification definitions for these alarm states. A temperature alarm can be modelled using the generic alarm Notifications of alarmClearState and alarmActive.
システムがウィジェットのために4つの異なった温度州を検出できると考えてください--正常で、小さい方的で、主要で、批判的です。 システムには、これらのアラーム州との少しのNotification定義もありません。 alarmClearStateとalarmActiveの一般的なアラームNotificationsを使用することで温度アラームをモデル化できます。
alarmModelIndex 5 alarmModelState 1 alarmModelNotificationId alarmClearState alarmModelVarbindIndex 2 alarmModelVarbindValue cleared (1) alarmModelDescription "Acme Widget Temperature Normal" alarmModelSpecificPointer ituAlarmEntry.5.1 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.5.1
alarmModelIndex5alarmModelState1alarmModelNotificationId alarmClearState alarmModelVarbindIndex2alarmModelVarbindValueクリアされた(1)alarmModelDescription「頂上ウィジェット温度標準」alarmModelSpecificPointer ituAlarmEntry.5.1 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverityは(1) ituAlarmGenericModel alarmModelEntry.5.1を儲けました。
alarmModelIndex 5 alarmModelState 2 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue minor (5) alarmModelDescription "Acme Widget Temperature Minor" alarmModelSpecificPointer ituAlarmEntry.5.5 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventState environmentalAlarm (6) ituPerceivedSeverity minor (5) ituAlarmGenericModel alarmModelEntry.5.2
小さい方のalarmModelIndex5alarmModelState2alarmModelNotificationId alarmActiveState alarmModelVarbindIndex2の(5)alarmModelDescription alarmModelVarbindValue「頂上ウィジェット温度副専攻」alarmModelSpecificPointer ituAlarmEntry.5.5 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventState environmentalAlarm(6)ituPerceivedSeverity未成年者(5)ituAlarmGenericModel alarmModelEntry.5.2
alarmModelIndex 5 alarmModelState 3 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue major (4) alarmModelDescription "Acme Widget Temperature Major" alarmModelSpecificPointer ituAlarmEntry.5.4 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0
alarmModelIndex5alarmModelState3alarmModelNotificationId alarmActiveState alarmModelVarbindIndex2alarmModelVarbindValue少佐(4)alarmModelDescription「頂上ウィジェット温度専攻」alarmModelSpecificPointer ituAlarmEntry.5.4 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix0.0
Chisholm & Romascanu Standards Track [Page 62] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[62ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity major (4) ituAlarmGenericModel alarmModelEntry.5.3 alarmModelIndex 5 alarmModelState 4 alarmModelNotificationId alarmActiveState alarmModelVarbindIndex 2 alarmModelVarbindValue critical (3) alarmModelDescription "Acme Widget Temperature Critical" alarmModelSpecificPointer ituAlarmEntry.5.3 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.5.4
アクティブなalarmModelRowStatusの主要な(4)ituAlarmGenericModel alarmModelEntry.5.3 alarmModelIndex5alarmModelState4alarmModelNotificationId alarmActiveState alarmModelVarbindIndex2alarmModelVarbindValue重要な(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverity(3)のalarmModelDescriptionの「頂上ウィジェット温度重要な」alarmModelSpecificPointer ituAlarmEntry; 5.3 alarmModelVarbindSubtree alarmActiveResourceId alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverity重要な(3)ituAlarmGenericModel alarmModelEntry.5.4
6.3. Temperature Alarms Without Notifications
6.3. 通知のない温度アラーム
Consider a system able to detect four different temperature states for a widget - normal, minor, major, critical. The system does not have any Notification definitions for these alarm states. A temperature alarm can be modelled without specifying any Notifications in the alarm model. When a temperature state other than normal is detected, an instance of this alarm would be added to the active alarm table, but no Notifications would be sent out.
システムがウィジェットのために4つの異なった温度州を検出できると考えてください--正常で、小さい方で、主要で、重要です。 システムには、これらのアラーム州との少しのNotification定義もありません。 アラームモデルのどんなNotificationsも指定しないで、温度アラームをモデル化できます。 標準以外の温度状態を検出するとき、アクティブなアラームテーブルにこのアラームのインスタンスを加えるでしょうが、Notificationsを全く出さないでしょう。
This could alternatively be accomplished using the models from example 6.2 and by not specifying any target managers in the SNMP- TARGET-MIB, which would allow the alarm state Notifications to be logged in the Notification Log while still preventing Notifications from being transmitted on the wire.
あるいはまた、例6.2とSNMP- TARGET-MIBのどんな目標マネージャも指定しないことによってモデルを使用することでこれを達成できるでしょう。Notificationsがワイヤの上に伝えられるのをまだ防いでいる間、SNMP- TARGET-MIBは、アラーム州のNotificationsがNotification Logに登録されるのを許容するでしょう。
alarmModelIndex 6 alarmModelState 1 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.1 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.6.1
alarmModelIndex6alarmModelState1alarmModelNotificationId0.0alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「ウィジェット温度」alarmModelSpecificPointer ituAlarmEntry.6.1 alarmModelVarbindSubtree0.0alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverityは(1) ituAlarmGenericModel alarmModelEntry.6.1を儲けました。
Chisholm & Romascanu Standards Track [Page 63] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[63ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelIndex 6 alarmModelState 2 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.5 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventState environmentalAlarm (6) ituAlarmPerceivedSeverity minor (5) ituAlarmGenericModel alarmModelEntry.6.2
alarmModelIndex6alarmModelState2alarmModelNotificationId0.0alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「ウィジェット温度」alarmModelSpecificPointer ituAlarmEntry.6.5 alarmModelVarbindSubtree0.0alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventState environmentalAlarm(6)ituAlarmPerceivedSeverity未成年者(5)ituAlarmGenericModel alarmModelEntry.6.2
alarmModelIndex 6 alarmModelState 3 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature" alarmModelSpecificPointer ituAlarmEntry.6.4 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity major (4) ituAlarmGenericModel alarmModelEntry.6.3
alarmModelIndex6alarmModelState3alarmModelNotificationId0.0alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「ウィジェット温度」alarmModelSpecificPointer ituAlarmEntry.6.4 alarmModelVarbindSubtree0.0alarmModelResourcePrefix0.0alarmModelRowStatus活発な(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverity少佐(4)ituAlarmGenericModel alarmModelEntry.6.3
alarmModelIndex 6 alarmModelState 4 alarmModelNotificationId 0.0 alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Widget Temperature Severe" alarmModelSpecificPointer ituAlarmEntry.6.3 alarmModelVarbindSubtree 0.0 alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1) ituAlarmEventType environmentalAlarm (6) ituPerceivedSeverity critical (3) ituAlarmGenericModel alarmModelEntry.6.4
alarmModelIndex6alarmModelState4alarmModelNotificationId0.0alarmModelVarbindIndex0alarmModelVarbindValue0のalarmModelDescriptionの「ウィジェット温度厳しい」alarmModelSpecificPointer ituAlarmEntry.6.3 alarmModelVarbindSubtree0.0alarmModelResourcePrefix0.0のalarmModelRowStatusのアクティブな(1)ituAlarmEventType environmentalAlarm(6)ituPerceivedSeverity重要な(3)ituAlarmGenericModel alarmModelEntry.6.4
Chisholm & Romascanu Standards Track [Page 64] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[64ページ]RFC3877はMIB2004年9月に驚かせます。
6.4. Printer MIB Alarm Example
6.4. プリンタMIBアラームの例
Consider the following Notifications defined in the printer MIB [RFC3805]:
以下のNotificationsがプリンタでMIB[RFC3805]を定義したと考えてください:
prtAlertSeverityLevel OBJECT-TYPE
-- This value is a type 1 enumeration
SYNTAX INTEGER {
other(1),
critical(3),
warning(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The level of severity of this alert table entry. The printer
determines the severity level assigned to each entry into the
table."
::= { prtAlertEntry 2 }
タイプの1つの列挙のSYNTAX INTEGERは他の(1)、重要な(3)、警告(4)です。prtAlertSeverityLevel OBJECT-TYPE--、この値、「この厳しさのレベルはテーブル項目を警告する」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「プリンタは各エントリーに割り当てられた厳しさレベルをテーブルに決定します。」 ::= prtAlertEntry2
printerV2Alert NOTIFICATION-TYPE
OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
STATUS current
DESCRIPTION
"This trap is sent whenever a critical event is added to the
prtAlertTable."
::= { printerV2AlertPrefix 1 }
printerV2Alert NOTIFICATION-TYPE OBJECTS、prtAlertIndex、prtAlertSeverityLevel、prtAlertGroup、prtAlertGroupIndex、prtAlertLocation、prtAlertCode、「重要なイベントがprtAlertTableに加えられるときはいつも、この罠を送る」STATUSの現在の記述。 ::= printerV2AlertPrefix1
These Notifications can be used to model a printer alarm as follows:
以下のプリンタアラームをモデル化するのにこれらのNotificationsを使用できます:
alarmModelIndex 9 alarmModelState 1 alarmModelNotificationId alarmClearState alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelIndex9alarmModelState1alarmModelNotificationId alarmClearState alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「プリンタアラーム」alarmModelSpecificPointer0.0alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix0.0alarmModelRowStatusアクティブです。(1)
alarmModelIndex 9 alarmModelState 2 alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue warning (4) alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelIndex9alarmModelState2alarmModelNotificationId printerV2Alert alarmModelVarbindIndex2alarmModelVarbindValue警告(4)alarmModelDescription「プリンタアラーム」alarmModelSpecificPointer0.0alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix0.0alarmModelRowStatusアクティブです。(1)
alarmModelIndex 9 alarmModelState 3
alarmModelIndex9alarmModelState3
Chisholm & Romascanu Standards Track [Page 65] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[65ページ]RFC3877はMIB2004年9月に驚かせます。
alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue other (1) alarmModelDescription "Printer Alarm - unknown severity" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelNotificationId printerV2Alert alarmModelVarbindIndex2alarmModelVarbindValue他の(1)alarmModelDescription、「プリンタAlarm--、未知の厳しさ、」 alarmModelSpecificPointer0.0alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix0.0alarmModelRowStatus能動態(1)
alarmModelIndex 9 alarmModelState 4 alarmModelNotificationId printerV2Alert alarmModelVarbindIndex 2 alarmModelVarbindValue critical (3) alarmModelDescription "Printer Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelIndex9alarmModelState4alarmModelNotificationId printerV2Alert alarmModelVarbindIndex2のalarmModelVarbindValueの重要な(3)alarmModelDescription「プリンタアラーム」alarmModelSpecificPointer0.0alarmModelVarbindSubtree prtAlertGroup alarmModelResourcePrefix0.0alarmModelRowStatusアクティブです。(1)
6.5. RMON Alarm Example
6.5. RMONアラームの例
The RMON MIB [RFC2819] defines a mechanism for generating threshold alarms. When the thresholds are crossed, RisingAlarm and FallingAlarm Notifications are generated as appropriate. These Notifications can be used to model an upper threshold alarm as follows:
RMON MIB[RFC2819]は、敷居アラームを生成するためにメカニズムを定義します。敷居が交差しているとき、RisingAlarmとFallingAlarm Notificationsは適宜生成されます。 以下の上側の敷居アラームをモデル化するのにこれらのNotificationsを使用できます:
alarmModelIndex 6 alarmModelState 1 alarmModelNotificationId FallingAlarm alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "RMON Rising Clear Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelIndex6alarmModelState1alarmModelNotificationId FallingAlarm alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「RMONの上昇している明確なアラーム」alarmModelSpecificPointer0.0alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix0.0alarmModelRowStatusアクティブです。(1)
alarmModelIndex 6 alarmModelState 2 alarmModelNotificationId RisingAlarm alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "RMON Rising Alarm" alarmModelSpecificPointer 0.0 alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix 0.0 alarmModelRowStatus active (1)
alarmModelIndex6alarmModelState2alarmModelNotificationId RisingAlarm alarmModelVarbindIndex0alarmModelVarbindValue0alarmModelDescription「RMONの上昇しているアラーム」alarmModelSpecificPointer0.0alarmModelVarbindSubtree alarmIndex alarmModelResourcePrefix0.0alarmModelRowStatusアクティブです。(1)
Chisholm & Romascanu Standards Track [Page 66] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[66ページ]RFC3877はMIB2004年9月に驚かせます。
6.6. The Lifetime of an Alarm
6.6. アラームの生涯
The following example demonstrates the relationship between the active alarm table, the clear alarm table and the Notification Log MIB.
以下の例はアクティブなアラームテーブルと、明確なアラームテーブルとNotification Log MIBとの関係を示します。
Consider a system with alarms modelled as in example 1 and which also supports the informational Notification dsx3LineStatusChange.
例1のようにモデル化されたアラームがあるまた、情報のNotification dsx3LineStatusChangeをサポートするシステムを考えてください。
dsx3LineStatusChange NOTIFICATION-TYPE
OBJECTS { dsx3LineStatus,
dsx3LineStatusLastChange }
STATUS current
DESCRIPTION
"A dsx3LineStatusChange trap is sent when the
value of an instance of dsx3LineStatus changes. It
can be utilized by an NMS to trigger polls. When
the line status change results in a lower level
line status change (i.e., ds1), then no traps for
the lower level are sent."
::= { ds3Traps 0 1 }
dsx3LineStatusChange NOTIFICATION-TYPE OBJECTS、dsx3LineStatus、dsx3LineStatusLastChange、「dsx3LineStatusのインスタンスの値が変化するときdsx3LineStatusChange罠を送る」STATUSの現在の記述。 NMSは、投票の引き金となるのにそれを利用できます。 「そして、下のレベル系列状態の系列状態変化結果が(すなわち、ds1)を変えるとき、下のレベルのための罠を全く送りません。」 ::= ds3Traps0 1
0. At system start, the active alarm table, alarm clear table and
the Notification Log are all empty.
___________________________ _______________________
| alarmActiveTable | | nlmLogTable |
|---------------------------| |-----------------------|
| alarmActiveIndex | alarm | | nlmLogPointer | notif.|
|---------------------------| |-----------------------|
|___________________________| |_______________________|
0. システムによって、始め、アクティブなアラームテーブルは明確なテーブルを驚かせます、そして、Notification Logはすべて空です。 ___________________________ _______________________ | alarmActiveTable| | nlmLogTable| |---------------------------| |-----------------------| | alarmActiveIndex| アラーム| | nlmLogPointer| notif、||---------------------------| |-----------------------| |___________________________| |_______________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| | |
|__________________________________________________|
__________________________________________________ | alarmClearTable| |--------------------------------------------------| | alarmClearインデックス| アラーム| |--------------------------------------------------| | | | |__________________________________________________|
Chisholm & Romascanu Standards Track [Page 67] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[67ページ]RFC3877はMIB2004年9月に驚かせます。
1. Some time later, a link goes down generating a linkDown
Notification, which is sent out and logged in the
Notification Log. As this Notification is modelled as
an alarm state, an entry is added to the active alarm
table.
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
| 1 | link down - problem confirmed |
|__________________________________________________|
1. その後、リンクは、linkDown Notification(出されて、Notification Logに登録される)を生成しながら、落ちます。 このNotificationがアラーム状態としてモデル化されるとき、エントリーはアクティブなアラームテーブルに加えられます。 __________________________________________________ | alarmActiveTable| |--------------------------------------------------| | alarmActiveIndex| アラーム| |--------------------------------------------------| | 1 | 確認された下に--問題をリンクしてください。| |__________________________________________________|
_______________________________________________
| nlmLogTable |
|-----------------------------------------------|
| nlmLogPointer | Notification |
|-----------------------------------------------|
| 1 | linkdown |
|_______________________________________________|
_______________________________________________ | nlmLogTable| |-----------------------------------------------| | nlmLogPointer| 通知| |-----------------------------------------------| | 1 | linkdown| |_______________________________________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| | |
|__________________________________________________|
__________________________________________________ | alarmClearTable| |--------------------------------------------------| | alarmClearインデックス| アラーム| |--------------------------------------------------| | | | |__________________________________________________|
Chisholm & Romascanu Standards Track [Page 68] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[68ページ]RFC3877はMIB2004年9月に驚かせます。
2. Some time later, the value of an instance of dsx3LineStatus
changes. This Notification is sent out and logged. As this
is not modelled into an alarm state, the active alarm table
remains unchanged.
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
| 1 | linkDown - problem confirmed |
|__________________________________________________|
2. その後、dsx3LineStatusのインスタンスの値は変化します。 このNotificationは出されて、登録されます。 これがアラーム状態にモデル化されないとき、アクティブなアラームテーブルは変わりがありません。 __________________________________________________ | alarmActiveTable| |--------------------------------------------------| | alarmActiveIndex| アラーム| |--------------------------------------------------| | 1 | linkDown--確認された問題| |__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogPointer | Notification |
|---------------------------------------------|
| 1 | linkDown |
| 2 | dsx3LineStatusChange |
|_____________________________________________|
_____________________________________________ | nlmLogTable| |---------------------------------------------| | nlmLogPointer| 通知| |---------------------------------------------| | 1 | linkDown| | 2 | dsx3LineStatusChange| |_____________________________________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| | |
|__________________________________________________|
__________________________________________________ | alarmClearTable| |--------------------------------------------------| | alarmClearインデックス| アラーム| |--------------------------------------------------| | | | |__________________________________________________|
Chisholm & Romascanu Standards Track [Page 69] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[69ページ]RFC3877はMIB2004年9月に驚かせます。
3. Some time later, the link goes back up. A linkUp Notification
is sent out and logged. As this Notification models
the clear alarm for this alarm, the alarm entry is remove
from the active alarm table. An entry is added to the
clear alarm table.
__________________________________________________
| alarmActiveTable |
|--------------------------------------------------|
| alarmActiveIndex | alarm |
|--------------------------------------------------|
|__________________________________________________|
3. その後、リンクは上がって戻ります。 linkUp Notificationは出されて、登録されます。 このNotificationがこのアラームのための明確なアラームをモデル化するとき、アラームエントリーはアクティブなアラームテーブルから取り外すことです。 エントリーは明確なアラームテーブルに加えられます。 __________________________________________________ | alarmActiveTable| |--------------------------------------------------| | alarmActiveIndex| アラーム| |--------------------------------------------------| |__________________________________________________|
_____________________________________________
| nlmLogTable |
|---------------------------------------------|
| nlmLogPointer | Notification |
|---------------------------------------------|
| 1 | linkDown |
| 2 | dsx3LineStatusChange |
| 3 | linkUp |
|_____________________________________________|
_____________________________________________ | nlmLogTable| |---------------------------------------------| | nlmLogPointer| 通知| |---------------------------------------------| | 1 | linkDown| | 2 | dsx3LineStatusChange| | 3 | 結合| |_____________________________________________|
__________________________________________________
| alarmClearTable |
|--------------------------------------------------|
| alarmClear Index | alarm |
|--------------------------------------------------|
| 1 | linkDown - confirmed problem |
|__________________________________________________|
__________________________________________________ | alarmClearTable| |--------------------------------------------------| | alarmClearインデックス| アラーム| |--------------------------------------------------| | 1 | linkDown--確認された問題| |__________________________________________________|
7. Security Considerations
7. セキュリティ問題
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
The following objects are defined with a MAX-ACCESS clause of read- write or read-create: alarmModelNotificationId, alarmModelVarbindIndex, alarmModelVarbindValue, alarmModelDescription, alarmModelSpecificPointer, alarmModelVarbindSubtree, alarmModelResourcePrefix, alarmModelRowStatus, alarmClearMaximum, ituAlarmEventType, ituAlarmProbableCause, ituAlarmAdditionalText, and ituAlarmGenericModel.
以下のオブジェクトは、読書の節が書くマックス-ACCESSと共に定義されるか、または以下を読書して作成します。 alarmModelNotificationId、alarmModelVarbindIndex、alarmModelVarbindValue、alarmModelDescription、alarmModelSpecificPointer、alarmModelVarbindSubtree、alarmModelResourcePrefix、alarmModelRowStatus、alarmClearMaximum、ituAlarmEventType、ituAlarmProbableCause、ituAlarmAdditionalText、およびituAlarmGenericModel。
Chisholm & Romascanu Standards Track [Page 70] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[70ページ]RFC3877はMIB2004年9月に驚かせます。
Note that setting the value of alarmClearMaximum too low may result in security related alarms history being prematurely lost.
あまりに低くalarmClearMaximumの値を設定すると関係づけられたセキュリティがもたらされるかもしれないというメモは早まって失われている歴史を驚かせます。
Changing values of alarmModelRowStatus as part of creating and deleting rows in the alarmModelTable result in adding new alarm models to the system or taking them out respectively. These operations need to be carefully planned. Adding a new model should be made in a consistent manner to avoid the system overflow with alarms. Taking out a model should result in the deletion of all this model's related alarms in the system.
新しいアラームを加える際にalarmModelTable結果における行を作成して、削除する一部としてalarmModelRowStatusの値を変えるのはシステムかそれぞれそれらを取り出すのにモデル化されます。 これらの操作は、慎重に計画される必要があります。 新しいモデルを加えると、アラームによるシステムオーバーフローは一貫した方法で避けさせられるべきです。モデルを連れて行くと、システムにおける、このすべてのモデルの関連するアラームの削除はもたらされるべきです。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), 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.
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([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に与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
Note that the alarm throttling mechanism associated with the alarmActiveState and alarmActiveClear notifications only applies to a given alarm. Defining multiple alarms from the same internal stimulus may then still result in a flood of alarms into the network.
alarmActiveStateに関連しているメカニズムとalarmActiveClear通知だけを阻止するアラームが与えられたアラームに適用されることに注意してください。 そして、同じ内部の刺激から複数のアラームを定義すると、ネットワークへのアラームの洪水はまだもたらされているかもしれません。
Although the use of community strings in SNMPv1 is not considered an effective means of providing security, security administrators SHOULD consider whether the fact that alarmActiveContextName can reveal community string values would make this object sensitive in their environment.
SNMPv1における共同体ストリングの使用はセキュリティを提供する効果的な手段であると考えられませんが、セキュリティ管理者SHOULDは、alarmActiveContextNameが共同体ストリング値を明らかにすることができるという事実でこのオブジェクトが彼らの環境で敏感になるかどうか考えます。
This MIB module can provide access to information that may also be accessed through manipulation of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413], and alarmListName. Consequently, it is RECOMMENDED that security administrators take care to configure a coherent VACM security policy. The objects
このMIBモジュールはまた、SNMP-NOTIFICATION-MIBとNOTIFICATION-LOG-MIBの操作でアクセスされるかもしれない情報入手を提供できます。 これはnlmLogName[RFC3014]、snmpNotifyFilterProfileName[RFC3413]、およびalarmListNameの一般的なインデックス構造を通して一部言い表されます。 その結果、セキュリティ管理者が論理的なVACM安全保障政策を構成するために注意するのは、RECOMMENDEDです。 オブジェクト
Chisholm & Romascanu Standards Track [Page 71] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[71ページ]RFC3877はMIB2004年9月に驚かせます。
alarmActiveLogPointer, alarmActiveModelPointer, alarmActiveSpecificPointer, and alarmClearModelPointer are object identifiers that reference information to which a particular user might not be given direct access. The structure of these object identifiers does not permit the extraction of any sensitive information. Two other objects, alarmClearResourceId, and alarmActiveResourceId, are also syntactically object identifiers, but their structure could provide a user with potentially useful information to which he or she might not otherwise be granted access, such as the existence of a particular resource.
alarmActiveLogPointer、alarmActiveModelPointer、alarmActiveSpecificPointer、およびalarmClearModelPointerは特定のユーザが与えられた直接アクセスでないかもしれない情報に参照をつけるオブジェクト識別子です。 これらのオブジェクト識別子の構造はどんな機密情報の抽出も可能にしません。 他の2個のオブジェクト(alarmClearResourceId、およびalarmActiveResourceId)は、あります、また、シンタクス上、しかし、オブジェクト識別子、それらの構造が与えられたアクセス(特定のリソースの存在としてのそのようなもの)を潜在的に有用性のある情報をもっているそうでなければその人がいないかもしれないaユーザに提供するかもしれません。
For further discussion of security, see section 3.4.
セキュリティのさらなる議論に関しては、セクション3.4を見てください。
8. Acknowledgements
8. 承認
This document is a product of the DISMAN Working Group.
このドキュメントはDISMAN作業部会の製品です。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[M.3100] ITU Recommendation M.3100, "Generic Network Information
Model", 1995
[M.3100]ITU推薦M.3100、「ジェネリックネットワーク情報モデル」、1995
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, RFC
1157, May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1215] Rose, M., "A Convention for defining traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215] 1991年3月のローズ、M.、「SNMPとの使用のために罠を定義するためのConvention」RFC1215。
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", January 1997.
[RFC2021] Waldbusser、S.、「SMIv2"、1997年1月を使用するリモートネットワーク監視管理情報ベースバージョン2。」
[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. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
Chisholm & Romascanu Standards Track [Page 72] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[72ページ]RFC3877はMIB2004年9月に驚かせます。
[RFC3291] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[RFC3291] ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ.Schoenwaelder(「インターネットネットワーク・アドレスのための原文のコンベンション」、RFC3291)は2002がそうするかもしれません。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3411] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3414, December 2002.
[RFC3413] レビとD.とマイヤーとP.とB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3415] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", STD
62, RFC 3416, December 2002.
[RFC3416]Presuhn、R.(エド)、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.
[RFC3584]フライとR.とレビとD.、RouthierとS.とB.Wijnen、「インターネット標準ネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」BCP74、RFC3584(2003年8月)。
[X.733] ITU Recommendation X.733, "Information Technology - Open
Systems Interconnection - System Management: Alarm
Reporting Function", 1992.
[X.733]ITU推薦X.733、「情報技術(オープン・システム・インターコネクション)システム管理:」 「アラーム報告機能」、1992。
[X.736] ITU Recommendation X.736, "Information Technology - Open
Systems Interconnection - System Management: Security
Alarm Reporting Function", 1992.
[X.736]ITU推薦X.736、「情報技術(オープン・システム・インターコネクション)システム管理:」 「警報機報告機能」、1992。
9.2 Informative References
9.2 有益な参照
[RFC1657] Willis, S., Burruss, J. and J. Chu, Ed., "Definitions of
Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July
1994.
そして、[RFC1657]ウィリス、S.、Burruss、J.、J.チュウ(エド)、「SMIv2"を使用して、境界ゲートウェイの第4バージョンのための管理オブジェクトの定義は(BGP-4)について議定書の中で述べます、RFC1657、1994年7月。」
[RFC2737] McCloghrie, K. and A. Bierman, "Entity MIB (version 2)",
RFC 2737, December 1999.
[RFC2737]McCloghrieとK.とA.Bierman、「実体MIB(バージョン2)」、RFC2737 1999年12月。
[RFC2819] Waldbusser, S. "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2819]Waldbusser(S.「リモートネットワーク監視管理情報ベース」、STD59、RFC2819)は2000がそうするかもしれません。
Chisholm & Romascanu Standards Track [Page 73] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[73ページ]RFC3877はMIB2004年9月に驚かせます。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB using SMIv2", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.、およびF.Kastenholz、「インタフェースは2000年6月にSMIv2"、RFC2863を使用するMIBを分類します」。
[RFC2981] Kavasseri, R., Ed., "Event MIB", RFC 2981, October 2000.
[RFC2981] Kavasseri、R.、エド、「イベントMIB」、RFC2981、10月2000日
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November
2000.
R.、「通知ログMIB」、RFC3014 2000年11月の[RFC3014]Kavasseri。
[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月)。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3418]Presuhn、R.(エド)、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[RFC3805] Bergman, R., Lewis, H. and I. McDonald, "Printer MIB v2",
RFC 3805, June 2004.
[RFC3805] バーグマンとR.とルイスとH.とI.マクドナルド、「プリンタMIB v2"、RFC3805、2004年6月。」
10. Authors' Addresses
10. 作者のアドレス
Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada
シャロンチスホルムノーテルは私書箱3511、オタワ、Cオンタリオ、駅のK1Y 4H7カナダをネットワークでつなぎます。
EMail: schishol@nortelnetworks.com
メール: schishol@nortelnetworks.com
Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel
ダンRomascanu Avaya Atidim技術公園、ビルディング #3 61131テルアビブ(イスラエル)
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
以下に電話をしてください。 +972-3-645-8414 メールしてください: dromasca@avaya.com
Chisholm & Romascanu Standards Track [Page 74] RFC 3877 Alarm MIB September 2004
チスホルムとRomascanu標準化過程[74ページ]RFC3877はMIB2004年9月に驚かせます。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Chisholm & Romascanu Standards Track [Page 75]
チスホルムとRomascanu標準化過程[75ページ]
一覧
スポンサーリンク
