RFC3014 日本語訳
3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT=48287 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Editor of this version:
Request for Comments: 3014 R. Kavasseri
Category: Standards Track Cisco Systems, Inc.
Author of previous version:
B. Stewart
November 2000
このバージョンの作業部会Editorをネットワークでつないでください: コメントのために以下を要求してください。 3014年のR.Kavasseriカテゴリ: 旧バージョンの規格TrackシスコシステムズInc.Author: B。 スチュワート2000年11月
Notification Log 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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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 managed objects used for logging Simple Network Management Protocol (SNMP) Notifications.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは伐採Simple Network Managementプロトコル(SNMP)通知に使用される管理オブジェクトについて説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Kavasseri Standards Track [Page 1] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[1ページ]。
Table of Contents
目次
1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Environment ................................................. 3 2.1.1 SNMP Engines and Contexts ................................. 4 2.1.2 Security .................................................. 4 2.2 Structure ................................................... 5 2.2.1 Configuration ............................................. 5 2.2.2 Statistics ................................................ 6 2.2.3 Log ....................................................... 6 2.3 Example ..................................................... 6 3 Definitions ................................................... 7 4 Intellectual Property ......................................... 23 5 References .................................................... 23 6 Security Considerations ....................................... 25 7 Author's Address .............................................. 25 8 Full Copyright Statement ...................................... 26
1 SNMP管理フレームワーク… 2 2概要… 3 2.1環境… 3 2.1 .1のSNMPエンジンと文脈… 4 2.1 .2セキュリティ… 4 2.2 構造… 5 2.2 .1構成… 5 2.2 .2の統計… 6 2.2 .3 登録します。 6 2.3の例… 6 3の定義… 7 4知的所有権… 23 5つの参照箇所… 23 6 セキュリティ問題… 25 7作者のアドレス… 25 8 完全な著作権宣言文… 26
1. The SNMP Management Framework
1. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[RFC2571]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]、およびRFC1215[RFC1215]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されます。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[RFC1157]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[RFC1901]とRFC1906[RFC1906]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]でSNMPv3と呼ばれて、説明されます。
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[RFC1905]で説明されます。
Kavasseri Standards Track [Page 2] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[2ページ]。
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
o RFC2573[RFC2573]で説明された1セットの基礎的応用と視点ベースのアクセス管理機構はRFC2575で[RFC2575]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
2. Overview
2. 概要
Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers.
SNMPをサポートするシステムがしばしば生垣として無くなっているNotificationsに対してNotification情報を記録するのにメカニズムを必要とします、それらが「再-トランスミッション」限界を超えているTrapsかInforms[RFC1905]であることにかかわらず。 したがって、このMIBは地方の伐採機能の形の他のMIBsに一般的なインフラストラクチャを供給します。 それを主としてNotificationsの送付者のために意図しましたが、また、受信機は使用できました。
Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications.
Notification Log MIBを考えて、個々のMIBsはNotificationメッセージが無くなって、アプリケーションが重要なNotificationsがいなくて寂しくないことを確かめるためにログに投票できる可能性に対してイベントに関連している一時的な情報を記録するより少ない責任を担います。
2.1. Environment
2.1. 環境
The overall environmental concerns for the MIB are:
MIBのための総合的な環境問題は以下の通りです。
o SNMP Engines and Contexts
o SNMPエンジンと文脈
o Security
o セキュリティ
Kavasseri Standards Track [Page 3] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[3ページ]。
2.1.1. SNMP Engines and Contexts
2.1.1. SNMPエンジンと文脈
There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) is modeled here as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines.
登録するかもしれない複数の通知創始者からの2回の異なった情報流れがあります。 SNMPが知らせて、捕らえるとき、1番目は伐採のために受け取られる(1台以上のSNMPエンジンから)通知です。 もう片方がインタフェースのSNMPエンジンに提供された通知を通知創始者に包括します(SNMP以外の通知メカニズムを使用するのは、知らせるか、または捕らえられます)。 後者の情報流動(SNMP以外の通知メカニズムを使用するのは、知らせるか、または捕らえられる)は、それ自体に通知書を送りながら、SNMPエンジン(ログを維持する)としてここでモデル化されます。 このセクションの残りは前の情報流動の取り扱いについて議論します--複数のSNMPエンジンからの通知(受け取って、SNMPのフォームは、知らせるか、または捕らえられます)。
As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came.
SNMPアーキテクチャ[RFC2571]で説明されるように、与えられたシステムはお互いの如何にかかわらず動作する複数のSNMPエンジンを支えるかもしれません、それぞれそれ自身のSNMPエンジン識別で。 その上、MIBオブジェクトとNotificationsのセットは、与えられたエンジンの範囲の中では、重なることをサポートする複数の命名された管理文脈であるかばらばらになるかもしれません。 したがって、それは来て、特定のNotificationが、起源からSNMPエンジンと管理文脈を知るのを必要とするのを理解していました。
To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name.
登録されたNotificationに、必要なソース情報を提供するなら、MIBは、そのNotificationのソースSNMPエンジンIDと管理文脈名を記録するためにオブジェクトを含んでいます。
2.1.2. Security
2.1.2. セキュリティ
Security for Notifications is awkward since access control for the objects in the Notification 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.
Notificationsのためのセキュリティは、Notificationが作成されるだけであるところでNotificationのオブジェクトのためのアクセスコントロールをチェックできるので、まずいです。 したがって、そのような照合は、局所的に発生しているNotificationsだけに可能であり、セキュリティー証明書がその時でさえ利用可能であるときにだけ、可能です。
For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] 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 [RFC2573].
この議論の目的のために、「セキュリティー証明書」は抽象的なサービスインタフェース機能isAccessAllowed[RFC2571]のために入力値を意味して、それらの資格証明書を使用するのは、それらの資格証明書が問題のMIBオブジェクトへのアクセスを許すことを確認するのに概念的にその機能を使用することを意味します、Notification Originatorのように[RFC2573]で作動して。
The Notification Log MIB has the notion of a "named log." By using log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay associated with that log.
Notification Log MIBには、「命名されたログ」の考えがあります。 ログ名と視点ベースのアクセス制御[RFC2575]を使用することによって、ネットワーク管理者は異なったアクセスを異なったユーザに提供できます。 アプリケーションが命名されたログを作成するとき、クリエイターのセキュリティー証明書はそのログに関連していた状態で残っています。
Kavasseri Standards Track [Page 4] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[4ページ]。
A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking.
より少ないリソースがある管理されたシステムは命名されたログ、デフォルトだけを提供するヌルで命名されたログの作成を禁じるかもしれません。 そのようなログには、Notificationオブジェクトアクセスコントロールのためのどんな暗黙のセキュリティー証明書もありません、そして、さらにチェックしないで、それにNotificationsを入れます。
When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573].
局所的に発生しているNotificationsを命名されたログに入れるとき、管理されたシステムは、そのログに関連しているセキュリティー証明書を使用しなければならなくて、[RFC2573]のNotification Originatorのために説明されるのと同じアクセス制御規則を当てはまらなければなりません。
The managed system SHOULD NOT apply access control when adding remotely-generated Notifications into either a named log or the default, null-named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself.
命名されたログかデフォルト(ヌルで命名されたログ)のどちらかにほんの少し発生しているNotificationsを追加するとき、管理されたシステムSHOULD NOTはアクセスコントロールを適用します。 それらの場合では、丸太のままで情報SHOULDのセキュリティが標準に残されて、総合的なアクセスはログ自体のために制御されます。
The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e., it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of- service attack. Methods for countering such an attack are for further study.
Notification Log MIBはアプリケーションにnlmConfigGlobalEntryLimitを使用して、登録できるNotificationsの最大数を設定させます。 同様に、アプリケーションは、nlmConfigGlobalAgeOutを使用することで最大の時代を設定できます。(その時、より古いNotificationsは外で調節されたかもしれません後)。 これらのオブジェクトを異価に設定しようとする複数のアプリケーションの間の主張が各アプリケーションで見られたデータの信頼性と完全性に影響するかもしれなくて、すなわち、1つのアプリケーションがこれらのオブジェクトのどちらかの値を変えるのが、可能であることを意識してください、他のアプリケーションにそれらを見る機会がある前に削除されるいくつかのNotificationsをもたらして。 これはそうであるかもしれません。-否定を調整するのが使用されて、サービスでは、攻撃してください。 さらなる研究にはそのような攻撃に対抗するためのメソッドがあります。
2.2. Structure
2.2. 構造
The MIB has the following sections:
MIBには、以下のセクションがあります:
o Configuration -- control over how much the log can hold and
what Notifications are to be logged.
o 構成--ログがどれほど成立できて、登録されて、Notificationsが何がいるかの上で制御してください。
o Statistics -- indications of logging activity.
o 統計--伐採活動のしるし。
o Log -- the Notifications themselves.
o ログ--Notifications自身。
2.2.1. Configuration
2.2.1. 構成
The configuration section contains objects to manage resource use by the MIB.
構成節はMIBによるリソース使用を管理するオブジェクトを含んでいます。
This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends
また、このセクションはどんなログが存在しているか、そして、それらがどのように作動するかを指定するテーブルを含みます。 登録されるためにNotificationsがどれであるかを決めるのをよります。
Kavasseri Standards Track [Page 5] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[5ページ]。
on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table.
そのテーブルから初期のインデックス(snmpNotifyFilterName)によって特定された標準のSNMP Notification MIB[RFC2573]のsnmpNotifyFilterTableで定義されたフィルタに関して。
2.2.2. Statistics
2.2.2. 統計
The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems.
統計部はログ容量構成の結果を理解する手段を供給して、登録されて、捨てられたNotificationsとリソース問題によってカウンタを含みます。
2.2.3. Log
2.2.3. ログ
The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries.
ログはエントリーをしたとき反射する整数によって索引をつけられたそれらの変項束縛リストに入ったNotificationsとオブジェクトを含んでいます。 すべての登録されたNotificationsを集めたいか、またはそれが何かを逃したかもしれないかどうかを知りたがっているアプリケーションは、検索した中で最も高いインデックスの動向をおさえて、そこから次の投票を始めることができます、インデックスをリセットして、恐らくエントリーを失った不連続がないかどうかsysUpTimeをチェックして。
Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type.
変数がそのNotificationの中でNotificationインデックスと可変インデックスによって索引をつけられたテーブルにあります。 値は「差別された組合」として1変数あたり1個の値のオブジェクトで保たれます。 ちょうどどの値のオブジェクトが例示されるかはそれぞれの異なったSNMPデータ型のために適切なタイプの別々のオブジェクトで変数に関するSNMPデータ型によります。
An application can thus reconstruct the information from the Notification PDU from what is recorded in the log.
その結果、アプリケーションはNotification PDUから丸太のままで記録されることから情報を再建できます。
2.3. Example
2.3. 例
Following is an example configuration of a named log for logging only linkUp and linkDown Notifications.
以下に、linkUpとlinkDown Notificationsだけを登録するための命名されたログの例の構成があります。
In nlmConfigLogTable:
nlmConfigLogTableで:
nlmConfigLogFilterName.5."links" = "link-status"
nlmConfigLogEntryLimit.5."links" = 0
nlmConfigLogAdminStatus.5."links" = enabled
nlmConfigLogOperStatus.5."links" = operational
nlmConfigLogStorageType.5."links" = nonVolatile
nlmConfigLogEntryStatus.5."links" = active
nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active
Note that snmpTraps is:
snmpTrapsは以下の通りであることに注意してください。
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5
Kavasseri Standards Track [Page 6] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[6ページ]。
Or numerically:
または、数の上で:
1.3.6.1.6.3.1.1.5
1.3.6.1.6.3.1.1.5
And linkDown is snmpTraps.3 and linkUp is snmpTraps.4.
そして、linkDownはsnmpTraps.3です、そして、linkUpはsnmpTraps.4です。
So to allow the two Notifications in snmpNotifyFilterTable:
snmpNotifyFilterTableの2Notificationsを許容するそう:
snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H
snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include
snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3
= nonVolatile
snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3
= active
「snmpNotifyFilterMask.11「リンク状態」.1.3.6.1.6.3.1.1.5.3=「H snmpNotifyFilterType.11」リンク状態」.1.3.6.1.6.3.1.1.5.3=インクルードsnmpNotifyFilterStorageType.11「リンク状態」.1.3.6.1.6.3.1.1.5.3=nonVolatile snmpNotifyFilterRowStatus.11「リンク状態」.1.3.6.1.6.3.1.1.5.3=アクティブです。
snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H
snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include
snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4
= nonVolatile
snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4
= active
「snmpNotifyFilterMask.11「リンク状態」.1.3.6.1.6.3.1.1.5.4=「H snmpNotifyFilterType.11」リンク状態」.1.3.6.1.6.3.1.1.5.4=インクルードsnmpNotifyFilterStorageType.11「リンク状態」.1.3.6.1.6.3.1.1.5.4=nonVolatile snmpNotifyFilterRowStatus.11「リンク状態」.1.3.6.1.6.3.1.1.5.4=アクティブです。
3. Definitions
3. 定義
NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN
通知ログMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Integer32, Unsigned32,
TimeTicks, Counter32, Counter64,
IpAddress, Opaque, mib-2 FROM SNMPv2-SMI
TimeStamp, DateAndTime,
StorageType, RowStatus,
TAddress, TDomain FROM SNMPv2-TC
SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Integer32、Unsigned32、TimeTicks、Counter32、Counter64、IpAddress、Opaque、mib-2 FROM SNMPv2-SMI TimeStamp、DateAndTime、StorageType、RowStatus、TAddress、TDomain FROM SNMPv2-TC SnmpAdminString、SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF。
notificationLogMIB MODULE-IDENTITY
LAST-UPDATED "200011270000Z" -- 27 November 2000
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO "Ramanathan Kavasseri
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose CA 95134-1706.
Phone: +1 408 527 2446
Email: ramk@cisco.com"
DESCRIPTION
"The MIB module for logging SNMP Notifications, that is, Traps
notificationLogMIBモジュールアイデンティティは"200011270000Z"をアップデートしました--「Ramanathan KavasseriシスコシステムズInc.170の西タスマンDrive、サンノゼカリフォルニア95134-1706」という2000年11月27日の組織「IETF分散管理作業部会」コンタクトインフォメーション。 以下に電話をしてください。 +1 2446年の408 527メール: " ramk@cisco.com "記述は「すなわち、伐採SNMP Notifications、TrapsのためのMIBモジュール」です。
Kavasseri Standards Track [Page 7] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[7ページ]。
and Informs."
-- Revision History
「知らせる」、--、改訂履歴
REVISION "200011270000Z" -- 27 November 2000
DESCRIPTION "This is the initial version of this MIB.
Published as RFC 3014"
::= { mib-2 92 }
REVISION"200011270000Z"--、2000年11月27日の記述、「これはこのMIBの初期のバージョンです」。 「RFC3014として発行される」:、:= mib-2 92
notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 }
notificationLogMIBObjectsオブジェクト識別子:、:= notificationLogMIB1
nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 }
nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 }
nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 }
nlmConfigオブジェクト識別子:、:= notificationLogMIBObjects1nlmStatsオブジェクト識別子:、:= notificationLogMIBObjects2nlmLogオブジェクト識別子:、:= notificationLogMIBObjects3
-- -- Configuration Section --
-- -- 構成節--
nlmConfigGlobalEntryLimit OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of notification entries that may be held
in nlmLogTable for all nlmLogNames added together. A particular
setting does not guarantee that much data can be held.
nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSは「合計されたすべてのnlmLogNamesのためのnlmLogTableに保持されるかもしれない通知エントリーの最大数」をSTATUSの現在の記述に読書して書きます。 特定の設定は、多くのデータを保持できるのを保証しません。
If an application changes the limit while there are
Notifications in the log, the oldest Notifications MUST be
discarded to bring the log down to the new limit - thus the
value of nlmConfigGlobalEntryLimit MUST take precedence over
the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit,
even if the Notification being discarded has been present for
fewer minutes than the value of nlmConfigGlobalAgeOut, or if
the named log has fewer entries than that specified in
nlmConfigLogEntryLimit.
Notificationsが丸太のままでありますが、アプリケーションが限界を変えるなら、ログを新しい限界までもたらすために最も古いNotificationsを捨てなければなりません--その結果、nlmConfigGlobalEntryLimitの値はnlmConfigGlobalAgeOutとnlmConfigLogEntryLimitの値の上で優先しなければなりません、捨てられるNotificationがnlmConfigGlobalAgeOutの値より少ない分間存在しているか、またはnlmConfigLogEntryLimitで命名されたログでそれより少ないエントリーを指定するなら。
A value of 0 means no limit.
0の値は限界を全く意味しません。
Please be aware that contention between multiple managers
trying to set this object to different values MAY affect the
reliability and completeness of data seen by each manager."
DEFVAL { 0 }
::= { nlmConfig 1 }
「このオブジェクトを異価に設定しようとする複数のマネージャの間の主張が各マネージャによって見られたデータの信頼性と完全性に影響するかもしれないのを意識してください。」 DEFVAL0:、:= nlmConfig1
nlmConfigGlobalAgeOut OBJECT-TYPE
SYNTAX Unsigned32
nlmConfigGlobalAgeOutオブジェクト・タイプ構文Unsigned32
Kavasseri Standards Track [Page 8] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[8ページ]。
UNITS "minutes"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The number of minutes a Notification SHOULD be kept in a log
before it is automatically removed.
UNITS「数分」マックス-ACCESSが現在の記述をSTATUSに読書して書く、「数、自動的にそれを取り除く前に、数分a Notification SHOULDでは、ログに保ってください、」
If an application changes the value of nlmConfigGlobalAgeOut,
Notifications older than the new time MAY be discarded to meet the
new time.
アプリケーションがnlmConfigGlobalAgeOutの値を変えるなら、新期間より古いNotificationsは、新期間に間に合うように捨てられるかもしれません。
A value of 0 means no age out.
0の値は外で時代を全く意味しません。
Please be aware that contention between multiple managers
trying to set this object to different values MAY affect the
reliability and completeness of data seen by each manager."
DEFVAL { 1440 } -- 24 hours
::= { nlmConfig 2 }
「このオブジェクトを異価に設定しようとする複数のマネージャの間の主張が各マネージャによって見られたデータの信頼性と完全性に影響するかもしれないのを意識してください。」 DEFVAL1440--24時間:、:= nlmConfig2
-- -- Basic Log Configuration Table --
-- -- 基本的なログ構成テーブル--
nlmConfigLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF NlmConfigLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of logging control entries."
::= { nlmConfig 3 }
nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「伐採コントロールエントリーのテーブル。」 ::= nlmConfig3
nlmConfigLogEntry OBJECT-TYPE
SYNTAX NlmConfigLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A logging control entry. Depending on the entry's storage type
entries may be supplied by the system or created and deleted by
applications using nlmConfigLogEntryStatus."
INDEX { nlmLogName }
::= { nlmConfigLogTable 1 }
アクセスしやすくないnlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntryの現在の記述マックス-ACCESS STATUS「A伐採コントロールエントリー。」 「nlmConfigLogEntryStatusを使用しながら、アプリケーションでエントリーのストレージタイプエントリーによるのをシステムから供給するか、作成して、または削除するかもしれません。」 nlmLogNameに索引をつけてください:、:= nlmConfigLogTable1
NlmConfigLogEntry ::= SEQUENCE {
nlmLogName SnmpAdminString,
nlmConfigLogFilterName SnmpAdminString,
nlmConfigLogEntryLimit Unsigned32,
nlmConfigLogAdminStatus INTEGER,
NlmConfigLogEntry:、:= 系列、nlmLogName SnmpAdminString、nlmConfigLogFilterName SnmpAdminString、nlmConfigLogEntryLimit Unsigned32、nlmConfigLogAdminStatus整数
Kavasseri Standards Track [Page 9] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[9ページ]。
nlmConfigLogOperStatus INTEGER,
nlmConfigLogStorageType StorageType,
nlmConfigLogEntryStatus RowStatus
}
nlmConfigLogOperStatus整数、nlmConfigLogStorageType StorageType、nlmConfigLogEntryStatus RowStatus
nlmLogName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the log.
nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「ログの名前。」
An implementation may allow multiple named logs, up to some
implementation-specific limit (which may be none). A
zero-length log 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 logs."
::= { nlmConfigLogEntry 1 }
実装は複数の命名されたログを何らかの実装特有の限界(なにもであるかもしれない)まで許容するかもしれません。 「ゼロ・レングスログ名を作成と削除のために管理されたシステムによって予約されて、デフォルトログ名として命名されたログをサポートしないシステムで使用しなければなりません。」 ::= nlmConfigLogEntry1
nlmConfigLogFilterName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A value of snmpNotifyFilterProfileName as used as an index
into the snmpNotifyFilterTable in the SNMP Notification MIB,
specifying the locally or remotely originated Notifications
to be filtered out and not logged in this log.
nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「無視されるために局所的か離れて溯源されたNotificationsを指定して、インデックスとしてSNMP Notification MIBでsnmpNotifyFilterTableに使用されて、このログに登録されないsnmpNotifyFilterProfileNameの値。」
A zero-length value or a name that does not identify an
existing entry in snmpNotifyFilterTable indicate no
Notifications are to be logged in this log."
DEFVAL { ''H }
::= { nlmConfigLogEntry 2 }
「ゼロ・レングス値かsnmpNotifyFilterTableで既存のエントリーを特定しない名前が、このログにNotificationsを全く登録してはいけないのを示します。」 DEFVAL、「H、:、:、」= nlmConfigLogEntry2
nlmConfigLogEntryLimit OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum number of notification entries that can be held in
nlmLogTable for this named log. A particular setting does not
guarantee that that much data can be held.
nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「これのためのnlmLogTableに保持できる通知エントリーの最大数はログを命名しました」。 特定の設定は、それだけのデータを保持できるのを保証しません。
If an application changes the limit while there are
Notifications in the log, the oldest Notifications are discarded
to bring the log down to the new limit.
Notificationsが丸太のままでありますが、アプリケーションが限界を変えるなら、最も古いNotificationsは、ログを新しい限界までもたらすために捨てられます。
Kavasseri Standards Track [Page 10] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[10ページ]。
A value of 0 indicates no limit.
0の値は限界を全く示しません。
Please be aware that contention between multiple managers
trying to set this object to different values MAY affect the
reliability and completeness of data seen by each manager."
DEFVAL { 0 }
::= { nlmConfigLogEntry 3 }
「このオブジェクトを異価に設定しようとする複数のマネージャの間の主張が各マネージャによって見られたデータの信頼性と完全性に影響するかもしれないのを意識してください。」 DEFVAL0:、:= nlmConfigLogEntry3
nlmConfigLogAdminStatus OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Control to enable or disable the log without otherwise
disturbing the log's entry.
nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGERは(2)であると無効にされた(1)を可能にしました。マックス-ACCESSは現在の記述が「そうでなければ、ログのエントリーを擾乱しないでログを可能にするか、または無効にするために制御する」STATUSを読書して作成します。
Please be aware that contention between multiple managers
trying to set this object to different values MAY affect the
reliability and completeness of data seen by each manager."
DEFVAL { enabled }
::= { nlmConfigLogEntry 4 }
「このオブジェクトを異価に設定しようとする複数のマネージャの間の主張が各マネージャによって見られたデータの信頼性と完全性に影響するかもしれないのを意識してください。」 DEFVALは可能にしました:、:= nlmConfigLogEntry4
nlmConfigLogOperStatus OBJECT-TYPE
SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational status of this log:
nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGERがマックス-ACCESS書き込み禁止STATUS現在で(1)、操作上の(2)、noFilter(3)を無効にした、記述、「このログの操作上の状態:」
disabled administratively disabled
行政上無効にされた身体障害者
operational administratively enabled and working
操作上、行政上可能にされて、扱います。
noFilter administratively enabled but either
nlmConfigLogFilterName is zero length
or does not name an existing entry in
snmpNotifyFilterTable"
::= { nlmConfigLogEntry 5 }
「行政上有効にされたnoFilterにもかかわらず、nlmConfigLogFilterNameはゼロ・レングスであるかsnmpNotifyFilterTableで既存のエントリーを命名しない」:、:= nlmConfigLogEntry5
nlmConfigLogStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this conceptual row."
::= { nlmConfigLogEntry 6 }
nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これほど概念的のストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。 ::= nlmConfigLogEntry6
nlmConfigLogEntryStatus OBJECT-TYPE
nlmConfigLogEntryStatusオブジェクト・タイプ
Kavasseri Standards Track [Page 11] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[11ページ]。
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Control for creating and deleting entries. Entries may be
modified while active.
SYNTAX RowStatusマックス-ACCESSは現在の記述が「エントリーを作成して、削除するために制御する」STATUSを読書して作成します。 エントリーはアクティブである間、変更されるかもしれません。
For non-null-named logs, the managed system records the security
credentials from the request that sets nlmConfigLogStatus
to 'active' and uses that identity to apply access control to
the objects in the Notification to decide if that Notification
may be logged."
::= { nlmConfigLogEntry 7 }
「指定された非ヌルログに関して、管理されたシステムはそのNotificationが登録されるかもしれないかどうか決めるために'アクティブに'nlmConfigLogStatusを設定して、アクセスコントロールを適用するのにそのアイデンティティを使用する要求からオブジェクトまでセキュリティー証明書をNotificationに記録します。」 ::= nlmConfigLogEntry7
-- -- Statistics Section --
-- -- 統計部--
nlmStatsGlobalNotificationsLogged OBJECT-TYPE
SYNTAX Counter32
UNITS "notifications"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Notifications put into the nlmLogTable. This
counts a Notification once for each log entry, so a Notification
put into multiple logs is counted multiple times."
::= { nlmStats 1 }
「Notificationsの数はnlmLogTableに置く」nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS「通知」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「これが一度それぞれのログエントリーまでNotificationを数えるので、複数のログに入れられたNotificationは複数の回数えられます。」 ::= nlmStats1
nlmStatsGlobalNotificationsBumped OBJECT-TYPE
SYNTAX Counter32
UNITS "notifications"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of log entries discarded to make room for a new entry
due to lack of resources or the value of nlmConfigGlobalEntryLimit
or nlmConfigLogEntryLimit. This does not include entries discarded
due to the value of nlmConfigGlobalAgeOut."
::= { nlmStats 2 }
「航空日誌記入事項の数は財源不足かnlmConfigGlobalEntryLimitかnlmConfigLogEntryLimitの値のため新しいエントリーに場所を開けるために捨てた」nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS「通知」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「これはnlmConfigGlobalAgeOutの値のため捨てられたエントリーを含んでいません。」 ::= nlmStats2
-- -- Log Statistics Table --
-- -- 統計テーブルを登録してください--
nlmStatsLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF NlmStatsLogEntry
MAX-ACCESS not-accessible
アクセスしやすくないnlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntryマックス-ACCESS
Kavasseri Standards Track [Page 12] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[12ページ]。
STATUS current
DESCRIPTION
"A table of Notification log statistics entries."
::= { nlmStats 3 }
STATUSの現在の記述、「Notificationログ統計エントリーのテーブル。」 ::= nlmStats3
nlmStatsLogEntry OBJECT-TYPE
SYNTAX NlmStatsLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Notification log statistics entry."
AUGMENTS { nlmConfigLogEntry }
::= { nlmStatsLogTable 1 }
アクセスしやすくない現在のnlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntryの記述マックス-ACCESS STATUS「A Notificationログ統計エントリー。」 nlmConfigLogEntryを増大させます:、:= nlmStatsLogTable1
NlmStatsLogEntry ::= SEQUENCE {
nlmStatsLogNotificationsLogged Counter32,
nlmStatsLogNotificationsBumped Counter32
}
NlmStatsLogEntry:、:= 系列nlmStatsLogNotificationsLogged Counter32、nlmStatsLogNotificationsBumped Counter32
nlmStatsLogNotificationsLogged OBJECT-TYPE
SYNTAX Counter32
UNITS "notifications"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Notifications put in this named log."
::= { nlmStatsLogEntry 1 }
「Notificationsの数はこの命名されたログに置く」nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS「通知」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= nlmStatsLogEntry1
nlmStatsLogNotificationsBumped OBJECT-TYPE
SYNTAX Counter32
UNITS "notifications"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of log entries discarded from this named log to make
room for a new entry due to lack of resources or the value of
nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not
include entries discarded due to the value of
nlmConfigGlobalAgeOut."
::= { nlmStatsLogEntry 2 }
「航空日誌記入事項の数は財源不足かnlmConfigGlobalEntryLimitかnlmConfigLogEntryLimitの値のため新しいエントリーに場所を開けるためにこの命名されたログから捨てた」nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS「通知」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「これはnlmConfigGlobalAgeOutの値のため捨てられたエントリーを含んでいません。」 ::= nlmStatsLogEntry2
-- -- Log Section --
-- -- セクションを登録してください--
-- -- Log Table
-- -- ログテーブル
Kavasseri Standards Track [Page 13] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[13ページ]。
--
--
nlmLogTable OBJECT-TYPE
SYNTAX SEQUENCE OF NlmLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of Notification log entries.
nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Notification航空日誌記入事項のテーブル。」
It is an implementation-specific matter whether entries in this
table are preserved across initializations of the management
system. In general one would expect that they are not.
このテーブルのエントリーがマネージメントシステムの初期化処理の向こう側に保持されるかどうかが、実現特有の問題です。 一般に、人は、それらがそうでないと予想するでしょう。
Note that keeping entries across initializations of the
management system leads to some confusion with counters and
TimeStamps, since both of those are based on sysUpTime, which
resets on management initialization. In this situation,
counters apply only after the reset and nlmLogTime for entries
made before the reset MUST be set to 0."
::= { nlmLog 1 }
それらの両方がsysUpTimeに基づいていて以来カウンタとTimeStampsへの何らかの混乱への管理システム先導の初期化処理の向こう側のエントリーがどのリセットであるかを管理初期化に保って、それに注意してください。 「この状況で、カウンタはリセットとnlmLogTimeの後にだけ0にリセットを設定しなければならない前にされたエントリーに適用されます。」 ::= nlmLog1
nlmLogEntry OBJECT-TYPE
SYNTAX NlmLogEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Notification log entry.
アクセスしやすくないnlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntryの現在の記述マックス-ACCESS STATUS「A Notificationログエントリー。」
Entries appear in this table when Notifications occur and pass
filtering by nlmConfigLogFilterName and access control. They are
removed to make way for new entries due to lack of resources or
the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or
nlmConfigLogEntryLimit.
エントリーは、Notificationsが起こるとこのテーブルに現れて、nlmConfigLogFilterNameとアクセス管理でフィルタリングを通過します。 財源不足による新しいエントリーかnlmConfigGlobalEntryLimit、nlmConfigGlobalAgeOut、またはnlmConfigLogEntryLimitの値に道をあけるためにそれらを取り除きます。
If adding an entry would exceed nlmConfigGlobalEntryLimit or system
resources in general, the oldest entry in any log SHOULD be removed
to make room for the new one.
加えるなら、エントリーはnlmConfigGlobalEntryLimitか一般に、システム資源を超えているでしょう、どんなログSHOULDも最も古いエントリー。取り除いて、1つを新しさの余地にしてください。
If adding an entry would exceed nlmConfigLogEntryLimit the oldest
entry in that log SHOULD be removed to make room for the new one.
エントリーがnlmConfigLogEntryLimitを超えていると言い足して、それで最も古いエントリーがSHOULDを登録するなら取り除いて、新しい方に場所を開けてください。
Before the managed system puts a locally-generated Notification
into a non-null-named log it assures that the creator of the log
has access to the information in the Notification. If not it
does not log that Notification in that log."
INDEX { nlmLogName, nlmLogIndex }
::= { nlmLogTable 1 }
管理されたシステムが指定された非ヌルログに局所的に発生しているNotificationを入れる前に、それは、ログの創造者がNotificationの情報に近づく手段を持っていることを保証します。 「そうでなければ、そのログにそのNotificationを登録しません。」 nlmLogName、nlmLogIndexに索引をつけてください:、:= nlmLogTable1
Kavasseri Standards Track [Page 14] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[14ページ]。
NlmLogEntry ::= SEQUENCE {
nlmLogIndex Unsigned32,
nlmLogTime TimeStamp,
nlmLogDateAndTime DateAndTime,
nlmLogEngineID SnmpEngineID,
nlmLogEngineTAddress TAddress,
nlmLogEngineTDomain TDomain,
nlmLogContextEngineID SnmpEngineID,
nlmLogContextName SnmpAdminString,
nlmLogNotificationID OBJECT IDENTIFIER
}
NlmLogEntry:、:= 系列nlmLogIndex Unsigned32、nlmLogTimeタイムスタンプ、nlmLogDateAndTime DateAndTime、nlmLogEngineID SnmpEngineID、nlmLogEngineTAddress TAddress、nlmLogEngineTDomain TDomain、nlmLogContextEngineID SnmpEngineID、nlmLogContextName SnmpAdminString、nlmLogNotificationID物の識別子
nlmLogIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A monotonically increasing integer for the sole purpose of
indexing entries within the named log. When it reaches the
maximum value, an extremely unlikely event, the agent wraps the
value back to 1."
::= { nlmLogEntry 1 }
「命名の中でエントリーに索引をつける唯一の目的のための単調に増加する整数は登録する」nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「最大値、非常にありそうもない出来事に達すると、エージェントは値を1に包装して戻します。」 ::= nlmLogEntry1
nlmLogTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the entry was placed in the log. If
the entry occurred before the most recent management system
initialization this object value MUST be set to zero."
::= { nlmLogEntry 2 }
nlmLogTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「エントリーであるときに、sysUpTimeの値は丸太のままで置かれました」。 「エントリーが合わせてくださいこの物の値を設定しなければならないゼロ最新の管理システム初期化の前に現れたなら。」 ::= nlmLogEntry2
nlmLogDateAndTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local date and time when the entry was logged, instantiated
only by systems that have date and time capability."
::= { nlmLogEntry 3 }
「日時の能力を持っているシステムだけによって例示されて、エントリーが登録されたとき、ローカルは、日付を入れて、調節する」nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTimeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= nlmLogEntry3
nlmLogEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The identification of the SNMP engine at which the Notification
nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineIDのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「SNMPエンジンの識別、どれ、Notification、」
Kavasseri Standards Track [Page 15] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[15ページ]。
originated.
溯源にされる。
If the log can contain Notifications from only one engine
or the Trap is in SNMPv1 format, this object is a zero-length
string."
::= { nlmLogEntry 4 }
「ログが1台のエンジンだけからのNotificationsを含むことができるか、またはSNMPv1形式にTrapがあるなら、この物はゼロ長ストリングです。」 ::= nlmLogEntry4
nlmLogEngineTAddress OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The transport service address of the SNMP engine from which the
Notification was received, formatted according to the corresponding
value of nlmLogEngineTDomain. This is used to identify the source
of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted
from the SNMPv1 trap pdu.
nlmLogEngineTAddress OBJECT-TYPE SYNTAX TAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「nlmLogEngineTDomainの換算値に従って、Notificationが受け取られていて、フォーマットされていたSNMPエンジンの輸送サービスアドレス。」 これはSNMPv1罠の源を特定するのに使用されます、SNMPv1罠pduからnlmLogEngineIdを抽出できないので。
This object MUST always be instantiated, even if the log
can contain Notifications from only one engine.
ログが1台のエンジンだけからのNotificationsを含むことができても、いつもこの物を例示しなければなりません。
Please be aware that the nlmLogEngineTAddress may not uniquely
identify the SNMP engine from which the Notification was received.
For example, if an SNMP engine uses DHCP or NAT to obtain
ip addresses, the address it uses may be shared with other
network devices, and hence will not uniquely identify the
SNMP engine."
::= { nlmLogEntry 5 }
nlmLogEngineTAddressが唯一、Notificationが受け取られたSNMPエンジンを特定しないかもしれないのを意識してください。 「例えば、SNMPエンジンがipアドレスを得るのにDHCPかNATを使用すると、それが使用するアドレスは、他のネットワーク装置と共有されるかもしれなくて、したがって、唯一SNMPエンジンを特定しないでしょう。」 ::= nlmLogEntry5
nlmLogEngineTDomain OBJECT-TYPE
SYNTAX TDomain
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the kind of transport service by which a Notification
was received from an SNMP engine. nlmLogEngineTAddress contains
the transport service address of the SNMP engine from which
this Notification was received.
SNMPエンジンからNotificationを受け取りました。nlmLogEngineTDomain OBJECT-TYPE SYNTAX TDomainのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「nlmLogEngineTAddressがどれについて輸送サービスアドレスを含んでいるかによって、輸送の種類がこのNotificationが受け取られたSNMPエンジンを調整するのを示します」。
Possible values for this object are presently found in the
Transport Mappings for SNMPv2 document (RFC 1906 [8])."
::= { nlmLogEntry 6 }
「この物のための可能な値が現在Transport MappingsでSNMPv2ドキュメントに関して見つけられる、(RFC1906[8])、」 ::= nlmLogEntry6
nlmLogContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION
nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineIDのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Kavasseri Standards Track [Page 16] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[16ページ]。
"If the Notification was received in a protocol which has a
contextEngineID element like SNMPv3, this object has that value.
Otherwise its value is a zero-length string."
::= { nlmLogEntry 7 }
「SNMPv3のようなcontextEngineID要素を持っているプロトコルでNotificationを受け取ったなら、この物には、その値があります。」 「さもなければ、値はゼロ長ストリングです。」 ::= nlmLogEntry7
nlmLogContextName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The name of the SNMP MIB context from which the Notification came.
For SNMPv1 Traps this is the community string from the Trap."
::= { nlmLogEntry 8 }
nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「Notificationが来たSNMP MIB文脈の名前。」 「SNMPv1 Trapsに関して、これはTrapからの共同体ストリングです。」 ::= nlmLogEntry8
nlmLogNotificationID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NOTIFICATION-TYPE object identifier of the Notification that
occurred."
::= { nlmLogEntry 9 }
nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「起こったNotificationに関するNOTIFICATION-TYPE物の識別子。」 ::= nlmLogEntry9
-- -- Log Variable Table --
-- -- 可変テーブルを登録してください--
nlmLogVariableTable OBJECT-TYPE
SYNTAX SEQUENCE OF NlmLogVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of variables to go with Notification log entries."
::= { nlmLog 2 }
nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Notification航空日誌記入事項と共に行く変数のテーブル。」 ::= nlmLog2
nlmLogVariableEntry OBJECT-TYPE
SYNTAX NlmLogVariableEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A Notification log entry variable.
アクセスしやすくないnlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntryの現在の記述マックス-ACCESS STATUS「A Notificationログ入口変数。」
Entries appear in this table when there are variables in
the varbind list of a Notification in nlmLogTable."
INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex }
::= { nlmLogVariableTable 1 }
「Notificationのvarbindリストに変数がnlmLogTableにあるとき、エントリーはこのテーブルに現れます。」 nlmLogName、nlmLogIndex、nlmLogVariableIndexに索引をつけてください:、:= nlmLogVariableTable1
NlmLogVariableEntry ::= SEQUENCE {
NlmLogVariableEntry:、:= 系列
Kavasseri Standards Track [Page 17] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[17ページ]。
nlmLogVariableIndex Unsigned32,
nlmLogVariableID OBJECT IDENTIFIER,
nlmLogVariableValueType INTEGER,
nlmLogVariableCounter32Val Counter32,
nlmLogVariableUnsigned32Val Unsigned32,
nlmLogVariableTimeTicksVal TimeTicks,
nlmLogVariableInteger32Val Integer32,
nlmLogVariableOctetStringVal OCTET STRING,
nlmLogVariableIpAddressVal IpAddress,
nlmLogVariableOidVal OBJECT IDENTIFIER,
nlmLogVariableCounter64Val Counter64,
nlmLogVariableOpaqueVal Opaque
}
nlmLogVariableIndex Unsigned32、nlmLogVariableID物の識別子、nlmLogVariableValueType整数、nlmLogVariableCounter32Val Counter32、nlmLogVariableUnsigned32Val Unsigned32、nlmLogVariableTimeTicksVal TimeTicks、nlmLogVariableInteger32Val Integer32、nlmLogVariableOctetStringVal八重奏ストリング、nlmLogVariableIpAddressVal IpAddress、nlmLogVariableOidVal物の識別子、nlmLogVariableOpaqueValが不透明にするnlmLogVariableCounter64Val Counter64
nlmLogVariableIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A monotonically increasing integer, starting at 1 for a given
nlmLogIndex, for indexing variables within the logged
Notification."
::= { nlmLogVariableEntry 1 }
nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「1時に与えられたnlmLogIndex、登録されたNotificationの中で変数に索引をつけるために始まる単調に増加する整数。」 ::= nlmLogVariableEntry1
nlmLogVariableID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The variable's object identifier."
::= { nlmLogVariableEntry 2 }
nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「変数の物の識別子。」 ::= nlmLogVariableEntry2
nlmLogVariableValueType 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 must be instantiated, based on this type."
::= { nlmLogVariableEntry 3 }
nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER、counter32(1)、unsigned32(2)、timeTicks(3)、integer32(4)、ipAddress(5)、octetString(6)、objectId(7)(counter64(8))が(9)について不透明にする、マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「価値のタイプ。」 「このタイプに基づいて従う値の物の唯一無二の1つを例示しなければなりません。」 ::= nlmLogVariableEntry3
nlmLogVariableCounter32Val OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Kavasseri Standards Track [Page 18] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[18ページ]。
"The value when nlmLogVariableType is 'counter32'."
::= { nlmLogVariableEntry 4 }
「nlmLogVariableTypeであるときに、値は'counter32'です。」 ::= nlmLogVariableEntry4
nlmLogVariableUnsigned32Val OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'unsigned32'."
::= { nlmLogVariableEntry 5 }
「nlmLogVariableTypeであるときに、値は'unsigned32nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry5
nlmLogVariableTimeTicksVal OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'timeTicks'."
::= { nlmLogVariableEntry 6 }
「nlmLogVariableTypeであるときに、値は'timeTicks nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry6
nlmLogVariableInteger32Val OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'integer32'."
::= { nlmLogVariableEntry 7 }
「nlmLogVariableTypeであるときに、値は'integer32nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry7
nlmLogVariableOctetStringVal OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'octetString'."
::= { nlmLogVariableEntry 8 }
「nlmLogVariableTypeであるときに、値は'octetString nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry8
nlmLogVariableIpAddressVal OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'ipAddress'.
Although this seems to be unfriendly for IPv6, we
have to recognize that there are a number of older
MIBs that do contain an IPv4 format address, known
as IpAddress.
「nlmLogVariableTypeであるときに、値は'ipAddress nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 これはIPv6に無愛想であるように思えますが、私たちは、IpAddressとして知られているIPv4形式アドレスを含む多くの、より古いMIBsがあると認めなければなりません。
IPv6 addresses are represented using TAddress or
InetAddress, and so the underlying datatype is
IPv6アドレスがTAddressかInetAddressを使用することで表されるので、基本的なデータ型式は表されます。
Kavasseri Standards Track [Page 19] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[19ページ]。
OCTET STRING, and their value would be stored in
the nlmLogVariableOctetStringVal column."
::= { nlmLogVariableEntry 9 }
「OCTET STRING、それらの値がnlmLogVariableOctetStringValコラムに格納されるだろう、」 ::= nlmLogVariableEntry9
nlmLogVariableOidVal OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'objectId'."
::= { nlmLogVariableEntry 10 }
「nlmLogVariableTypeであるときに、値は'objectId nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry10
nlmLogVariableCounter64Val OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'counter64'."
::= { nlmLogVariableEntry 11 }
「nlmLogVariableTypeであるときに、値は'counter64nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述である'、」 ::= nlmLogVariableEntry11
nlmLogVariableOpaqueVal OBJECT-TYPE
SYNTAX Opaque
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value when nlmLogVariableType is 'opaque'."
::= { nlmLogVariableEntry 12 }
「値のいつnlmLogVariableTypeはそうであるか'が不透明にするnlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaqueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、'、」 ::= nlmLogVariableEntry12
-- -- Conformance --
-- -- 順応--
notificationLogMIBConformance OBJECT IDENTIFIER ::=
{ notificationLogMIB 3 }
notificationLogMIBCompliances OBJECT IDENTIFIER ::=
{ notificationLogMIBConformance 1 }
notificationLogMIBGroups OBJECT IDENTIFIER ::=
{ notificationLogMIBConformance 2 }
notificationLogMIBConformance物の識別子:、:= notificationLogMIB3notificationLogMIBCompliances物の識別子:、:= notificationLogMIBConformance1notificationLogMIBGroups物の識別子:、:= notificationLogMIBConformance2
-- Compliance
-- 承諾
notificationLogMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for entities which implement
the Notification Log MIB."
MODULE -- this module
notificationLogMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「Notification Log MIBを実行する実体のための承諾声明。」 MODULE--このモジュール
Kavasseri Standards Track [Page 20] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[20ページ]。
MANDATORY-GROUPS {
notificationLogConfigGroup,
notificationLogStatsGroup,
notificationLogLogGroup
}
義務的なグループnotificationLogConfigGroup、notificationLogStatsGroup、notificationLogLogGroup
OBJECT nlmConfigGlobalEntryLimit
SYNTAX Unsigned32 (0..4294967295)
MIN-ACCESS read-only
DESCRIPTION
"Implementations may choose a limit and not allow it to be
changed or may enforce an upper or lower bound on the
limit."
「実現は、変えるか、または上側の、または、下側のバウンドに限界に押しつけるかもしれないということであることを限界を選んで、それを許容しないかもしれない」OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32(0 .4294967295)MIN-ACCESS書き込み禁止記述。
OBJECT nlmConfigLogEntryLimit
SYNTAX Unsigned32 (0..4294967295)
MIN-ACCESS read-only
DESCRIPTION
"Implementations may choose a limit and not allow it to be
changed or may enforce an upper or lower bound on the
limit."
「実現は、変えるか、または上側の、または、下側のバウンドに限界に押しつけるかもしれないということであることを限界を選んで、それを許容しないかもしれない」OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32(0 .4294967295)MIN-ACCESS書き込み禁止記述。
OBJECT nlmConfigLogEntryStatus
MIN-ACCESS read-only
DESCRIPTION
"Implementations may disallow the creation of named logs."
「ログと命名されて、実現は創造を禁じるかもしれない」OBJECT nlmConfigLogEntryStatus MIN-ACCESS書き込み禁止記述。
GROUP notificationLogDateGroup
DESCRIPTION
"This group is mandatory on systems that keep wall clock
date and time and should not be implemented on systems that
do not have a wall clock date."
GROUP notificationLogDateGroup記述、「このグループを柱時計日時を保つシステムの上で義務的であり、柱時計日付を持っていないシステムの上で実行するべきではありません」。
::= { notificationLogMIBCompliances 1 }
::= notificationLogMIBCompliances1
-- Units of Conformance
-- ユニットの順応
notificationLogConfigGroup OBJECT-GROUP
OBJECTS {
nlmConfigGlobalEntryLimit,
nlmConfigGlobalAgeOut,
nlmConfigLogFilterName,
nlmConfigLogEntryLimit,
nlmConfigLogAdminStatus,
nlmConfigLogOperStatus,
nlmConfigLogStorageType,
nlmConfigLogEntryStatus
}
notificationLogConfigGroup物群対象nlmConfigGlobalEntryLimit、nlmConfigGlobalAgeOut、nlmConfigLogFilterName、nlmConfigLogEntryLimit、nlmConfigLogAdminStatus、nlmConfigLogOperStatus、nlmConfigLogStorageType、nlmConfigLogEntryStatus
Kavasseri Standards Track [Page 21] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[21ページ]。
STATUS current
DESCRIPTION
"Notification log configuration management."
::= { notificationLogMIBGroups 1 }
STATUSの現在の記述「通知ログ構成管理。」 ::= notificationLogMIBGroups1
notificationLogStatsGroup OBJECT-GROUP
OBJECTS {
nlmStatsGlobalNotificationsLogged,
nlmStatsGlobalNotificationsBumped,
nlmStatsLogNotificationsLogged,
nlmStatsLogNotificationsBumped
}
STATUS current
DESCRIPTION
"Notification log statistics."
::= { notificationLogMIBGroups 2 }
notificationLogStatsGroup OBJECT-GROUP OBJECTS、nlmStatsGlobalNotificationsLogged、nlmStatsGlobalNotificationsBumped、nlmStatsLogNotificationsLogged、nlmStatsLogNotificationsBumped、STATUSの現在の記述「通知ログ統計。」 ::= notificationLogMIBGroups2
notificationLogLogGroup OBJECT-GROUP
OBJECTS {
nlmLogTime,
nlmLogEngineID,
nlmLogEngineTAddress,
nlmLogEngineTDomain,
nlmLogContextEngineID,
nlmLogContextName,
nlmLogNotificationID,
nlmLogVariableID,
nlmLogVariableValueType,
nlmLogVariableCounter32Val,
nlmLogVariableUnsigned32Val,
nlmLogVariableTimeTicksVal,
nlmLogVariableInteger32Val,
nlmLogVariableOctetStringVal,
nlmLogVariableIpAddressVal,
nlmLogVariableOidVal,
nlmLogVariableCounter64Val,
nlmLogVariableOpaqueVal
}
STATUS current
DESCRIPTION
"Notification log data."
::= { notificationLogMIBGroups 3 }
notificationLogLogGroup物群対象、nlmLogTime、nlmLogEngineID、nlmLogEngineTAddress、nlmLogEngineTDomain、nlmLogContextEngineID、nlmLogContextName、nlmLogNotificationID、nlmLogVariableID、nlmLogVariableValueType、nlmLogVariableCounter32Val、nlmLogVariableUnsigned32Val、nlmLogVariableTimeTicksVal、nlmLogVariableInteger32Val、nlmLogVariableOctetStringVal、nlmLogVariableIpAddressVal、nlmLogVariableOidVal、nlmLogVariableCounter64Val、nlmLogVariableOpaqueVal; STATUSの現在の記述「通知ログデータ。」 ::= notificationLogMIBGroups3
notificationLogDateGroup OBJECT-GROUP
OBJECTS {
nlmLogDateAndTime
}
STATUS current
notificationLogDateGroup OBJECT-GROUP OBJECTS nlmLogDateAndTime、STATUS海流
Kavasseri Standards Track [Page 22] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[22ページ]。
DESCRIPTION
"Conditionally mandatory notification log data.
This group is mandatory on systems that keep wall
clock date and time and should not be implemented
on systems that do not have a wall clock date."
::= { notificationLogMIBGroups 4 }
「通知がデータを登録するのが条件付きに義務的な」記述。 「このグループを柱時計日時を保つシステムの上で義務的であり、柱時計日付を持っていないシステムの上で実行するべきではありません。」 ::= notificationLogMIBGroups4
END
終わり
4. Intellectual Property
4. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
5. References
5. 参照
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理枠組みについて説明するための構造」、RFC2571、1999年4月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
Kavasseri Standards Track [Page 23] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[23ページ]。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April
1999.
[RFC2572] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス管理モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメント枠組みのバージョン3への序論」RFC2570(1999年4月)。
Kavasseri Standards Track [Page 24] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[24ページ]。
6. Security Considerations
6. セキュリティ問題
Security issues are discussed in Section 3.1.2.
セクション3.1.2で安全保障問題について議論します。
7. Authors' Addresses
7. 作者のアドレス
Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A.
西タスマン・Driveボブ・スチュワートシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A.
西タスマン・Drive Ramanathan KavasseriシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 527 2446 EMail: ramk@cisco.com
以下に電話をしてください。 +1 2446年の408 527メール: ramk@cisco.com
Kavasseri Standards Track [Page 25] RFC 3014 Notification Log MIB November 2000
Kavasseri規格は通知ログMIB2000年11月にRFC3014を追跡します[25ページ]。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kavasseri Standards Track [Page 26]
Kavasseri標準化過程[26ページ]
一覧
スポンサーリンク
