Network Working Group M. MacFaden
Request for Comments: 3512 Riverstone Networks, Inc.
Category: Informational D. Partain
Ericsson
J. Saperia
JDS Consulting, Inc.
W. Tackabury
Gold Wire Technology, Inc.
April 2003
Configuring Networks and Devices with
Simple Network Management Protocol (SNMP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks.
このドキュメントはインターネット標準管理フレームワークとそのプロトコル、簡易ネットワーク管理プロトコル（SNMP）に関心のある読者のために書かれています。特に、それは、構成管理のためのSNMPの有効利用のガイダンスを提供しています。この情報は、ネットワーク要素、管理アプリケーションの開発者、および取得し、自社のネットワークでこの技術を展開しているものを構築ベンダーに関連しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet Standard Management Framework. . . . . . . . 3
1.2. Configuration and the Internet Standard Management
Frame-work. . . . . . . . . . . . . . . . . . . . . . . . 4
2. Using SNMP as a Configuration Mechanism. . . . . . . . . . . . 5
2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . . 6
2.2. Practical Requirements for Transactional Control. . . . . 6
2.3. Practices in Configuration--Verification. . . . . . . . . 7
3. Designing a MIB Module . . . . . . . . . . . . . . . . . . . . 9
3.1. MIB Module Design - General Issues. . . . . . . . . . . . 10
3.2. Naming MIB modules and Managed Objects. . . . . . . . . . 11
3.3. Transaction Control And State Tracking. . . . . . . . . . 12
3.3.1. Conceptual Table Row Modification Practices. . . . 12
3.3.2. Fate sharing with multiple tables. . . . . . . . . 13
3.3.3. Transaction Control MIB Objects. . . . . . . . . . 14
3.3.4. Creating And Activating New Table Rows . . . . . . 15
3.3.5. Summary Objects and State Tracking . . . . . . . . 15
3.3.6. Optimizing Configuration Data Transfer . . . . . . 18
3.4. More Index Design Issues. . . . . . . . . . . . . . . . . 22
3.4.1. Simple Integer Indexing. . . . . . . . . . . . . . 23
3.4.2. Indexing with Network Addresses. . . . . . . . . . 23
3.5. Conflicting Controls. . . . . . . . . . . . . . . . . . . 24
3.6. Textual Convention Usage. . . . . . . . . . . . . . . . . 25
3.7. Persistent Configuration. . . . . . . . . . . . . . . . . 26
3.8. Configuration Sets and Activation . . . . . . . . . . . . 28
3.8.1. Operational Activation Considerations. . . . . . . 28
3.8.2. RowStatus and Deactivation . . . . . . . . . . . . 30
3.9. SET Operation Latency . . . . . . . . . . . . . . . . . . 31
3.9.1. Subsystem Latency, Persistence Latency,
and Activation Latency . . . . . . . . . . . . . . 33
3.10. Notifications and Error Reporting. . . . . . . . . . . . 33
3.10.1. Identifying Source of Configuration Changes . . . 34
3.10.2. Limiting Unnecessary Transmission of
Notifications . . . . . . . . . . . . . . . . . . 34
3.10.3. Control of Notification Subsystem . . . . . . . . 36
3.11 Application Error Reporting . . . . . . . . . . . . . . . 36
3.12 Designing MIB Modules for Multiple Managers . . . . . . . 37
3.13 Other MIB Module Design Issues. . . . . . . . . . . . . . 39
3.13.1. Octet String Aggregations . . . . . . . . . . . . 39
3.13.2 Supporting multiple instances of a MIB Module. . . 40
3.13.3 Use of Special Optional Clauses. . . . . . . . . . 41
4. Implementing SNMP Configuration Agents . . . . . . . . . . . . 41
4.1. Operational Consistency . . . . . . . . . . . . . . . . . 41
4.2. Handling Multiple Managers. . . . . . . . . . . . . . . . 43
4.3. Specifying Row Modifiability. . . . . . . . . . . . . . . 44
4.4. Implementing Write-only Access Objects. . . . . . . . . . 44
5. Designing Configuration Management Software. . . . . . . . . . 44
5.1. Configuration Application Interactions
with Managed Systems. . . . . . . . . . . . . . . . . . . 45
5.1.1. SET Operations . . . . . . . . . . . . . . . . . . 46
5.1.2. Configuration Transactions . . . . . . . . . . . . 46
5.1.3. Tracking Configuration Changes . . . . . . . . . . 47
5.1.4. Scalability of Data Retrieval. . . . . . . . . . . 48
6. Deployment and Security Issues . . . . . . . . . . . . . . . . 48
6.1. Basic assumptions about Configuration . . . . . . . . . . 48
6.2. Secure Agent Considerations . . . . . . . . . . . . . . . 49
6.3. Authentication Notifications. . . . . . . . . . . . . . . 49
6.4. Sensitive Information Handling. . . . . . . . . . . . . . 50
7. Policy-based Management. . . . . . . . . . . . . . . . . . . . 51
7.1. What Is the Meaning of 'Policy-based' . . . . . . . . . . 51
7.2. Organization of Data in an SNMP-Based Policy System . . . 53
7.3. Information Related to Policy-based Configuration . . . . 54
7.4. Schedule and Time Issues. . . . . . . . . . . . . . . . . 56
7.5. Conflict Detection, Resolution and Error Reporting. . . . 56
7.5.1. Changes to Configuration Outside of the
Policy System. . . . . . . . . . . . . . . . . . . 57
7.6. More about Notifications in a Policy System . . . . . . . 57
7.7. Using Policy to Move Less Configuration Data. . . . . . . 57
8. Example MIB Module With Template-based Data. . . . . . . . . . 58
8.1. MIB Module Definition. . . . . . . . . . . . . . . . . . 61
8.2. Notes on MIB Module with Template-based Data. . . . . . . 73
8.3. Examples of Usage of the MIB . . . . . . .. . . . . . . . 74
9. Security Considerations . . . . . . . . . . .. . . . . . . . . 77
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 78
11. Normative References. . . . . . . . . . . . . . . . . . . . . 78
12. Informative References. . . . . . . . . . . . . . . . . . . . 79
13. Intellectual Property . . . . . . . . . . . . . . . . . . . . 81
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 82
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 83
The Internet Standard Management Framework has many components. The purpose of this document is to describe effective ways of applying those components to the problems of configuration management.
インターネット標準管理フレームワークは、多くのコンポーネントがあります。このドキュメントの目的は、構成管理の問題にそれらのコンポーネントを適用する効果的な方法を記述することです。
For reference purposes, the Internet Standard Management Framework presently consists of five major components:
参考のため、インターネット標準管理フレームワークは現在、5つの主要コンポーネントで構成されています。
o An overall architecture, described in RFC 3411 [1].
RFC 3411に記載され、全体的なアーキテクチャ、O [1]。
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 [15], STD 16, RFC 1212 [16] and RFC 1215 [17]. The second version, called SMIv2, is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].
管理の目的のためにオブジェクトとイベントを記述し、命名するためのメカニズムO。管理情報（SMI）のこの構造体の最初のバージョンでSMIv1と呼ばれ、STD 16に記載され、RFC 1155 [15]、STD 16、RFC 1212 [16]およびRFC 1215 [17]。 SMIv2のと呼ばれる第二のバージョン、STD 58、RFC 2578に記載されている[2]、STD 58、RFC 2579 [3]、STD 58、RFC 2580 [4]。
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 [18]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [19]. The third version of the message protocol is called SNMPv3 and described in RFC 3417 [5], RFC 3412 [6] and RFC 3414 [7].
管理情報を転送するためのOメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンのSNMPv1と呼ばれ、STD 15、RFC 1157に記載されている[18]。インターネット標準トラックプロトコルでないSNMPメッセージプロトコルの第2のバージョンは、SNMPv2cのと呼ばれ、RFC 1901 [19]に記載されています。第3のメッセージプロトコルのバージョンのSNMPv3と呼ばれ、RFC 3417に記載されている[5]、RFC 3412 [6]およびRFC 3414 [7]。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [18]. A second set of protocol operations and associated PDU formats is described in RFC 3416 [8].
管理情報にアクセスするためのOプロトコル操作。プロトコル操作と関連PDU形式の第一セットは、STD 15、RFC 1157 [18]に記載されています。プロトコル操作と関連PDU形式の第2のセットは、RFC 3416に記載されている[8]。
o A set of fundamental applications described in RFC 3413 [9] and the view-based access control mechanism described in RFC 3415 [10].
O RFC 3413に記載の基本アプリケーションのセット[9]およびRFC 3415 [10]に記載のビューベースアクセス制御機構。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 3410 [12].
現在のSNMP Management Frameworkへの、より詳細な紹介は、RFC 3410 [12]に記載されています。
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.
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されています。
Data networks have grown significantly over the past decade. This growth can be seen in terms of:
データネットワークは、過去10年間に大幅に成長してきました。この成長は、の観点で見ることができます。
Scale - Networks have more network elements, and the network elements are larger and place more demands on the systems managing them. For example, consider a typical number and speed of interfaces in a modern core network element. A managed metropolitan area network switch can have a port density much greater than the port density built into the expectations of the management systems that predated it. There are also many more interrelationships within and between devices and device functions.
スケール - ネットワークスは、より多くのネットワーク要素を持っているし、ネットワーク要素が大きく、それらを管理するシステムでより多くの要求を置きます。例えば、現代のコアネットワーク要素内のインターフェイスの典型的な数と速度を考えます。管理メトロポリタン・エリア・ネットワーク・スイッチは、それを先行した管理システムの期待に組み込まれたポート密度よりもはるかに大きいポート密度を持つことができます。デバイスとデバイス関数内との間でより多くの相互関係もあります。
Functionality - network devices perform more functions. More protocols and network layers are required for the successful deployment of network services which depend on them.
機能 - ネットワークデバイスは、より多くの機能を実行します。その他のプロトコルとネットワーク層は、それらに依存するネットワークサービスの展開を成功のために必要とされます。
Rate of Change - the nature of modern network services causes updates, additions, and deletions of device configuration information more often than in the past. No longer can it be assumed that a configuration will be specified once and then be updated rarely. On the contrary, the trend has been towards much more frequent changes of configuration information.
変化率 - 近代的なネットワークサービスの性質は、過去に比べより頻繁に更新、追加、およびデバイス構成情報の削除を引き起こします。もはや設定を一度に指定され、その後、ほとんど更新しないことを前提とすることはできません。逆に、トレンドは、構成情報のはるかに頻繁な変更に向けてきました。
Correct configuration of network elements that make up data networks is a prerequisite to the successful deployment of the services on them. The growth in size and complexity of modern networks increases the need for a standard configuration mechanism that is tightly integrated with performance and fault management systems.
データネットワークを構成するネットワーク要素の正しい構成は、それらのサービスの展開を成功させる前提条件です。現代のネットワークの規模と複雑さの成長はしっかりパフォーマンスと障害管理システムと統合された標準的な構成メカニズムの必要性が増します。
The Internet Standard Management Framework has been used successfully to develop configuration management systems for a broad range of devices and networks. A standard configuration mechanism that tightly integrates with performance and fault systems is needed not only to help reduce the complexity of management, but also to enable verification of configuration activities that create revenue-producing services.
インターネット標準管理フレームワークは、デバイスやネットワークの幅広い構成管理システムを開発するのに成功裡に使用されてきました。しっかりパフォーマンスとフォールトシステムと統合標準構成メカニズムは、管理の複雑さを軽減するために、だけでなく、収益をもたらすサービスを作成、構成活動の検証を可能にするだけでなく、必要とされています。
This document describes Current Practices that have been used when designing effective configuration management systems using the Internet Standard Management Framework (colloquially known as SNMP). It covers many basic practices as well as more complex agent and manager design issues that are raised by configuration management. We are not endeavoring to present a comprehensive how-to document for generalized SNMP agent, MIB module, or management application design and development. We will, however, cover points of generalized SNMP software design and implementation practice, where the practice has been seen to benefit configuration management software. So, for example, the requirement for management applications to be aware of agent limitations is discussed in the context of configuration operations, but many issues that a management application developer should consider with regard to manager-agent interactions are left for other documents and resources.
この文書は（口語SNMPとして知られている）は、インターネット標準管理フレームワークを使用して効果的な構成管理システムを設計する際に使用されている現在のプラクティスについて説明します。これは、多くの基本的な慣行並びに構成管理によって提起され、より複雑なエージェントとマネージャの設計上の問題をカバーしています。私たちは、一般のSNMPエージェント、MIBモジュール、または管理アプリケーションの設計と開発のために文書化する方法 - 包括的に提示するために努力されていません。私達は、しかし、実際には、構成管理ソフトウェアの利益のために見てきた一般的なSNMPソフトウェアの設計と実装の練習のカバーポイント。したがって、たとえば、管理アプリケーションのための要件は、設定操作の文脈で議論されているエージェントの制限に注意する必要はなく、管理アプリケーションの開発者は、マネージャー・エージェント間の相互作用に関連して検討すべき多くの問題は、他の文書とリソースのために残されています。
Significant experience has been gained over the past ten years in configuring public and private data networks with SNMP. During this time, networks have grown significantly as described above. A response to this explosive growth has been the development of policy-based configuration management. Policy-Based Configuration Management is a methodology wherein configuration information is derived from rules and network-wide objectives, and is distributed to potentially many network elements with the goal of achieving consistent network behavior throughout an administrative domain.
重要な経験は、SNMPでパブリックおよびプライベートデータネットワークを構成する際に、過去10年間に得られています。前述したように、この時間の間に、ネットワークが大幅に成長してきました。この爆発的な成長への応答は、ポリシーベースの構成管理の開発でした。ポリシーベースの構成管理は、構成情報がルールとネットワーク全体の目標に由来し、かつ管理ドメイン全体一貫したネットワーク動作を実現することを目標に、潜在的に多くのネットワーク要素に配信されている方法論です。
This document presents lessons learned from these experiences and applies them to both conventional and policy-based configuration systems based on SNMP.
この文書では、これらの経験から学んだ教訓を提示し、SNMPに基づいて、両方の従来のポリシーベースの構成システムに適用します。
Configuration activity causes one or more state changes in an element. While it often takes an arbitrary number of commands and amount of data to make up configuration change, it is critical that the configuration system treat the overall change operation atomically so that the number of states into which an element transitions is minimized. The goal is for a change request either to be completely executed or not at all. This is called transactional integrity. Transactional integrity makes it possible to develop reliable configuration systems that can invoke transactions and keep track of an element's overall state and work in the presence of error states.
設定の活動は、要素内の1つまたは複数の状態の変化を引き起こします。それは多くの場合、コマンドや設定の変更を補うためにデータ量の任意の数を取るが、状態の数が、その中に要素の遷移が最小になるように設定システムがアトミック全体の変更操作を扱うことが重要です。目標は、どちらか完全に実行するかどうかで、すべての変更要求のためです。これは、トランザクションの整合性と呼ばれています。トランザクションの整合性は、トランザクションを呼び出すと、エラー状態の存在下での要素の全体的な状態と作業を追跡することができ、信頼性コンフィギュレーションシステムを開発することが可能となります。
Transactions can logically take place at very fine-grained levels such as an individual object instance or in very large aggregations that could include many object instances located in many tables on a managed device. For this reason, reliance on transactional integrity only at the SNMP protocol level is insufficient.
トランザクションは、論理的に、このような個々のオブジェクトのインスタンスとしてまたは管理対象デバイスに多くのテーブルにある多くのオブジェクトインスタンスが含まれる可能性が非常に大規模な集計では非常にきめの細かいレベルで行うことができます。このため、専用のSNMPプロトコルレベルでトランザクションの整合性への依存度が不十分です。
A well-designed and deployed configuration system should have the following features with regard to transactions and transactional integrity.
うまく設計および展開構成システムは、トランザクションとトランザクションの整合性に関して、以下のような特徴を持っている必要があります。
1) Provide for flexible transaction control at many different levels of granularity. At one extreme, an entire configuration may be delivered and installed on an element, or alternately one small attribute may be changed.
1）粒状の多くの異なるレベルで柔軟なトランザクション制御を提供します。一方の極端で、全体の構成が提供され、インストール要素上に、又は交互に小さな属性を変更することができるされてもよいです。
2) The transaction control component should work at and understand a notion of the kind of multi-level "defaulting" as described in Section 7.1. The key point here is that it may make most sense to configure systems at an abstract level rather than on an individual instance by instance basis as has been commonly practiced. In some cases it is more effective to send a configuration command to a system that contains a set of 'defaults' to be applied to instances that meet certain criteria.
2）トランザクション制御成分は、動作およびセクション7.1に記載したように、マルチレベルが「不履行」のような概念を理解するべきです。ここで重要な点は、それが一般に実施されているように、インスタンス単位で抽象的なレベルではなく、個々のインスタンス上のシステムを構成するために、ほとんど意味をなさないかもしれないということです。いくつかのケースでは、一定の基準を満たすインスタンスに適用される「デフォルト」のセットを含むシステムにコンフィギュレーションコマンドを送信することがより効果的です。
3) An effective configuration management system must allow flexibility in the definition of a successful transaction. This cannot be done at the protocol level alone, but rather must be provided for throughout the application and the information that is being managed. In the case of SNMP, the information would be in properly defined MIB modules.
3）効果的な構成管理システムは、成功したトランザクションの定義における柔軟性を可能にしなければなりません。これだけでは、プロトコルレベルで行うことができないのではなく、アプリケーションおよび管理されている情報全体のために提供されなければなりません。 SNMPの場合には、情報が適切に定義されたMIBモジュールであろう。
4) A configuration management system should provide time-indexed transaction control. For effective rollback control, the configuration transactions and their successful or unsuccessful completion status must be reported by the managed elements and stored in a repository that supports such time indexing and can record the user that made the change, even if the change was not carried out by the system recording the change.
4）構成管理システムは、時間インデックストランザクション制御を提供すべきです。変更を行わなかった場合でも、効果的なロールバック制御のために、コンフィギュレーション・トランザクションとその成功または失敗終了状態は、管理対象の要素によって報告されなければならないと、そのような時間のインデックス作成をサポートし、変更を行ったユーザーを記録することができ、リポジトリに保存されています変更を記録するシステムによって。
5) The managed system must support transactional security. This means that depending on who is making the configuration request and where it is being made, it may be accepted or denied based on security policy that is in effect in the managed element.
5）管理対象システムは、トランザクションのセキュリティをサポートしている必要があります。つまり、設定要求を行っている、それが行われている場合、それは管理対象要素で有効になっているセキュリティポリシーに基づいて受け入れまたは拒否することができる人に依存します。
Effective transactional control is a responsibility shared between design, implementation, and operational practice. Transaction control techniques for MIB module design are discussed in Section 3.3. Transaction control considerations for the agent implementation are discussed in Section 5.2.2.
効果的なトランザクション制御は、設計、実装、運用実践の間で共有責任です。 MIBモジュール設計のためのトランザクション制御技術は、3.3節で議論されています。エージェント実装のためのトランザクション制御の考慮事項は、5.2.2項で説明されています。
Verification of expected behavior subsequent to the commitment of change is an integral part of the configuration process. To reduce the chance of making simple errors in configuration, many organizations employ the following change management procedure:
変更のコミットメントの後に期待される動作の検証は、構成プロセスの不可欠な部分です。構成の単純なエラーを作るチャンスを減らすために、多くの組織は、以下の変更管理手順を採用します：
pre-test - verify that the system is presently working properly
事前テスト - システムが現在正常に動作していることを確認
change - make configuration changes and wait for convergence (system or network stability)
変更 - 設定変更を行うと収束（システムやネットワークの安定性）を待ちます
re-test - verify once again that the system is working properly
再テスト - システムが正常に動作していることをもう一度確認してください
This procedure is commonly used to verify configuration changes to critical systems such as the domain name system (DNS). DNS software kits provide diagnostic tools that allow automatic test procedures/scripts to be conducted.
この手順は、一般的に、このようなドメインネームシステム（DNS）などの重要なシステムへの構成の変更を確認するために使用されます。 DNSソフトウェア・キットには、自動テスト手順/スクリプトを行うことを可能にする診断ツールを提供しています。
A planned configuration sequence can be aborted if the pre-configuration test result shows the state of the system as unstable. Debugging the unintended effects of two sets of changes in large systems is often more challenging than an analysis of the effects of a single set after test termination.
事前設定のテスト結果が不安定などのシステムの状態を示している場合、計画構成シーケンスは中止することができます。大規模なシステムの変化の二組の意図しない影響をデバッグすることは、多くの場合、テスト終了後、単一のセットの効果の分析よりも困難です。
Networks and devices under SNMP configuration readily support this change management procedure since the SNMP provides integrated monitoring, configuration and diagnostic capabilities. The key is the sequencing of SNMP protocol operations to effect an integrated change procedure like the one described above. This is usually a well-bounded affair for changes within a single network element or node. However, there are times when configuration of a given element can impact other elements in a network. Configuring network protocols such as IEEE 802.1D Spanning Tree or OSPF is especially challenging since the impact of a configuration change can directly affect stability (convergence) of the network the device is connected to.
SNMPは、統合監視、構成、および診断機能を提供するので、SNMP設定の下でネットワークとデバイスが容易にこの変更管理手順をサポートしています。キーは、上述のような統合された変更手順を行うためにSNMPプロトコル操作の順序です。これは通常、単一のネットワーク要素またはノード内の変化によく有界事件です。しかし、与えられた要素の構成は、ネットワーク内の他の要素に影響を与える可能性がございます。構成変更の影響を直接デバイスが接続されているネットワークの安定（収束）に影響を与えることができるので、このようなIEEE 802.1DスパニングツリーやOSPFのような構成のネットワークプロトコルは、特に困難です。
An integrated view of configuration and monitoring provides an ideal platform from which to evaluate such changes. For example, the MIB module governing IEEE 802.1D Spanning Tree (RFC 1493 [24]) provides the following object to monitor stability per logical bridge.
構成および監視の統合されたビューは、そのような変化を評価するのに理想的なプラットフォームを提供します。例えば、IEEE 802.1Dスパニングツリー（RFC 1493 [24]）を支配するMIBモジュールは、論理ブリッジあたりの安定性を監視するために、以下の目的を提供します。
dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of topology changes detected by
this bridge since the management entity was last
reset or initialized."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
Likewise, the OSPF MIB module provides a similar metric for stability per OSPF area.
同様に、OSPF MIBモジュールはOSPF面積当たりの安定性のための同様の指標を提供します。
ospfSpfRuns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the intra-area route
table has been calculated using this area's
link-state database. This is typically done
using Dijkstra's algorithm."
::= { ospfAreaEntry 4 }
The above object types are good examples of a means of facilitating the principles described in Section 2.3. That is, one needs to understand the behavior of a subsystem before configuration change, then be able to use the same means to retest and verify proper operation subsequent to configuration change.
上記オブジェクトタイプは、セクション2.3で説明される原理を容易にする手段の良い例です。それは1つが、構成の変更後に適切な操作を再テストし、検証するための同様の手段を使用することができ、設定変更前のサブシステムの動作を理解する必要があります。
The operational effects of a given implementation often differ from one to another for any given standard configuration object. The impact of a change to stability of systems such as OSPF should be documented in an agent-capabilities statement which is consistent with "Requirements for IP Version 4 Routers" [22], Section 1.3.4:
所与の実装の作用効果は、多くの場合、任意の標準的な構成オブジェクトのための別の異なります。 OSPFなどのシステムの安定性に与える影響は、「IPバージョン4つのルータのための要件」[22]、セクション1.3.4と一致しているエージェント機能文に記載されるべきです。
A vendor needs to provide adequate documentation on all configuration parameters, their limits and effects.
ベンダーは、すべての設定パラメータ、その限界や効果に関する適切なドキュメントを提供する必要があります。
Adherence to the above model is not fail-safe, especially when configuration errors are masked by long latencies or when configuration errors lead to oscillations in network stability. For example, consider the situation of loading a new software version on a device, which leads to small, slow, cumulative memory leaks brought on by a certain traffic pattern that was not caught during vendor and customer test lab trials.
上記のモデルへの付着は、構成エラーが長い待ち時間とき、または設定エラーがネットワークの安定性に振動を引き起こすことにより、マスクされている場合は特に、フェイルセーフではありません。例えば、ベンダーと顧客のテストラボ試験中にキャッチされていなかった特定のトラフィックパターンによってもたらされた小さな、ゆっくりと、累積メモリリークにつながるデバイス、上の新しいソフトウェアバージョンをロードする状況を考えます。
In a network-based example, convergence in an autonomous system cannot be guaranteed when configuration changes are made since there are factors beyond the control of the operator, such as the state of other network elements. Problems affecting this convergence may not be detected for a significant period of time after the configuration change. Even for factors within the operator's control, there is often little verification done to prevent mis-configuration (as shown in the following example).
そのような他のネットワーク要素の状態などのオペレータのコントロールを超えた要因は、存在するので、構成の変更が行われた場合、ネットワークベースの例では、自律システム内の収束は保証できません。この収束に影響を与える問題は、設定の変更後はかなりの時間のために検出されないことがあります。オペレータのコントロール内の要因のために、（次の例に示すように）設定ミスを防止するために行わ少し検証がしばしばあります。
Consider a change made to ospfIfHelloInterval and ospfIfRtrDeadInterval [24] timers in the OSPF routing protocol such that both are set to the same value. Two routers may form an adjacency but then begin to cycle in and out of adjacency, and thus never reach a stable (converged) state. Had the configuration process described at the beginning of this section been employed, this particular situation would have been discovered without impacting the production network.
ospfIfHelloIntervalとospfIfRtrDeadIntervalへの変更[24]の両方が同じ値に設定されるようにOSPFルーティングプロトコルにタイマーを考慮する。 2台のルータが隣接関係を形成するが、その後に隣接し、外のサイクルに始まり、安定した（収束）状態に到達しない可能性があります。このセクションの冒頭で説明した構成プロセスが採用されていた、この特定の状況は、生産ネットワークに影響を与えることなく、発見されていたであろう。
The important point to remember from this discussion is that configuration systems should be designed and implemented with verification tests in mind.
この議論から覚えておくべき重要な点は、コンフィギュレーション・システムが設計されており、心の中で実証試験を実施しなければならないということです。
Carefully considered MIB module designs are crucial to practical configuration with SNMP. As we have just seen, MIB objects designed for configuration can be very effective since they can be associated with integrated diagnostic, monitoring, and fault objects. MIB modules for configuration also scale when they expose their notion of template object types. Template objects can represent information at a higher level of abstraction than instance-level ones. This has the benefit of reducing the amount of instance-level data to move from management application to the agent on the managed element, when that instance-level data is brought about by applying a template object on the agent. Taken together, all of these objects can provide a robust configuration subsystem.
慎重に検討MIBモジュールの設計は、SNMPでの具体的な構成に重要です。私たちは見てきたように、彼らは統合された診断、モニタリング、および障害オブジェクトに関連付けることができるので、設定のために設計されたMIBオブジェクトは、非常に有効であることができます。彼らは、テンプレートオブジェクトタイプの彼らの概念を公開する際の設定のためのMIBモジュールも拡大します。テンプレートオブジェクトは、インスタンス・レベルのものより抽象度の高い情報を表すことができます。これは、インスタンス・レベルのデータをエージェントにテンプレートオブジェクトを適用することによってもたらされる場合、管理対象要素上のエージェントに管理アプリケーションから移動するインスタンス・レベルのデータの量を減少させるという利点を有します。まとめると、これらのオブジェクトはすべて、堅牢な構成サブシステムを提供することができます。
The remainder of this section provides specific practices used in MIB module design with SMIv2 and SNMPv3.
このセクションの残りの部分は、のSMIv2およびSNMPv3とMIBモジュール設計で使用される特定のプラクティスを提供します。
One of the first tasks in defining a MIB module is the creation of a model that reflects the scope and organization of the management information an agent will expose.
MIBモジュールを定義する際の最初のタスクの1つは、エージェントが公開する管理情報の範囲や組織を反映したモデルの作成です。
MIB modules can be thought of as logical models providing one or more aspects/views of a subsystem. The objective for all MIB modules should be to serve one or more operational requirements such as accounting information collection, configuration of one or more parts of a system, or fault identification. However, it is important to include only those aspects of a subsystem that are proven to be operationally useful.
MIBモジュールが、1つまたは複数の態様/サブシステムのビューを提供するなど、論理モデルと考えることができます。すべてのMIBモジュールの目的は、このような会計情報の収集、システム、または障害の特定の1つ以上の部分の構成として、1つ以上の動作要件を提供するべきです。しかし、操作上有用であることが証明されているサブシステムの側面のみを含めることが重要です。
In 1993, one of most widely deployed MIB modules supporting configuration was published, RFC 1493, which contained the BRIDGE-MIB. It defined the criteria used to develop the MIB module as follows:
1993年には、コンフィギュレーションをサポートしている最も広く導入されているMIBモジュールの一つは、BRIDGE-MIBを含んでいRFC 1493を発表しました。それは次のようにMIBモジュールを開発するために使用する基準を定義しました。
To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion:
IABの指示と良いエンジニアリングの実践と一致するように、明示的な試みが、できるだけシンプルなこのMIBを維持するために作られました。これは含めることが提案オブジェクトに以下の基準を適用することによって達成しました。
(1) Start with a small set of essential objects and add only as further objects are needed.
（1）基本的なオブジェクトの小さなセットを開始し、さらにオブジェクトが必要とされるだけ追加します。
(2) Require objects be essential for either fault or configuration management.
（2）オブジェクトは、障害や構成管理のいずれかのために不可欠であることが必要。
(3) Consider evidence of current use and/or utility.
（3）現在の使用および/または有用性の証拠を考えてみましょう。
(4) Limit the total (sic) of objects.
（4）オブジェクトの合計（SIC）を制限します。
(5) Exclude objects which are simply derivable from others in this or other MIBs.
（5）は、単にこの又は他のMIBで他から誘導されたオブジェクトを除外する。
(6) Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer.
（6）重要なセクションが重くインストルメントさせることは避けてください。続いたガイドラインは、層ごとのクリティカルセクションごとに1つのカウンタです。
Over the past eight years additional experience has shown a need to expand these criteria as follows:
過去8年間で追加の経験は、次のようにこれらの基準を拡大する必要性を示しています。
(7) Before designing a MIB module, identify goals and objectives for the MIB module. How much of the underlying system will be exposed depends on these goals.
（7）MIBモジュールを設計する前に、MIBモジュールのための目標と目的を特定します。どのくらいの基盤となるシステムのは、公開されますこれらの目標に依存します。
(8) Minimizing the total number of objects is not an explicit goal, but usability is. Be sure to consider deployment and usability requirements.
（8）オブジェクトの合計数を最小にすることは、明示的な目標ではなく、使い勝手があります。展開と使いやすさの要件を考慮してください。
(9) During configuration, consider supporting explicit error state, capability and capacity objects.
（9）構成中に、明示的なエラー状態、能力及び容量オブジェクトをサポート考えます。
(10) When evaluating rule (5) above, consider the impact on a management application. If an object can help reduce a management application's complexity, consider defining objects that can be derived.
ルールを評価するとき（10）上記（5）、管理アプリケーションへの影響を考えます。オブジェクトは、管理アプリケーションの複雑さを軽減することができた場合は、導出可能なオブジェクトを定義することを検討してください。
Naming of MIB modules and objects informally follows a set of best practices. Originally, standards track MIB modules used RFC names. As the MIB modules evolved, the practice changed to using more descriptive names. Presently, Standards Track MIB modules define a given area of technology such as ATM-MIB, and vendors then extend such MIB modules by prefixing the company name to a given MIB module as in ACME-ATM-MIB.
MIBモジュールとオブジェクトのネーミングは、非公式のベストプラクティスのセットに従います。もともと、基準はRFC名を使用するMIBモジュールを追跡します。 MIBモジュールが進化するにつれて、実際はもっと説明的な名前を使用するように変更しました。現在、標準化過程MIBモジュールは、ATM-MIBなどの技術の所定の領域を定義し、ベンダーはその後、ACME-ATM-MIBのように与えられたMIBモジュールに会社名を付けることによって、このようなMIBモジュールを拡張します。
Object descriptors (the "human readable names" assigned to object identifiers [2]) defined in standard MIB modules should be unique across all MIB modules. Generally, a prefix is added to each managed object that can help reference the MIB module it was defined in. For example, the IF-MIB uses "if" prefix for descriptors of object types such as ifTable, ifStackTable and so forth.
標準MIBモジュールで定義されたオブジェクト記述子（[2]の識別子をオブジェクトに割り当てられた「人間可読名」）は、すべてのMIBモジュール全体で一意でなければなりません。一般的に、接頭辞は、それが中で定義されたMIBモジュールを参照することができ、各管理対象オブジェクトに付加される。例えば、IF-MIBは、「IF」は、等々のifTable、のifStackTableおよびASオブジェクトタイプの記述子のプレフィックス使用します。
MIB module object type descriptors can include an abbreviation for the function they perform. For example the objects that control configuration in the example MIB module in Section 8 include "Cfg" as part of the object descriptor, as in bldgHVACCfgDesiredTemp.
MIBモジュールのオブジェクトタイプ記述子は、彼らが実行する機能の省略形を含めることができます。例えば、第8の例MIBのモジュール構成を制御するオブジェクトはbldgHVACCfgDesiredTempのように、オブジェクト記述子の一部として「CFG」を含みます。
This is more fully realized when the object descriptors that include the fault, configuration, accounting, performance and security [33] abbreviations are combined with an organized OID assignment approach. For example, a vendor could create a configuration branch in their private enterprises area. In some cases this might be best done on a per product basis. Whatever the approach used, "Cfg" might be included in every object descriptor in the configuration branch. This has two operational benefits. First, for those that do look at instances of MIB objects, descriptors as seen through MIB browsers or other command line tools assist in conveying the meaning of the object type. Secondly, management applications can be pointed at specific subtrees for fault or configuration, causing a more efficient retrieval of data and a simpler management application with potentially better performance.
障害、設定、アカウンティング、性能、およびセキュリティを含むオブジェクト記述子[33]略語を編成OID割り当てアプローチと組み合わされるとき、これは、より完全に実現されます。例えば、ベンダーは彼らの民間企業の領域で構成ブランチを作成することができます。いくつかのケースでは、これは最高の製品ごとに行われる可能性があります。どのようなアプローチが使用され、「CFGは、」構成ブランチ内のすべてのオブジェクト記述子に含まれている場合があります。これは、2つの動作の利点を持っています。まず、MIBブラウザまたはその他のコマンドラインツールを通して見たMIBオブジェクト、ディスクリプタのインスタンスを見ないもののためのオブジェクトタイプの意味を伝えるのに役立ちます。第二に、管理アプリケーションは、潜在的に良好な性能とデータのより効率的な検索と簡単な管理アプリケーションを引き起こし、障害または構成のための特定のサブツリーに指摘することができます。
Transactions and keeping track of their state is an important consideration when performing any type of configuration activity regardless of the protocol. Here are a few areas to consider when designing transaction support into an SNMP-based configuration system.
関係なく、プロトコルの構成活動のいずれかのタイプを実行するとき、その状態のトランザクションと保持トラックは重要な考慮事項です。ここでは、SNMPベースのコンフィギュレーションシステムにトランザクションサポートを設計する際に考慮すべきいくつかの領域です。
Any discussion of transaction control as it pertains to MIB module design often begins with how the creation or modification of object instances in a conceptual row in the MIB module is controlled.
それはMIBモジュールの設計に関連したトランザクション制御のいずれかの議論はしばしばMIBモジュールの概念的な行のオブジェクトインスタンスの作成または変更を制御する方法で始まります。
RowStatus [3] is a standard textual convention for the management of conceptual rows in a table. Specifically, the RowStatus textual convention that is used for the SYNTAX value of a single column in a table controls the creation, deletion, activation, and deactivation of conceptual rows of the table. When a table has been defined with a RowStatus object as one of its columns, changing an instance of the object to 'active' causes the row in which that object instance appears to become 'committed'.
RowStatusの[3]表の概念的な列を管理するための標準的なテキストの表記法です。具体的には、テーブル内の単一の列の構文の値のために使用されRowStatusテキストの表記法は表の概念的な行の作成、削除、アクティブ化、および非アクティブ化を制御します。テーブルは、その列の一つとして、RowStatusオブジェクトで定義されている場合、「アクティブ」へのオブジェクトのインスタンスを変更すると、そのオブジェクトのインスタンスは、「コミット」になるように表示される行を引き起こします。
In a multi-table scenario where the configuration data must be spread over many columnar objects, a RowStatus object in one table can be used to cause the entire set of data to be put in operation or stored based on the definition of the objects.
構成データは、多くの円柱状のオブジェクトの上に広げなければならないマルチテーブルのシナリオでは、一つのテーブルでRowStatusオブジェクトは、データセット全体が動作して置くか、またはオブジェクトの定義に基づいて記憶させるために使用することができます。
In some cases, very large amounts of data may need to be 'committed' all at once. In these cases, another approach is to configure all of the rows in all the tables required and have an "activate" object that has a set method that commits all the modified rows.
いくつかのケースでは、非常に大量のデータを一度に「コミット」する必要があるかもしれません。これらのケースでは、別のアプローチが必要とされるすべての表の行のすべてを設定し、全ての変更された行をコミットし、設定された方法を有する「アクティブ」オブジェクトを有することです。
The RowStatus textual convention specifies that, when used in a conceptual row, a description must define what can be modified. While the description of the conceptual row and its columnar object types is the correct place to derive this information on instance modifiability, it is often wrongly assumed in some implementations that:
RowStatusテキストの表記法は、概念的な列で使用される場合、説明は変更することができるかを定義しなければならないことを指定します。概念的な行とその円柱状のオブジェクト・タイプの記述は、インスタンス修正可能で、この情報を導出するための適切な場所であるが、それはしばしば誤ってそのいくつかの実装形態で想定しています。
1) objects either must all be presently set or none need be set to make a conceptual RowStatus object transition to active(1)
1）（1）すべての現在設定されなければならないか、どれがアクティブに概念的RowStatusオブジェクトの遷移を行うように設定する必要はないいずれかのオブジェクト
2) objects in a conceptual row cannot be modified once a RowStatus object is active(1). Restricting instance modifiability like this, so that after a RowStatus object is set to active(1) is in fact a reasonable limitation, since such a set of RowStatus may have agent system side-effects which depend on committed columnar object instance values. However, where this restriction exists on an object, it should be made clear in a DESCRIPTION clause such as the following:
RowStatusオブジェクトがアクティブになると2）の概念的な行のオブジェクトは、（1）変更することはできません。 RowStatusオブジェクトがアクティブに設定された後にそのようなRowStatusのそのようなセットがコミット円柱状のオブジェクトのインスタンスの値に依存剤系副作用を有することができるので、このようなインスタンスの修正可能を制限する、（1）、実際には合理的な制限です。この制限は、オブジェクト上に存在する場合しかし、それは次のような説明の節において明らかにされるべきです。
protocolDirDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the protocol encapsulation. A probe may choose to describe only a subset of the entire encapsulation (e.g., only the highest layer).
protocolDirDescrのOBJECT-TYPE構文DisplayString（SIZE（1..64））MAX-ACCESSリード作成ステータス現在の説明「プロトコルカプセル化のテキスト記述をプローブは、全体のカプセル化のサブセットのみを説明するために選択することができる（例えば、のみ最上位層）。
This object is intended for human consumption only.
このオブジェクトは人間の消費のために意図されます。
This object may not be modified if the associated
protocolDirStatus object is equal to active(1)."
::= { protocolDirEntry 4 }
Any such restrictions on columnar object instance modification while a row's RowStatus object instance is set to active(1) should appear in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as well.
行のRowStatusオブジェクトインスタンスがアクティブに設定されている円柱状のオブジェクトのインスタンスの修正上の任意のそのような制限は、（1）同様なRowStatus柱状OBJECT-TYPEの記述節に表示されます。
An important principle associated with transaction control is fate sharing of rows in different tables. Consider the case where a relationship has been specified between two conceptual tables of a MIB module (or tables in two different MIB modules). In this context, fate sharing means that when a row of a table is deleted, the corresponding row in the other table is also deleted. Fate sharing in a transaction control context can also be used with the activation of very large configuration changes. If we have two tables that hold a set of configuration information, a row in one table might have to be put in the 'ready' state before the second can be put in the 'ready' state. When that second table can be placed in the 'ready' state, then the entire transaction can be considered to have been 'committed'.
トランザクション制御に関連した重要な原則は、異なる表の行の運命の共有です。関係は、2つの概念的なMIBモジュールのテーブル（または2つの異なるMIBモジュールのテーブル）との間に指定された場合を考えます。この文脈において、運命共有は、テーブルの行が削除された場合、他のテーブル内の対応する行も削除されることを意味します。トランザクション制御コンテキストにおける運命共有はまた、非常に大規模な構成変更の活性化に使用することができます。我々は、構成情報のセットを保持する2つのテーブルを持っている場合は、1つのテーブルの行は、第二が「準備完了」状態に置くことができる前に「準備完了」状態に置くことが必要になる場合があります。その第二の表は、「準備完了」状態に置くことができる場合は、トランザクション全体が「コミット」であったと考えることができます。
Fate sharing of SNMP table data should be explicitly defined where possible using the SMI index qualifier AUGMENTS. If the relationship between tables cannot be defined using SMIv2 macros, then the DESCRIPTION clause of the object types which particularly effect the cross-table relationship should define what should happen when rows in related tables are added or deleted.
SMI指数修飾子AUGMENTSを使用して、可能な場合はSNMPテーブルデータの運命共有は、明示的に定義する必要があります。テーブル間の関係はSMIv2のマクロを使用して定義することができない場合には、特にクロステーブルの関係を行うオブジェクトタイプの記述句は、関連するテーブルの行が追加または削除されたときに起こるべきかを定義すべきです。
Consider the relationship between the dot1dBasePortTable and the ifTable. These tables have a sparse relationship. If a given ifEntry supports 802.1D bridging then there is a dot1dBasePortEntry that has a pointer to it via dot1dBasePortIfIndex.
dot1dBasePortTableとifTableの間の関係を考えてみましょう。これらのテーブルは、まばらな関係を有しています。与えられたifEntryのブリッジング802.1Dをサポートしている場合は、dot1dBasePortIfIndexを経由して、それへのポインタを持っているdot1dBasePortEntryがあります。
Now, what should happen if an ifEntry that can bridge is deleted? Should the object dot1dBasePortIfIndex simply be set to 0 or should the dot1dBasePortEntry be deleted as well? A number of acceptable design and practice techniques can provide the answer to these questions, so it is important for the MIB module designer to provide the guidance to guarantee consistency and interoperability.
ブリッジできますifEntryが削除された場合に今、何が起こるのでしょうか？オブジェクトdot1dBasePortIfIndexは単純に0に設定する必要がありますかdot1dBasePortEntryも同様に削除する必要がありますか？ MIBモジュールの設計者は、一貫性と相互運用性を保証するためのガイダンスを提供することが重要であるので、許容可能な設計と実践テクニックの数は、これらの質問への答えを提供することができます。
To this end, when two tables are related in such a way, ambiguities such as this should be avoided by having the DESCRIPTION clauses of the pertinent row object types define the fate sharing of entries in the respective tables.
この目的のために、二つのテーブルは、このような方法で関連している場合、このような曖昧さは、それぞれのテーブル内のエントリの運命共有を定義する関連行オブジェクトタイプの記述句を有することを避けるべきです。
When a MIB module is defined that includes configuration object types, consider providing transaction control objects. These objects can be used to cause a large transaction to be committed. For example, we might have several tables that define the configuration of a portion of a system. In order to avoid churn in the operational state of the system we might create a single scalar object that, when set to a particular value, will cause the activation of the rows in all the necessary tables. Here are some examples of further usage for such object types:
MIBモジュールはコンフィギュレーション・オブジェクト・タイプを含むことが定義されている場合、トランザクション制御オブジェクトを提供することを検討してください。これらのオブジェクトは、大規模なトランザクションがコミットさせるために使用することができます。例えば、我々は、システムの一部の構成を定義する複数のテーブルを持っているかもしれません。システムの動作状態で解約を避けるために、我々は特定の値に設定すると、必要なすべての表の行の活性化を引き起こすだろう、という単一のスカラーオブジェクトを作成することができます。ここでは、そのようなオブジェクトタイプのため、他の用途のいくつかの例は以下のとおりです。
o Control objects that are the 'write' or 'commit' objects.
「書き込み」または「コミット」オブジェクトであるOコントロールオブジェクト。
Such objects can cause all pending transactions (change MIB object values as a result of SET operations) to be committed to a permanent repository or operational memory, as defined by the semantics of the MIB objects.
そのようなオブジェクトは、MIBオブジェクトの意味論によって定義されるすべての保留中のトランザクションが（SET操作の結果として、MIBオブジェクトの値を変更する）、永久的なリポジトリまたは動作メモリにコミットさせることができます。
o Control objects at different levels of configuration granularity.
Oコントロールは、構成粒度の異なるレベルでのオブジェクト。
One of the decisions for a MIB module designer is what are the levels of granularity that make sense in practice. For example, in the routing area, would changes be allowed on a per protocol basis such as BGP? If allowed at the BGP level, are sub-levels permitted such as per autonomous system? The design of these control objects will be impacted by the underlying software design. RowStatus (see Section 3.3.1) also has important relevance as a general transaction control object.
MIBモジュールの設計者のための意思決定の一つは、実際に意味をなす粒度のレベルが何であるかです。例えば、ルーティングエリアにおいて、変更は、BGPなどのプロトコルごとに許可されますか？ BGPレベルで許可されている場合、サブレベルは、自律システムごとに許可されていますか？これらのコントロールオブジェクトのデザインは、基盤となるソフトウェア設計によって影響を受けることになります。 RowStatusのは（セクション3.3.1を参照）も、一般的なトランザクション制御対象として重要な関連性を持っています。
When designing read-create objects in a table, a MIB module designer should first consider the default state of each object in the table when a row is created. Should an implementation of a standard MIB module vary in terms of the objects that need to be set in order to create an instance of a given row, an agent capabilities statement should be used to name the additional objects in that table using the CREATION-REQUIRES clause.
表にリード作成オブジェクトを設計する際に行が作成されたときに、MIBモジュールの設計者は、最初のテーブル内の各オブジェクトのデフォルト状態を考慮すべきです。標準MIBモジュールの実装では、所与の行のインスタンスを作成するために設定する必要があるオブジェクトの点で変化すべきである、エージェント機能文は-REQUIRES CREATIONを使用して、そのテーブルに追加オブジェクトに名前を付けるために使用されるべきです句。
It is useful when configuring new rows to use the notReady status to indicate row activation cannot proceed.
行の活性化が進むことができない示すために準備中]ステータスを使用して新しい行を設定するときに便利です。
When creating a row instance of a conceptual table, one should consider the state of instances of required columnar objects in the row. The DESCRIPTION clause of such a required columnar object should specify it as such.
概念テーブルの行インスタンスを作成する場合、一つの行の必要な円柱状のオブジェクトのインスタンスの状態を考慮すべきです。このように必要な円柱状のオブジェクトの説明句は、そのように指定する必要があります。
During the period of time when a management application is attempting to create a row, there may be a period of time when not all of these required (and non-defaultable) columnar object instances have been set. Throughout this time, an agent should return a noSuchInstance error for a GET of any object instance of the row until such time that all of these required instance values are set. The exception is the RowStatus object instance, for which a notReady(3) value should be returned during this period.
これらの必要な（非デフォルト値を設定）柱状オブジェクトインスタンスのすべてが設定されていない場合、管理アプリケーションが行を作成しようとしている期間中、一定の時間があってもよいです。この時間を通して、エージェントはこれらの必要なインスタンスのすべての値が設定されているような時間まで、行の任意のオブジェクトインスタンスのGETのためのnoSuchInstanceエラーを返すべきです。例外は、準備中（3）の値は、この期間中に返されるためRowStatusオブジェクトインスタンスです。
One need only be concerned with the notReady value return for a RowStatus object when the row under creation does not yet have all of the required, non-defaultable instance values for the row. One approach to simplifying in-row configuration transactions when designing MIB modules is to construct table rows that have no more instance data for columnar objects than will fit inside a single SET PDU. In this case, the createAndWait() value for the RowStatus columnar object is not required. It is possible to use createAndGo() in the same SET PDU, thus simplifying transactional management.
一つは、作成中の行がまだ行に必要な、非デフォルト値を設定できるインスタンスのすべての値を有していない場合RowStatusオブジェクトのための準備中の値のリターンに関係することのみ必要です。 MIBモジュールを設計する際に、行の構成トランザクションを単純化するための一つのアプローチは、一組のPDUの内部に収まるより円柱状のオブジェクトのためにこれ以上のインスタンス・データを持つテーブルの行を構築することです。この場合、RowStatusの円柱状のオブジェクトのcreateAndWaitに（）値が必要とされません。したがって、トランザクション管理を簡素化し、同じSET PDUにcreateAndGo（）を使用することが可能です。
Before beginning a new set of configuration transactions, a management application might want to checkpoint the state of the managed devices whose configuration it is about to change. There are a number of techniques that a MIB module designer can provide to assist in the (re-)synchronization of the managed systems. These objects can also be used to verify that the management application's notion of the managed system state is the same as that of the managed device.
コンフィギュレーション・トランザクションの新しいセットを開始する前に、管理アプリケーションは、コンフィギュレーション、変わろうとしている管理対象デバイスの状態をチェックポイントすることがあります。 MIBモジュールの設計者は、管理対象システムの（再）同期を支援するために提供することができ、多くの技術があります。これらのオブジェクトは、管理対象システムの状態の管理、アプリケーションの概念は、管理対象デバイスと同じであることを確認するために使用することができます。
These techniques include:
これらの技術は、次のとおりです。
1. Provide an object that reports the number of rows in a table
1.テーブルの行数を報告したオブジェクトを提供します
2. Provide an object that flags when data in the table was last modified.
2.テーブル内のデータが最後に更新されたフラグが変更されたオブジェクトを提供します。
3. Send a notification message (InformRequests are preferable) to deliver configuration change.
3.コンフィギュレーションの変更を配信する（InformRequestsが好ましい）通知メッセージを送信します。
By providing an object containing the number of rows in a table, management applications can decide how best to retrieve a given table's data and may choose different retrieval strategies depending on table size. Note that the availability of and application monitoring of such an object is not sufficient for determining the presence of table data change over a checkpointed duration since an equal number of row creates and deletes over that duration would reflect no change in the object instance value. Additionally, table data change which does not change the number of rows in the table would not be reflected through simple monitoring of such an object instance.
テーブルの行数を含むオブジェクトを提供することにより、管理アプリケーションは、指定されたテーブルのデータを取得するために最善の方法を決定することができ、テーブルのサイズに応じて、異なる検索戦略を選択することができます。そのような物体の、アプリケーション監視の可用性は、行の等しい数が作成され、オブジェクトインスタンス値の変化を反映しないであろうという期間にわたって削除ためチェックポイント期間にわたってテーブルデータ変更の存在を決定するのに十分ではないことに留意されたいです。また、テーブルの行数を変更しないテーブルのデータの変更は、オブジェクトのインスタンスの簡単なモニタリングを介して反射されないであろう。
Instead, the change in the value of any table object instance data can be tracked through an object that monitors table change state as a function of time. An example is found in RFC 2790, Host Resources MIB:
その代わりに、任意のテーブル・オブジェクト・インスタンス・データの値の変化は、時間の関数として表変化状態を監視するオブジェクトを介して追跡することができます。例では、RFC 2790で発見され、リソースMIBをホスト：
hrSWInstalledLastUpdateTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the hrSWInstalledTable
was last completely updated. Because caching of this
data will be a popular implementation strategy,
retrieval of this object allows a management station
to obtain a guarantee that no data in this table is
older than the indicated time."
::= { hrSWInstalled 2 }
A similar convention found in many standards track MIB modules is the "LastChange" type object.
多くの規格で見つかった同様の規則はMIBモジュールが「LastChange」タイプのオブジェクトである追跡します。
For example, the ENTITY-MIB, RFC 2737 [34], provides the following object:
例えば、ENTITY-MIB、RFC 2737 [34]は、以下の目的を提供します。
entLastChangeTime OBJECT-TYPE SYNTAX TimeStamp
entLastChangeTimeのOBJECT-TYPE構文タイムスタンプ
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in any of these tables:
- entPhysicalTable
- entLogicalTable
- entLPMappingTable
- entAliasMappingTable
- entPhysicalContainsTable"
::= { entityGeneral 1 }
This convention is not formalized. There tend to be small differences in what a table's LastChanged object reflects. IF-MIB (RFC 2863 [20]) defines the following:
この規則は、形式化されていません。テーブル最後に変更されたオブジェクトが反映するものでは小さな違いがあるように傾向があります。 IF-MIB（RFC 2863 [20]）は、以下を定義します。
ifTableLastChange 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 ifTable. 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."
::= { ifMIBObjects 5 }
So, if an agent modifies a row with an SNMP SET on ifAdminStatus, the value of ifTableLastChange will not be updated. It is important to be specific about what can cause an object to update so that management applications will be able to detect and more properly act on these changes.
エージェントはのifAdminStatus上のSNMP SETで行を変更する場合ので、ifTableLastChangeの値が更新されません。オブジェクトが管理アプリケーションが検出し、より適切にこれらの変化に基づいて行動することができるようになりますように更新することがありますかについて具体的にすることが重要です。
The final way to keep distributed configuration data consistent is to use an event-driven model, where configuration changes are communicated as they occur. When the frequency of change to configuration is relatively low or polling a cache object is not desired, consider defining a notification that can be used to report all configuration change details.
一貫性のある分散構成データを保持するための最終的な方法は、彼らが起こるように構成の変更が伝達されるイベント駆動型モデルを使用することです。コンフィギュレーションへの変更の頻度が比較的低い場合やポーリングはキャッシュオブジェクトを希望されていない場合は、すべての設定変更の詳細を報告するために使用することができ、通知を定義することを検討してください。
When doing so, the option is available to an SNMPv3 (or SNMPv2c) agent to deliver the notification using either a trap or an inform. The decision as to which PDU to deliver to the recipient is generally a matter of local configuration. Vendors should recommend the use of informs over traps for NOTIFICATION-TYPE data since the agent can use the presence or absence of a response to help know whether it needs to retransmit or not. Overall, it is preferable to use an inform instead of a trap so that changes have a higher likelihood of confirmed end-to-end delivery.
その際、オプションでは、トラップまたは通知のいずれかを使用して通知をお届けするためのSNMPv3（またはSNMPv2cの）エージェントに提供されています。受信者に提供するためにどのPDUに関する決定は、一般的にローカル設定の問題です。エージェントが再送信するかしない必要があるかどうかを知る手助けするために、応答の有無を使用することができますので、ベンダーはNOTIFICATION-TYPEデータのトラップを介して知らせるの使用を推奨します。全体として、変化が確認され、エンドツーエンド配信のより高い可能性を有するように代わりに、トラップの通知用いることが好ましいです。
As a matter of MIB module design, when practical, the NOTIFICATION-TYPE should include in the PDU all of the modified columnar objects in a row of a table. This makes it easier for the management application receiving the notification to keep track of what has changed in the row of a table and perform addition analysis on the state of the managed elements.
MIBモジュールデザイン、実用的な問題として、NOTIFICATION-TYPEは、テーブルの行のPDUで修正円柱状のオブジェクトの全てを含むべきです。これは、テーブルの行に変更されたものを追跡し、管理対象要素の状態に加えて解析を実行するための通知を受けた管理アプリケーションのためにそれが容易になります。
However, the use of notifications to communicate the state of a rapidly changing object may not be ideal either. This leads us back to the MIB module design question of what is the right level of granularity to expose.
しかし、急速に変化するオブジェクトの状態を通信するための通知の使用は、いずれかの理想的ではないかもしれません。これは、公開する粒度の適切なレベルであるもののMIBモジュール設計の質問に私たちをバックつながります。
Finally, having to poll many "LastChange" objects does not scale well. Consider providing a global LastChange type object to represent overall configuration in a given agent implementation.
最後に、多くの「LastChange」オブジェクトをポーリングすることは十分に拡張しません。所与のエージェントの実装で全体構成を表すためにグローバルLastChange型オブジェクトを提供考えます。
Configuration management software should keep track of the current configuration of all devices under its control. It should ensure that the result is a consistent view of the configuration of the network, which can help reduce inadvertent configuration errors.
構成管理ソフトウェアは、その制御下にあるすべてのデバイスの現在の設定を追跡する必要があります。これは、結果は不注意による設定エラーを減らすことができ、ネットワークの構成を、一貫性のあるビューであることを確認する必要があります。
In devices that have very large amounts of configuration data, it can be costly to both the agent and the manager to have the manager periodically poll the entire contents of these configuration tables for synchronization purposes. A benefit of good synchronization between the manager and the agent is that the manager can determine the smallest and most effective set of data to send to managed devices when configuration changes are required. Depending on the table organization in the managed device and the agent implementation, this practice can reduce the burden on the managed device for activation of these configuration changes.
コンフィギュレーション・データの非常に大量に持っているデバイスでは、管理者が定期的に同期目的のために、これらの構成テーブルの内容全体をポーリング持っているエージェントとマネージャの両方に高価なことができます。マネージャとエージェントとの間の良好な同期化の利点は、管理者が設定変更が必要な場合、管理対象デバイスに送信するデータの最小かつ最も効果的なセットを決定できることです。管理対象デバイスでの表編成とエージェントの実装によっては、このような行為は、これらの構成変更の活性化のための管理対象デバイスの負担を軽減することができます。
In the previous section, we discussed the "LastChange" style of object. When viewed against the requirements just described, the LastChange object is insufficient for large amounts of data.
前のセクションでは、我々は、オブジェクトの「LastChange」スタイルを議論しました。今説明した要件に照らして見た場合、LastChangeオブジェクトは、大量のデータには不十分です。
There are three design options that can be used to assist with the synchronization of the configuration data found in the managed device with the manager:
マネージャーと管理対象デバイスで見つかったコンフィギュレーション・データの同期化を支援するために使用することができる3つの設計オプションがあります：
1) Design multiple indices to partition the data in a table logically or break a table into a set of tables to partition the data based on what an application will use the table for
1）論理的にテーブル内のデータを分割またはアプリケーションがテーブルを使用するものに基づいてデータを分割するテーブルのセットにテーブルを分割する複数のインデックスをデザイン
2) Use a time-based indexing technique
2）時間ベースのインデックス技術を使用してください
3) Define a control MIB module that manages a separate data delivery protocol
3）別個のデータ配信プロトコルを管理する制御MIBモジュールを定義
Index design has a major impact on the amount of data that must be transferred between SNMP entities and can help to mitigate scaling issues with large tables.
インデックスのデザインは、SNMPエンティティ間で転送される必要があり、大きなテーブルとスケーリングの問題を軽減するために助けることができるデータの量に大きな影響を与えます。
Many tables in standard MIB modules follow one of two indexing models:
標準MIBモジュールの多くのテーブルは2つのインデックスモデルのいずれかに従います。
- Indexing based upon increasing Integer32 or Unsigned32 values of the kind one might find in an array.
- インデックス1の配列に見つけるかもしれない種類の構文Integer32またはUnsigned32の値を増やすに基づきます。
- Associative indexing, which refers to the technique of using potentially sparse indices based upon a "key" of the sort one would use for a hash table.
- 一つは、ハッシュテーブルの使用する種類の「キー」に基づいて、潜在的にまばらなインデックスを使用する技術を指す連想割り出し、。
When tables grow to a very large number of rows, using an associative indexing scheme offers the useful ability to efficiently retrieve only the rows of interest.
テーブルは連想インデックススキームを使用して行の非常に大きな数、に成長すると効率的に興味のある行のみを取得するための便利な機能を提供しています。
For example, if an SNMP entity exposes a copy of the default-free Internet routing table as defined in the ipCidrRouteTable, it will presently contain around 100,000 rows.
SNMPエンティティがipCidrRouteTableで定義されているデフォルトのないインターネットルーティングテーブルのコピーを公開した場合、それは現在、約10万行が含まれます。
Associative indexing is used in the ipCidrRouteTable and allows one to retrieve, for example, all routes for a given IPv4 destination 192.0.2/24.
連想索引付けは、例えば、所与のIPv4宛先のすべてのルートが/ 24 192.0.2、ipCidrRouteTableで使用され、一方が取得できています。
Yet, if the goal is to extract a copy of the table, the associative indexing reduces the throughput and potentially the performance of retrieval. This is because each of the index objects are appended to the object identifiers for every object instance returned.
目標は、テーブルのコピーを抽出することであるならば、まだ、連想インデックスは、スループットと潜在的に検索のパフォーマンスが低下します。インデックスオブジェクトの各々が返されるすべてのオブジェクトインスタンスのオブジェクト識別子に付加されているためです。
ipCidrRouteEntry OBJECT-TYPE SYNTAX IpCidrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular route to a particular destination, under a particular policy." INDEX { ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop }
ipCidrRouteEntry OBJECT-TYPE構文IpCidrRouteEntry MAX-ACCESSステータス現在の説明「特定のポリシーの下で特定の宛先への特定の経路、。」 INDEX {ipCidrRouteDest、ipCidrRouteMask、ipCidrRouteTos、ipCidrRouteNextHop}
A simple array-like index works efficiently since it minimizes the index size and complexity while increasing the number of rows that can be sent in a PDU. If the indexing is not sparse, concurrency can be gained by sending multiple asynchronous non-overlapping collection requests as is explained in RFC 2819 [32], Page 41 (in the section pertaining to Host Group indexing).
PDUで送信することができる行の数を増加させながら、それはインデックスのサイズと複雑さを最小化するための単純なアレイ状のインデックスを効率的に働きます。インデックスは、スパースでない場合は、同時実行は、RFC 2819で説明されているように、複数の非同期の非重複収集要求を送信することにより得ることができる[32]（グループのインデックスをホストするために関係するセクション）、ページ41。
Should requirements dictate new methods of access, multiple indices can be defined such that both associative and simple indexing can coexist to access a single logical table.
要件は、アクセスの新しい方法を決定する必要があり、複数のインデックスを連想し、シンプルなインデックスの両方を単一の論理テーブルにアクセスするために共存できるように定義することができます。
Two examples follow.
二つの例は以下の通り。
First, consider the ifStackTable found in RFC 2863 [20] and the ifInvStackTable RFC 2864 [33]. They are logical equivalents with the order of the auxiliary (index) objects simply reversed.
まず、のifStackTableは、RFC 2863 [20]及びifInvStackTable RFC 2864 [33]に見出さ考えます。彼らは単に逆補助（インデックス）オブジェクトのための論理的等価物です。
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between
two sub-layers, specifying that one sub-layer runs
on 'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
ifInvStackEntry OBJECT-TYPE
SYNTAX IfInvStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer runs underneath
the other sub-layer. Each sub-layer corresponds to a
conceptual row in the ifTable."
INDEX { ifStackLowerLayer, ifStackHigherLayer }
::= { ifInvStackTable 1 }
Second, table designs that can factor data into multiple tables with well-defined relationships can help reduce overall data transfer requirements. The RMON-MIB, RFC 2819 [32], demonstrates a very useful technique of organizing tables into control and data components. Control tables contain those objects that are configured and change infrequently, and the data tables contain information to be collected that can be large and may change quite frequently.
第二に、明確に定義された関係で複数のテーブルにデータを考慮することができ、テーブルのデザインは、全体的なデータ転送の要件を減らすことができます。 RMON-MIB、RFC 2819 [32]は、制御及びデータ成分にテーブルを編成するのに非常に有用な技術を実証します。制御テーブルが設定され、まれに変更されるそれらのオブジェクトを含み、データテーブルを大きくすることができる、非常に頻繁に変更できる情報を収集することを含みます。
As an example, the RMON hostControlTable provides a way to specify how to collect MAC addresses learned as a source or destination from a given port that provides transparent bridging of Ethernet packets.
一例として、RMON hostControlTableは、イーサネットパケットのトランスペアレント・ブリッジングを提供する特定のポートから送信元または宛先として学習されたMACアドレスを収集する方法を指定する方法を提供します。
Configuration is accomplished using the hostControlTable. It is indexed by a simple integer. While this may seem to be array-like, it is common practice for command generators to encode the ifIndex into this simple integer to provide associative lookup capability.
設定はhostControlTableを用いて達成されます。これは、単純な整数によってインデックスされます。これは、アレイのようであるように見えるかもしれないが、それは、コマンド・ジェネレータは、連想検索機能を提供するために、この単純な整数にするifIndexをエンコードするための一般的な方法です。
The RMON hostTable and hostTimeTable represent dependent tables that contain the results indexed by the hostControlTable entry.
RMONホストテーブルとホスト時間テーブルはhostControlTableエントリによって索引付け結果を含む従属テーブルを表します。
The hostTable is further indexed by the MAC address which provides the ability to reasonably search for a collection, such as the Organizationally Unique Identifier (OUI), the first three octets of the MAC address.
ホストテーブルはさらに、組織固有識別子（OUI）、MACアドレスの最初の3つのオクテットとして、合理コレクションを検索する能力を提供するMACアドレスによってインデックスされます。
The hostTimeTable is designed explicitly for fast transfer of bulk RMON data. It demonstrates how to handle collecting large number of rows in the face of deletions and insertions by providing hostControlLastDeleteTime.
ホスト時間テーブルは、バルクRMONデータの高速転送のために明示的に設計されています。それはhostControlLastDeleteTimeを提供することにより、欠失および挿入の顔に大量の行を収集し処理する方法を示しています。
hostControlLastDeleteTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the last entry
was deleted from the portion of the hostTable
associated with this hostControlEntry. If no
deletions have occurred, this value shall be zero."
::= { hostControlEntry 4 }
The TimeFilter as defined in RFC 2021 [44] and used in RMON2-MIB and Q-BRIDGE-MIB (RFC 2674 [26]) provides a way to obtain only those rows that have changed on or after some specified period of time has passed.
[44] RFC 2021で定義されており、RMON2-MIB及びQ-BRIDGE-MIB（RFC 2674 [26]）で使用されるようなのTimeFilter時間のいくつかの指定された期間以降に変更された行だけを取得する方法を提供するが経過しました。
One drawback to TimeFilter index tables is that a given row can appear at many points in time, which artificially inflates the size of the table when performing standard getNext or getBulk data retrieval.
TimeFilterインデックステーブルの一つの欠点は、所与の行が標準getNextをまたはGETBULKデータ検索を行う際に人為的にテーブルのサイズを膨張させる時、多くの点で現れることができることです。
If the amount of data to transfer is larger than current SNMP design restrictions permit, as in the case of OCTET STRINGS (64k minus overhead of IP/UDP header plus SNMP header plus varbind list plus varbind encoding), consider delivery of the data via an alternate method, such as FTP and use a MIB module to control that data delivery process. In many cases, this problem can be avoided via effective MIB design. In other words, object types requiring this kind of transfer size should be used judiciously, if at all.
転送データの量は、現在のSNMP設計の制約が許すよりも大きい場合、OCTET STRINGS（IP / UDPヘッダーとSNMPヘッダプラスvarbindリストプラスVARBIND符号化の64Kマイナスオーバーヘッド）の場合のように、を介してデータの配信を検討FTPなどの別の方法、及びそのデータ配信処理を制御するために、MIBモジュールを使用します。多くの場合、この問題は、有効なMIBのデザインを経由して回避することができます。全く言い換えれば、転送サイズのこの種を必要とするオブジェクトの種類は、慎重に使用すべきです。
There are many enterprise MIB modules that provide control of the TFTP or FTP protocol. Often the SNMP part defines what to send where and setting an object initiates the operation (for an example, refer to the CISCO-FTP-CLIENT-MIB, discussed in [38]).
TFTPまたはFTPプロトコルの制御を提供する多くの企業MIBモジュールがあります。しばしばSNMP部分がオブジェクトを設定する操作（例えば、[38]で論じCISCO-FTP-CLIENT-MIBを参照）を開始どこで送信するかを定義します。
Various approaches exist for allowing a local agent process running within the managed node to take a template for an object instance (for example for a set of interfaces), and adapt and apply it to all of the actual instances within the node. This is an architecture for one form of policy-based configuration (see [36], for example). Such an architecture, which must be designed into the agent and some portions of the MIB module, affords the efficiency of specifying many copies of instance data only once, along with the execution efficiency of distributing the application of the instance data to the agent.
様々なアプローチは、（インターフェイスのセットのために、例えば）オブジェクトインスタンスのためのテンプレートを取り、ノード内の実際のインスタンスの全てに適合し、適用するために管理ノード内で実行されているローカルエージェントプロセスを可能にするために存在します。これは、ポリシーベースの設定（例えば、[36]参照）の一の形態のためのアーキテクチャです。エージェントとMIBモジュールのいくつかの部分に設計しなければならないようなアーキテクチャは、エージェントにインスタンスデータのアプリケーションを配布の実行効率と一緒に、一度だけインスタンスデータの多数のコピーを特定の効率が得られます。
Other work is currently underway to improve efficiency for bulk SNMP transfer operations [37]. The objective of these efforts is simply the conveyance of more information with less overhead.
他の研究は、バルクSNMP転送動作[37]のための効率を改善するために現在進行中です。これらの取り組みの目的は、単に少ないオーバーヘッドでより多くの情報の伝達です。
Section 3.3.5 described considerations for table row index design as it pertains to the synchronization of changes within sizable table rows. This section simply considers how to specify this syntactically and how to manage indices semantically.
それはかなりのテーブル列内の変更の同期に関連したセクション3.3.5は、テーブルの行インデックス設計の考慮事項が記載されています。このセクションでは、単に文法的にこれを指定する方法と意味的にインデックスを管理する方法を考えています。
In many respects, the design issues associated with indices in a MIB module are similar to those in a database. Care must be taken during the design phase to determine how often and what kind of information must be set or retrieved. The next few points provide some guidance.
多くの点で、MIBモジュールのインデックスに関連付けられた設計上の問題は、データベース内のものと同様です。ケアはどのくらいの頻度を決定するために設計段階で取らなければならず、情報の種類は、設定または取得する必要があります。次のいくつかのポイントは、いくつかのガイダンスを提供します。
When indexing tables using simple Integer32 or Unsigned32, start with one (1) and specify the maximum range of the value. Since object identifiers are unsigned long values, a question that arises is why not index from zero (0) instead of one(1)?
単純Integer32の又はUnsigned32のを使用して、テーブルにインデックスを付ける場合、一方（1）で始まり、値の最大範囲を指定します。オブジェクト識別子は、符号なしの長い値であるため、発生する問題ではなく、一方のゼロからなぜインデックス（0）（1）は？
RFC 2578 [2], Section 7.7, page 28 states the following: Instances identified by use of integer-valued objects should be numbered starting from one (i.e., not from zero). The use of zero as a value for an integer-valued index object type should be avoided, except in special cases. Consider the provisions afforded by the following textual convention from the Interfaces Group MIB module [33]:
RFC 2578 [2]、セクション7.7、ページ28個の状態次の整数値オブジェクトの使用により同定インスタンスは1から始まる番号を付けなければならない（すなわち、ゼロでないから）。整数値のインデックスオブジェクトタイプの値としてゼロを使用することは、特別な場合を除き、避けるべきです。 [33]インタフェースグループMIBモジュールから次のテキストの表記法によって与えられる規定を考慮してください。
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
There are many objects that use IPv4 addresses (SYNTAX IpAddress) as indexes. One such table is the ipAddrTable from RFC 2011 [14] IP-MIB. This limits the usefulness of the MIB module to IPv4. To avoid such limitations, use the addressing textual conventions INET-ADDRESS-MIB [13] (or updates to that MIB module), which provides a generic way to represent addresses for Internet Protocols. In using the InetAddress textual convention in this MIB, however, pay heed to the following advisory found in its description clause:
インデックスとしてIPv4アドレス（構文IPアドレス）を使用する多くのオブジェクトがあります。そのようなテーブルは、RFC 2011 [14] IP-MIBからipAddrTableにあります。これは、IPv4にMIBモジュールの有用性を制限します。そのような制限を回避するために、インターネットプロトコルのアドレスを表現する一般的な方法を提供し、（そのMIBモジュールまたは更新）アドレッシングテキストの表記法をINET-ADDRESS-MIB [13]を使用。このMIBでのInetAddressテキストの表記法を使用して、しかし、その記述節の以下の助言に注意を払います：
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers.
このテキストの表記法は、インデックスオブジェクトの構文として使用される場合、この場合のSMIv2、STD 58で指定された128のサブ識別子の限界の問題があるかもしれない、OBJECT型の宣言は、に「SIZE」句を含まなければなりません潜在的なインスタンスサブ識別子の数を制限します。
One should consider the SMI limitation on the 128 sub-identifier specification when using certain kinds of network address index types. The most likely practical liability encountered in practice has been with DNS names, which can in fact be in excess of 128 bytes. The problem can be, of course, compounded when multiple indices of this type are specified for a table.
ネットワーク・アドレス・インデックス・タイプの特定の種類を使用する場合に一つは、128のサブ識別子仕様にSMI制限を考慮すべきです。実際に発生する最も可能性の高い実用的な責任は、実際には128バイトを超えることができるDNS名、とされています。このタイプの複数のインデックスが表に指定されている場合、問題は、もちろん、配合することができます。
MIB module designers should avoid specifying read-write objects that overlap in function partly or completely.
MIBモジュールの設計者は、部分的または完全に機能的に重複読み書きオブジェクトを指定することは避けてください。
Consider the following situation where two read-write objects partially overlap when a dot1dBasePortEntry has a corresponding ifEntry.
dot1dBasePortEntryは対応のifEntryを有しているときに、2つの読み書きオブジェクトが部分的に重なる次のような状況を考えます。
The BRIDGE-MIB defines the following managed object:
BRIDGE-MIBは、次の管理対象オブジェクトを定義しています。
dot1dStpPortEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The enabled/disabled status of the port."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
The IF-MIB defines a similar managed object:
IF-MIBは、同様の管理対象オブジェクトを定義しています。
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3)
state indicates that no operational packets can be
passed. When a managed system initializes, all
interfaces start with ifAdminStatus in the down(2) state.
As a result of either explicit management action or per
configuration information retained by the managed system,
ifAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state)."
::= { ifEntry 7 }
If ifAdminStatus is set to testing(3), the value to be returned for dot1dStpPortEnable is not defined. Without clarification on how these two objects interact, management implementations will have to monitor both objects if bridging is detected and correlate behavior.
ifAdminStatusがテストに設定されている場合（3）、dot1dStpPortEnableに対して返される値が定義されていません。これら2つのオブジェクトがどのように相互作用するかを明確にせずに、管理の実装では、ブリッジングが検出された場合、両方のオブジェクトを監視し、行動を相関させる必要があります。
The dot1dStpPortEnable object type could have been written with more information about the behavior of this object when values of ifAdminStatus which impact it change. For example, text could be added that described proper return values for the dot1dStpPortEnable object instance for each of the possible values of ifAdminStatus.
dot1dStpPortEnableオブジェクト型は、のifAdminStatusの値が、それは変更の影響このオブジェクトの振る舞いについての詳細で書かれている可能性があります。例えば、テキストは、のifAdminStatusの可能な値のそれぞれについてdot1dStpPortEnableオブジェクトインスタンスのための適切な戻り値を記載したものを添加することができます。
In those cases where overlap between objects is unavoidable, then as we have just described, care should be taken in the description of each of the objects to describe their possible interactions. In the case of an object type defined after an incumbent object type, it is necessary to include in the DESCRIPTION of this later object type the details of these interactions.
オブジェクト間の重複が避けられないような場合では、我々は今説明したように、注意がそれらの可能な相互作用を記述するためにオブジェクトのそれぞれの説明に注意すべきです。現オブジェクトタイプ後に定義されたオブジェクト・タイプの場合には、これらの相互作用の詳細を入力し、この後、オブジェクトの記述に含める必要があります。
Textual conventions should be used whenever possible to create a consistent semantic for an oft-recurring datatype.
OFT-定期的なデータ型の一貫性のセマンティックを作成するために、可能な限りのテキストの表記法を使用する必要があります。
MIB modules often define a binary state object such as enable/disable or on/off. Current practice is to use existing Textual Conventions and define the read-write object in terms of a TruthValue from SNMPv2-TC [3]. For example, the Q-BRIDGE-MIB [26] defines:
MIBモジュールは、多くの場合、有効/無効にするか、オン/オフなどのバイナリ状態オブジェクトを定義します。現在の慣行では、既存のテキストの表記法を使用するとSNMPv2-TC [3]からのTruthValueの点で読み書きオブジェクトを定義することです。例えば、Q-BRIDGE-MIB [26]定義します：
dot1dTrafficClassesEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value true(1) indicates that Traffic Classes are
enabled on this bridge. When false(2), the bridge
operates with a single priority level for all traffic."
DEFVAL { true }
::= { dot1dExtBase 2 }
Textual conventions that have a reasonable chance of being reused in other MIB modules ideally should also be defined in a separate MIB module to facilitate sharing of such object types. For example, all ATM MIB modules draw on the ATM-TC-MIB [39] to reference and utilize common definitions for addressing, service class values, and the like.
理想的には、他のMIBモジュールで再使用されることの妥当な機会を有するテキストの表記法はまた、オブジェクトタイプの共有を容易にするために別個のMIBモジュールで定義されなければなりません。例えば、全てのATM MIBモジュールは、サービスクラス値、等に対処するための共通の定義を参照し、利用するATM-TC-MIB [39]に描画します。
To simplify management, it is recommended that existing SNMPv2-TC based definitions be used when possible. For example, consider the following object definition:
管理を簡単にするために、可能な場合は、既存のSNMPv2-TCベースの定義を使用することをお勧めします。たとえば、次のオブジェクトの定義を考えてみます。
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
This could be defined as follows using existing SNMPv2-TC TruthValue.
これは次のように既存のSNMPv2-TCのTruthValueを使用して定義することができます。
acmePatioLightsOn OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRI2096PTION
"Current status of outdoor lighting. When set to true (1),
this means that the lights are enabled and turned on.
When set to false (2), the lights are turned off."
::= { acmeOutDoorElectricalEntry 3 }
Many network devices have two levels of persistence with regard to configuration data. In the first case, the configuration data sent to the device is persistent only until changed with a subsequent configuration operation, or the system is reinitialized. The second level is where the data is made persistent as an inherent part of the acceptance of the configuration information. Some configuration shares both these properties, that is, that on acceptance of new configuration data it is saved permanently and in memory. Neither of these necessarily means that the data is used by the operational code. Sometimes separate objects are required to activate this new configuration data for use by the operational code.
多くのネットワークデバイスは、コンフィギュレーション・データに関して、持続性の2つのレベルがあります。最初のケースでは、デバイスに送信される構成データは、後続の構成操作で変更、またはシステムが再初期化されるまでの間だけ持続します。データは、コンフィギュレーション情報の受付の固有の一部として永続化される第二のレベルです。一部の設定を共有し、両方のこれらの性質は、つまり、それは、新しいコンフィギュレーション・データの受け入れにそれが恒久的に、メモリに保存されます。これらはいずれも、必ずしもデータが操作コードによって使用されることを意味します。時には別々のオブジェクトは、演算コードで使用するために、この新しいコンフィギュレーション・データをアクティブにするために必要とされます。
However, many SNMP agents presently implement simple persistence models, which do not reflect all the relationships of the configuration data to the actual persistence model as described above. Some SNMP set requests against MIB objects with MAX-ACCESS read-write are written automatically to a persistent store. In other cases, they are not. In some of the latter cases, enterprise MIB objects are required in order to get standard configuration stored, thus making it difficult for a generic application to have a consistent effect.
しかし、多くのSNMPエージェントは、現在、上記のように、実際の永続化モデルに設定データのすべての関係を反映していないシンプルな永続性モデルを実装します。 MAX-ACCESSの読み取りと書き込みとのMIBオブジェクトに対していくつかのSNMPセット要求は永続ストアに自動的に書き込まれます。他の例では、そうではありません。後者の場合のいくつかでは、エンタープライズMIBオブジェクトは、このように、一貫した効果を有するため、一般的なアプリケーションのためにそれが困難、記憶された標準構成を得るために必要とされます。
There are standard conventions for saving configuration data. The first method uses the Textual Convention known as StorageType [3] which explicitly defines a given row's persistence requirement.
コンフィギュレーション・データを保存するための標準的な規則があります。 StorageType [3]が明示的に指定された行の永続性要件を定義するように、第1の方法は、既知のテキストの表記法を使用します。
Examples include the RFC 3231 [25] definition for the schedTable row object schedStorageType of syntax StorageType, as well as similar row objects for virtually all of the tables of the SNMP View-based Access Control Model MIB [10].
例としては、実質的にすべてのSNMPビューベースアクセス制御モデルMIB [10]のテーブルのための構文StorageTypeのschedTable行オブジェクトschedStorageType、ならびに同様の行オブジェクトのためのRFC 3231 [25]の定義を含みます。
A second method for persistence simply uses the DESCRIPTION clause to define how instance data should persist. RFC 2674 [26] explicitly defines Dot1qVlanStaticEntry data persistence as follows:
永続性のための第二の方法は、単にインスタンス・データが持続するべき方法を定義する記述句を使用します。次のようにRFC 2674 [26]は、明示的にDot1qVlanStaticEntryデータの永続性を定義します。
dot1qVlanStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qVlanStaticEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing static configuration information for
each VLAN configured into the device by (local or
network) management. All entries are permanent and will
be restored after the device is reset."
::= { dot1qVlan 3 }
The current practice is a dual persistence model where one can make changes to run-time configuration as well as to a non-volatile configuration read at device initialization. The DISMAN-SCHEDULE-MIB module [25] provides an example of this practice. A row entry of its SchedTable specifies the parameters by which an agent MIB variable instance can be set to a specific value at some point in time and governed by other constraints and directives. One of those is:
現在の練習は1つがだけでなく、デバイスの初期化時に読み、不揮発性コンフィギュレーションに設定を-時に実行するように変更を加えることができ、デュアル永続モデルです。 DISMAN-SCHEDULE-MIBモジュール[25]この方法の例を提供します。そのSchedTableの行エントリはエージェントMIB変数のインスタンスがある時点で特定の値に設定し、他の制約とディレクティブによって管理することが可能なパラメータを指定します。それらの一つは、次のとおりです。
schedStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this scheduled action is kept
in volatile storage and lost upon reboot or if this row is
backed up by non-volatile or permanent storage.
Conceptual rows having the value `permanent' must allow
write access to the columnar objects schedDescr,
schedInterval, schedContextName, schedVariable, schedValue,
and schedAdminStatus. If an implementation supports the schedCalendarGroup, write access must be also allowed to
the columnar objects schedWeekDay, schedMonth, schedDay,
schedHour, schedMinute."
DEFVAL { volatile }
::= { schedEntry 19 }
It is important, however, to reiterate that the persistence is ultimately controlled by the capabilities and features (with respect to the storage model of management data) of the underlying system on which the MIB Module agent is being implemented. This falls into very much the same kind of issue set as, for example, the situation where the size of data storage in the system for a Counter object type is not the same as that in the corresponding MIB Object Type. To generalize, the final word on the "when" and "how" of storage of persistent data is dictated by the system and the implementor of the agent on the system.
これは、永続性が最終的にMIBモジュールのエージェントが実装されている基礎となるシステムの（管理データのストレージモデルに対して）機能及び機能によって制御されることを繰り返すために、しかし、重要です。これは、のように設定問題の非常に同じ種類に該当例えば、カウンターオブジェクト・タイプのシステムのデータ・ストレージのサイズは、対応するMIBオブジェクトタイプと同じではない状況。 、「」の最終単語を一般化し、「どのように」永続的なデータの保存のために、システムとシステム上のエージェントの実装によって決定されます。
An essential notion for configuration of network elements with SNMP is awareness of the difference between the set of one or more configuration objects from the activation of those configuration changes in the actual subsystem. That is, it often only makes sense to activate a group of objects as a single 'transaction'.
SNMPでネットワーク要素を構成するための基本的な概念は、実際のサブシステム内のこれらの構成変更の起動から1つ以上の構成オブジェクトのセットとの間の差の意識です。つまり、それは多くの場合にのみ単一の「トランザクション」などのオブジェクトのグループをアクティブにするために理にかなっています。
A MIB module design must consider the implications of the preceding in the context of changes that will occur throughout a subsystem when changes are activated. This is particularly true for configuration changes that are complex. This complexity can be in terms of configuration data or the operational ramifications of the activation of the changes in the managed subsystem. A practical technique to accommodate this kind of activation is the partitioning of contained configuration sets, as it pertains to their being activated as changes. Any complex configuration should have a master on/off switch (MIB object type) as well as strategically placed on/off switches that partition the activation of configuration data in the managed subsystem. These controls play a pivotal role during the configuration process as well as during subsequent diagnostics. Generally, a series of set operations should not cause an agent to activate each object, causing operational instability to be introduced with every changed object instance. To avoid this liability, ideally a series of Set PDUs can install the configuration and a final set series of PDUs can activate the changes.
MIBモジュールのデザインは変更が活性化されるサブシステム全体で発生する変更の文脈で、先行の影響を考慮しなければなりません。これは、複雑な構成の変更のために特に当てはまります。この複雑さは、構成データや管理サブシステムの変化の活性化の運用波及効果の観点からすることができます。それは変化として活性化され、それらに関連した活性化のこの種を収容するための実用的な技術は、含まれているコンフィギュレーションセットの分割です。任意の複雑な構成では、スイッチ（MIBオブジェクトタイプ）のオン/オフマスターを持っているだけでなく、戦略的に管理サブシステムのコンフィギュレーションデータの活性化を分割/オフスイッチ上に配置されなければなりません。これらのコントロールは、構成プロセス中だけでなく、その後の診断の際に重要な役割を果たしています。一般的に、セットの一連の操作は、すべての変更されたオブジェクトのインスタンスを導入する運用不安定性を引き起こし、各オブジェクトをアクティブにするには、エージェントが発生することはありません。この責任を回避するために、設定したPDUの理想的なシリーズは、コンフィギュレーションおよびPDUの最終セットシリーズをインストールすることができ、変更を有効にすることができます。
During diagnostic situations, certain on/off switches can be set to localize the perceived error instead of having to remove the configuration.
診断状況の間、一定のオン/オフスイッチは、設定を削除する代わりに知覚エラーをローカライズするように設定することができます。
An example of such an object from the OSPF Version 2 MIB [29] is the global ospfAdminStat:
OSPFバージョン2 MIB [29]のようなオブジェクトの例は、グローバルospfAdminStatあります。
ospfAdminStat OBJECT-TYPE
SYNTAX Status
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status of OSPF in the
router. The value 'enabled' denotes that the
OSPF Process is active on at least one interface;
'disabled' disables it on all interfaces."
::= { ospfGeneralGroup 2 }
Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to enabled(2) are clearly spelled out.
他の場所OSPF MIBで、（2）を有効にするospfAdminStat設定の意味が明確に綴られています。
The Scheduling MIB [25] exposes such an object on each entry in the scheduled actions table, along with the corresponding stats object type (with read-only ACCESS) on the scheduled actions row instance.
スケジューリングMIB [25]対応する統計は、スケジュールアクション行インスタンスに（読み取り専用アクセス権を持つ）タイプのオブジェクトに沿って、スケジュールされたアクションテーブルの各エントリにそのようなオブジェクトを公開します。
This reflects a recurring basic design pattern which brings about semantic clarity in the object type usage. A table can expose one columnar object type which is strictly for administrative control. When read, an instance of this object type will reflect its last set or defaulted value. A companion operational columnar object type, with MAX-ACCESS of read-only, provides the current state of activation or deactivation resulting from the last set of the administrative columnar instance. It is fully expected that these administrative and operational columnar instances may reflect different values over some period of time of activation latency, which is why they are separate. Further sections display some of the problems which can result from attempting to combine the operational and administrative row columns into a single object type.
これは、オブジェクト型の使用におけるセマンティック明快もたらす定期的な基本的なデザインパターンを反映しています。テーブルには、管理制御のために厳密に1つの円柱状のオブジェクト型を公開することができます。読まれたとき、このオブジェクト型のインスタンスには、最後に設定またはデフォルト値を反映します。読み取り専用のMAX-ACCESSとコンパニオン動作柱状オブジェクトタイプは、管理柱状インスタンスの最後のセットから得られた活性化または非活性化の現在の状態を提供します。完全にこれらの管理と運用柱状のインスタンスは、彼らが分離されている理由である活性化の待ち時間、時間のいくつかの期間にわたって異なる値を反映することができることが期待されます。さらにセクションは、単一のオブジェクト型に運用および管理行列を結合しようとするから生じ得る問題のいくつかを表示します。
Note that all of this is independent of the RowStatus columnar object, and the notion of 'activation' as it pertains to RowStatus. A defined RowStatus object type should be strictly concerned with the management of the table row itself (with 'activation' indicating "the conceptual row is available for use by the managed device" [3], and not to be confused with any operational activation semantics).
このすべてが、RowStatusの円柱状のオブジェクトから独立していること、および「活性化」の概念は、それがRowStatusのに関係するように注意してください。定義RowStatusオブジェクトタイプは、[3]「概念的な列は管理対象デバイスによる使用のために利用可能である」を示す「活性化」とテーブルの行自体（の管理を厳密に関係であるべきであり、任意の動作活性化セマンティクスと混同されるべきではありません）。
In the following example, schedAdminStatus controls activation of the scheduled action, and schedOperStatus reports on its operational status:
次の例では、schedAdminStatusは、スケジュールされたアクションの起動を制御し、schedOperStatusは、その動作ステータスをレポート：
schedAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The desired state of the schedule."
DEFVAL { disabled }
::= { schedEntry 14 }
schedOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2),
finished(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of this schedule. The state
enabled(1) indicates this entry is active and that the
scheduler will invoke actions at appropriate times. The
disabled(2) state indicates that this entry is currently
inactive and ignored by the scheduler. The finished(3)
state indicates that the schedule has ended. Schedules
in the finished(3) state are ignored by the scheduler.
A one-shot schedule enters the finished(3) state when it
deactivates itself."
::= { schedEntry 15 }
RowStatus objects should not be used to control activation/deactivation of a configuration. While RowStatus looks ideally suited for such a purpose since a management application can set a row to active(1), then set it to notInService(2) to disable it then make it active(1) again, there is no guarantee that the agent won't discard the row while it is in the notInService(2) state. RFC 2579 [3], page 15 states:
RowStatusのオブジェクトは、構成の活性化/非活性化を制御するために使用すべきではありません。 RowStatusの管理アプリケーションがアクティブに行を設定することができるので、そのような目的のために理想的に適し探しながら（1）、次いで（1）再び、エージェントという保証がない、（2）それがアクティブにそれを無効にするためのnotInServiceに設定それはnotInServiceの（2）の状態にある間に行を破棄しないであろう。 RFC 2579 [3]、15ページ状態：
The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be.
エージェントは、時間の異常に長い期間、どちらかの状態になっている概念的な列を検出し、それらを削除する必要があります。時間の異常に長い期間がどうなるかを示すために、ステータスカラムの記述節の責任です。
The DISMAN-SCHEDULE-MIB's managed object schedAdminStatus demonstrates how to separate row control from row activation. Setting the schedAdminStatus to disabled(2) does not cause the row to be aged out/removed from the table.
DISMAN-SCHEDULE-MIBの管理対象オブジェクトschedAdminStatusは、行活性化から行制御を分離する方法を示します。 （2）行がテーブルから削除/エージアウトされることはありません無効にschedAdminStatusを設定します。
Finally, a reasonable agent implementation must consider how many rows will be allowed to be created in the notReady/notInService state such that resources are not exhausted by an errant application.
最後に、合理的なエージェントの実装は、リソースが誤ったアプリケーションによって排出されないようにNOTREADY / notInServiceの状態で作成することが許可される行数を考慮する必要があります。
Many standards track and enterprise MIB modules that contain read-write objects assume that an agent can complete a set operation as quickly as an agent can send back the status of the set operation to the application.
多くの規格読み書きオブジェクトを含むトラックおよびエンタープライズMIBモジュールは、エージェントがアプリケーションに設定された操作の状況を送り返すことができますよう迅速剤として設定された操作を完了できることを前提としています。
Consider the subtle operational shortcomings in the following object. It both reports the current state and allows a SET operation to change to a possibly new state.
次のオブジェクトの微妙な操作欠点を考えてみましょう。これは、両方のは、現在の状態を報告し、SET操作は、おそらく新しい状態に変更することができます。
wheelRotationState OBJECT-TYPE
SYNTAX INTEGER { unknown(0),
idle(1),
spinClockwise(2),
spinCounterClockwise(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The current state of a wheel."
::= { XXX 2 }
With the object defined, the following example represents one possible transaction.
定義されたオブジェクトを使用すると、以下の例では、一つの可能なトランザクションを表します。
Time Command Generator --------> <--- Command Responder
----- ----------------- -----------------
|
A GetPDU(wheelRotationState.1.1)
|
| ResponsePDU(error-index 0,
| error-code 0)
|
B wheelRotationState.1.1 == spinClockwise(2)
|
C SetPDU(wheelRotationState.1.1 =
| spinCounterClockwise(3)
|
| ResponsePDU(error-index 0,
| error-code 0)
|
D wheelRotationState.1.1
== spinCounterClockwise(3)
|
E GetPDU(wheelRotationState.1.1)
|
F ResponsePDU(error-index 0,
| error-code 0)
|
V wheelRotationState.1.1 == spinClockwise(2)
....some time, perhaps seconds, later....
|
G GetPDU(wheelRotationState.1.1)
|
H ResponsePDU(error-index 0,
| error-code 0)
| wheelRotationState.1.1
V == spinCounterClockwise(3)
The response to the GET request at time E will often confuse management applications that assume the state of the object should be spinCounterClockwise(3). In reality, the wheel is slowing down in order to come to the idle state then begin spinning counter clockwise.
時間EでGET要求に対する応答は、多くの場合、spinCounterClockwiseあるべきオブジェクトの状態を想定し、管理アプリケーションを混乱させます（3）。現実には、ホイールは反時計回りに回転し始め、その後、アイドル状態に来るために減速しています。
This possibility of confusing and paradoxical interactions of administrative and operational state is inevitable when a single object type is used to control and report on both types of state. One common practice which we have already seen is to separate out the desired (settable) state from current state. The objects ifAdminStatus and ifOperStatus from RFC 2863 [20] provide such an example of the separation of objects into desired and current state.
単一のオブジェクトタイプが制御および状態の両方のタイプを報告するために使用されたときに管理および動作状態の混乱と逆説的な相互作用のこの可能性は避けられません。我々はすでに見てきた一つの一般的な方法は、現在の状態から所望の（設定可能）状態を分離することです。 [20] RFC 2863からオブジェクトのifAdminStatusとのifOperStatusは、所望と、現在の状態へのオブジェクトの分離のような例を提供します。
A second way latency can be introduced in SET operations is caused by delay in agent implementations that must interact with loosely coupled subsystems. The time it takes the instrumented system to accept the new configuration information from the SNMP agent, process it and 'install' the updated configuration in the system or otherwise process the directives can often be longer than the SNMP response timeout.
待ち時間がSET操作で導入することができる第二の方法は、疎結合されたサブシステムと相互作用しなければならないエージェントの実装の遅延により引き起こされます。時間は、それは、SNMPエージェント、プロセスからそれを新しい構成情報を受け入れて、システムに更新された設定を「インストール」またはその他のディレクティブは、多くの場合、SNMPの応答タイムアウトよりも長くすることができます処理するために、インストルメントシステムをとります。
In these cases, it is desirable to provide a "current state" object type which can be polled by the management application to determine the state of control of the loosely coupled subsystem which was affected by its configuration update.
これらの場合には、その構成の更新によって影響を受けた疎結合サブシステムの制御の状態を決定するために、管理アプリケーションによってポーリングすることができ、「現在の状態」オブジェクトタイプを提供することが望ましいです。
More generally, some MIB objects may have high latencies associated with changes to their values. This could be either a function of saving the changed value to a persistent storage type, and/or activating a subsystem that inherently has high latency as discussed above. When defining such MIB objects, it might be wise to have the agent process set operations in the managed subsystem as soon as the Set PDU has been processed, and then update appropriate status objects when the save-to- persistent storage and (if applicable) activation has succeeded or is otherwise complete. Another approach would be to cause a notification to be sent that indicates that the operation has been completed.
より一般的には、いくつかのMIBオブジェクトは、それらの値の変更に関連する高い待ち時間を有していてもよいです。これは、永続ストレージタイプに変更された値を保存する機能、および/または上述したように本質的に高いレイテンシーを持つサブシステムを起動するのいずれかである可能性があります。そのようなMIBオブジェクトを定義するとき、それはセットのPDUが処理されるとすぐに管理サブシステムにエージェント・プロセスの集合演算を持つことが賢明で、その後、適切なステータスのオブジェクトを更新する可能性がある場合、保存・ツー・永続ストレージおよび（該当する場合）活性化が成功したか、そうでなければ完了ですました。別のアプローチは、操作が完了したことを示す送信する通知を引き起こすことであろう。
When you describe an activation object, the DESCRIPTION clauses for these objects should give a hint about the likely latency for the completion of the operation. Keep in mind that from a management software perspective (as presented in the example of schedAdminStatus in Section 3.8.1), the combined latency of saving-to-persistence and activation are not distinguishable when they are part of a single operation.
アクティベーションオブジェクトを記述すると、これらのオブジェクトの記述節は、操作の完了のための可能性が高いの待ち時間についてのヒントを与える必要があります。彼らは、単一の操作の一部である場合、管理ソフトウェアの観点（セクション3.8.1でschedAdminStatusの例で提示される）から、省への永続性および活性化の組み合わせ待ち時間が区別できないことに注意してください。
For the purpose of this section, a 'notification' is as described in the SMIv2, RFC 2578 [2], by the NOTIFICATION-TYPE macro. Notifications can be sent in either SNMPv2c [19] or SNMPv3 TRAP or InformRequest PDUs. Given the sensitivity of configuration information, it is recommended that configuration operations always be performed using SNMPv3 due to its enhanced security capabilities. InformRequest PDUs should be used in preference to TRAP PDUs since the recipient of the InformRequest PDUs responds with a Response PDU. This acknowledgment can be used to avoid unnecessary retransmission of NOTIFICATION-TYPE information when retransmissions are in fact required. The use of InformRequest PDUs (as opposed to TRAPs) is not at the control of the MIB module designer or agent implementor. The determination as to whether or not a TRAP or InformRequest PDU is sent from an SNMPv2c or SNMPv3 agent is generally a function of the agent's local configuration (but can be controlled with MIB objects in SNMPv3). To the extent notification timeout and retry values are determined by local configuration parameters, care should be taken to avoid unnecessary retransmission of InformRequest PDUs.
このセクションの目的のためのSMIv2に記載されているように、「通知」であり、RFC 2578 [2]、NOTIFICATION-TYPEマクロによって。通知はSNMPv2cの[19]またはSNMPv3のトラップまたはInformRequestのPDUのいずれかで送信することができます。コンフィギュレーション情報の感度を考えると、構成操作は、常に、その強化されたセキュリティ機能へのSNMPv3を使用して実行することをお勧めします。 InformRequest PDUの受信者が応答PDUで応答するためInformRequestのPDUは、トラップのPDUに優先して使用すべきです。この確認は、再送信が実際に必要とされるとき、NOTIFICATION-TYPE情報の不必要な再送信を回避するために使用することができます。 InformRequest PDUの使用は、（トラップとは対照的に）MIBモジュールの設計者またはエージェントの実装の制御ではありません。 TRAP又はInformRequest PDUをSNMPv2cのまたはSNMPv3のエージェントから送信されたか否かの決意は、一般に、エージェントのローカル構成の関数である（しかし、SNMPv3がMIBオブジェクトを制御することができます）。エクステント通知タイムアウトと値はローカル構成パラメータによって決定されるリトライ、注意がInformRequest PDUの不必要な再送信を回避するように注意しなければなりません。
Configuration change and error information conveyed in InformRequest PDUs can be an important part of an effective SNMP-based management system. They also have the potential to be overused. This section offers some guidance for effective definition of NOTIFICATION-TYPE information about configuration changes that can be carried in InformRequest PDUs. Notifications can also play a key role for all kinds of error reporting from hardware failures to configuration and general policy errors. These types of notifications should be designed as described in Section 3.11 (Application Error Reporting).
InformRequestのPDUで搬送構成変更やエラー情報は、効果的なSNMPベースの管理システムの重要な一部となることができます。彼らはまた、過剰に使用される可能性があります。このセクションでは、InformRequest PDUの中で実施することができる構成の変更についてのNOTIFICATION-TYPE情報の効果的な定義のためのいくつかのガイダンスを提供しています。通知はまた、すべての設定にハードウェア障害からの報告、エラーの種類と一般的な政策の誤りのために重要な役割を再生することができます。 3.11節（アプリケーションエラーレポート）で説明したように、通知のこれらのタイプは、設計すべきです。
A NOTIFICATION-TYPE designed to report configuration changes should report the identity of the management entity initiating the configuration change. Specifically, if the entity is known to be a SNMP command generator, the transport address and SNMP parameters as found in table snmpTargetParamsTable from RFC 3413 SNMP-TARGET-MIB should be reported where possible. For reporting of configuration changes outside of the SNMP domain, the applicable change mechanism (for example, CLI vs. HTTP-based management client access) should be reported, along with whatever notion of "user ID" of the change initiator is applicable and available.
構成の変更を報告するように設計NOTIFICATION-TYPEは、設定の変更を開始する管理エンティティのアイデンティティを報告する必要があります。表たsnmpTargetParamsTableに見られるようなエンティティがRFCからSNMPコマンド生成、トランスポートアドレスとSNMPパラメータであることが知られている場合、具体的に、3413 SNMP-TARGET-MIBは、可能な場合に報告されるべきです。 （HTTPベースの管理クライアントアクセス対例えば、CLI）、該当する変更機構SNMPドメインの外の構成変更の報告について適用し、利用できるものは何でも変更開始剤の「ユーザーID」の概念とともに、報告する必要があります。
The design of event-driven synchronization models, essential to configuration management, can use notifications as an important enabling technique. Proper usage of notifications allows the manager's view of the managed element's configuration to be in close synchronization with the actual state of the configuration of the managed element.
構成管理に不可欠なイベント駆動型の同期モデルの設計は、重要なことが可能な技術として通知を使用することができます。通知の適切な使用は、管理対象要素のコンフィギュレーションの管理者の見解は、管理対象要素のコンフィギュレーションの実際の状態と密接に同期することができます。
When designing new NOTIFICATION-TYPEs, consider how to limit the number of notifications PDUs that will be sent with the notification information defined in the NOTIFICATION-TYPE in response to a configuration change or error event.
新しいNOTIFICATION-型を設計する場合、設定変更やエラーイベントに応答してNOTIFICATION-TYPEで定義された通知情報を送信されます通知PDUの数を制限する方法を検討してください。
InformRequest PDUs, when compared to TRAP PDUs, have an inherent advantage when the concern is the reduction of unnecessary messages from the system generating the NOTIFICATION-TYPE data, when in fact retransmission of this data is required. That is, an InformRequest PDU is acknowledged by the receiving entity with a Response PDU. The receipt of this response allows the entity which generated the InformRequest PDU to verify (and record an audit entry, where such facilities exist on the agent system) that the message was received. As a matter of notification protocol, this receipt guarantee is not available when using TRAP PDUs, and if it is required, must be accomplished by the agent using some mechanism out of band to SNMP, and usually requiring the penalty of polling.
TRAP PDUのと比較した場合、実際には、このデータの再送信が要求される場合に懸念は、NOTIFICATION-TYPEデータを生成するシステムからの不要なメッセージの削減である場合InformRequest PDUは、固有の利点を有します。すなわちInformRequest PDUは、応答PDUと、受信エンティティによって承認されています。この応答の受信は、メッセージが受信されたこと（そのような施設は、エージェントシステム上に存在し、監査エントリを記録）を確認するためにInformRequest PDUを生成したエンティティを可能にします。 TRAP PDUを使用するときに通知プロトコルの問題として、この領収書の保証は利用できません、それが必要な場合は、SNMPに帯域外いくつかのメカニズムを使用して、通常のポーリングのペナルティを必要とするエージェントによって達成されなければなりません。
Regardless of the specific PDUs used to convey them, one way to limit the unnecessary generation of notifications is to include in the NOTIFICATION-TYPE definition situations where it need not be sent. A good example is the frDLCIStatusChange defined in FRAME-RELAY-DTE-MIB, RFC 2115 [21].
関係なく、それらを伝えるために使用される特定のPDUの、通知の不要な生成を制限するための一つの方法は、それが送信される必要がないNOTIFICATION-TYPEの定義の状況に含めることです。良い例は、フレームリレーDTE-MIBで定義されfrDLCIStatusChange、RFC 2115 [21]です。
frDLCIStatusChange NOTIFICATION-TYPE
OBJECTS { frCircuitState }
STATUS current
DESCRIPTION
"This trap indicates that the indicated Virtual Circuit
has changed state. It has either been created or
invalidated, or has toggled between the active and
inactive states. If, however, the reason for the state
change is due to the DLCMI going down, per-DLCI traps
should not be generated."
::= { frameRelayTraps 1 }
There are a number of other techniques which can be used to reduce the unwanted generation of NOTIFICATION-TYPE information. When defining notifications, the designer can specify a number of temporal limitations on the generation of specific instances of a NOTIFICATION-TYPE. For example, a definition could specify that messages will not be sent more frequently than once every 60 seconds while the condition which led to the generation of the notification persists. Alternately, a NOTIFICATION-TYPE DESCRIPTION clause could provide a fixed limit on the number of messages sent over the duration of the condition leading to sending the notification.
NOTIFICATION-TYPE情報の望ましくない発生を低減するために使用することができる他の多くの技術が存在します。通知を定義する場合、設計者はNOTIFICATION-TYPEの特定のインスタンスの生成に時間的な制限の数を指定することができます。たとえば、定義は通知の世代につながった状態が続いている間、メッセージが60秒ごとに1回よりも頻繁に送信されないことを指定できます。交互に、NOTIFICATION-TYPE説明句は、通知の送信につながる条件の期間にわたって送信されたメッセージの数に一定の制限を提供することができます。
If NOTIFICATION-TYPE transmission is "aggregated" in some way - bounded either temporally or by absolute system state change as described above - the optimal design technique is to have the data delivered with the notification reference the actual number of underlying managed element transitions which brought about the notification. No matter which threshold is chosen to govern the actual transmission of NOTIFICATION-TYPEs, the idea is to describe an aggregated event or related set of events in as few PDUs as possible.
NOTIFICATION-TYPE送信が何らかの方法で「集約」である場合、 - 上記のように一時的または絶対的なシステム状態の変化のいずれかによって囲ま - 最適設計手法は、データが通知参照してもたらさ根底にある管理対象要素遷移の実際の数を配信することです通知に関する。 NOTIFICATION-型の実際の送信を支配するように選択された閾値に関係なく、アイデアは、集約イベント又はできるだけ少ないのPDU内のイベントの関連セットを記述することです。
There are standards track MIB modules that define objects that either augment or overlap control of notifications. For instance, FRAME-RELAY-DTE-MIB RFC 2115 defines frTrapMaxRate and DOCS-CABLE-DEVICE-MIB defines a set of objects in docsDevEvent that provide for rate limiting and filtering of notifications.
基準があります強化や通知の制御をオーバーラップするいずれかのオブジェクトを定義するMIBモジュールを追跡します。例えば、フレームリレーDTE-MIBのRFC 2115 frTrapMaxRateを定義し、DOCS-CABLE-DEVICE-MIBは、速度制限および通知のフィルタリングを提供するdocsDevEventのオブジェクトのセットを定義します。
In the past, agents did not have a standard means to configure a notification generator. With the availability of the SNMP-NOTIFICATION-MIB module in RFC 3413 [9], it is strongly recommended that the filtering functions of this MIB module be used. This MIB facilitates the mapping of given NOTIFICATION-TYPEs and their intended recipients.
過去には、薬剤は、通知生成器を構成するための標準的な手段を持っていませんでした。 RFC 3413でSNMP-NOTIFICATION-MIBモジュールの利用可能性を有する[9]、強く、このMIBモジュールのフィルタリング機能を使用することが推奨されます。このMIBは、与えられたNOTIFICATION-種類とその目的の受信者のマッピングを容易にします。
If the mechanisms of the SNMP-NOTIFICATION-MIB are not suitable for this application, a explanation of why they are not suitable should be included in the DESCRIPTION clause of any replacement control objects.
SNMP-NOTIFICATION-MIBのメカニズムはこの用途に適していない場合、彼らは適切ではない理由の説明は、任意の置換制御オブジェクトの説明節に含まれるべきです。
MIB module designers should not rely on the SNMP protocol error reporting mechanisms alone to report application layer error state for objects that accept SET operations.
MIBモジュールの設計者は、SET操作を受け入れるオブジェクトのためのアプリケーション層のエラー状態を報告するだけではSNMPプロトコルエラー報告メカニズムに依存しないでください。
Most MIB modules that exist today provide very little detail as to why a configuration request has failed. Often the only information provided is via SNMP protocol errors which generally does not provide enough information about why an agent rejected a set request. Typically, there is an incumbent and sizable burden on the configuration application to determine if the configuration request failure is the result of a resource issue, a security issue, or an application error.
今日存在するほとんどのMIBモジュールは、設定要求が失敗した理由としてはほとんど詳細を提供します。多くの場合、提供される唯一の情報は一般的に、エージェントが設定された要求を拒否した理由について十分な情報を提供していないSNMPプロトコルエラーによるものです。典型的には、構成要求の失敗は、リソースの問題、セキュリティ上の問題、またはアプリケーションエラーの結果であるかどうかを決定するために設定アプリケーションに現職とかなりの負担があります。
Ideally, when a "badValue" error occurs for a given set request, an application can query the agent for more details on the error. A badValue does not necessarily mean the command generator sent bad data. An agent could be at fault. Additional detailed diagnostic information may aid in diagnosing conditions in the integrated system.
「エラーBadValue」エラーが与えられた一連の要求のために発生した場合に理想的には、アプリケーションがエラーの詳細については、エージェントに照会することができます。 BADVALUEは必ずしもコマンドジェネレータは、不良データを送ったという意味ではありません。エージェントは、障害である可能性があります。追加の詳細な診断情報が統合されたシステムでの状態を診断するのを助けることができます。
Consider the requirement of conveying error information about a MIB expression 'object' set within the DISMAN-EXPRESSION-MIB [40] that occurs when the expression is evaluated. Clearly, none of the available protocol errors are relevant when reporting an error condition that occurs when an expression is evaluated. Instead, the DISMAN-EXPRESSION-MIB provides objects to report such errors (the expErrorTable). Instead, the expErrorTable maintains information about errors that occur at evaluation time:
式が評価されるときに発生DISMAN-EXPRESSION-MIB [40]に設定MIB式「オブジェクト」に関するエラー情報を伝えるの要件を考えます。式が評価されるときに発生するエラー状態を報告するときに明確に、利用可能なプロトコルエラーのいずれも関連していません。代わりに、DISMAN-EXPRESSION-MIBは、このようなエラー（expErrorTable）を報告するためのオブジェクトを提供します。その代わり、expErrorTableは、評価時に発生したエラーに関する情報を保持します：
expErrorEntry OBJECT-TYPE SYNTAX ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about errors in processing an expression. Entries appear in this table only when there is a matching expExpressionEntry and then only when there has been an error for that expression as reflected by the error codes defined for expErrorCode." INDEX { expExpressionOwner, expExpressionName }
式の処理におけるエラーに関するexpErrorEntry OBJECT-TYPE構文ExpErrorEntry MAX-ACCESSステータス現在の説明「情報。エントリが反映されるように、その発現のためにエラーがあった場合にのみ、その後のマッチングexpExpressionEntryがある場合にのみ、この表に表示されexpErrorCode用に定義されたエラーコードによります。」 INDEX {expExpressionOwner、expExpressionName}
More specifically, a MIB module can provide configuration applications with information about errors on the managed device by creating columnar object types in log tables that contain error information particular to errors that occur on row activation.
具体的には、MIBモジュールは、行活性化に発生するエラーに特定のエラー情報を含むログテーブル柱状オブジェクト型を作成することによって、管理対象デバイス上のエラーに関する情報を構成アプリケーションを提供することができます。
Notifications with detailed failure information objects can also be used to signal configuration failures. If this approach is used, the configuration of destinations for NOTIFICATION-TYPE data generated from configuration failures should be considered independently of the those for other NOTIFICATION-TYPEs which are generated for other operational reasons. In other words, in many management environments, the network operators interested in NOTIFICATION-TYPEs generated from configuration failures may not completely overlap with the community of network operators interested in NOTIFICATION-TYPEs generated from, for example, network interface failures.
詳細な障害情報オブジェクトと通知は、構成の失敗を通知するために使用することができます。このアプローチを使用する場合は、コンフィギュレーション障害から生成された通知タイプのデータの宛先の構成は、他の動作の理由のために生成される他のNOTIFICATION-タイプの独立したものの考慮すべきです。換言すれば、多くの管理環境では、コンフィギュレーション障害から発生NOTIFICATION-に興味ネットワークオペレータは完全に、例えば、ネットワークインタフェースの障害から発生NOTIFICATION-に興味ネットワーク事業者のコミュニティと重ならなくてもよいです。
When designing a MIB module for configuration, there are several pertinent considerations to provide support for multiple managers.
コンフィギュレーションのためのMIBモジュールを設計するとき、複数のマネージャのためのサポートを提供するには、いくつかの適切な考慮事項があります。
The first is to avoid any race conditions between two or more authorized management applications issuing SET protocol operations spanning over more than a single PDU.
最初は、単一のPDUより上に及ぶSETプロトコルオペレーションを発行する二つ以上の許可された管理アプリケーションとの間の競合状態を回避することです。
The standard textual convention document [3] defines TestAndIncr, often called a spinlock, which is used to avoid race conditions.
標準テキストの表記法ドキュメント[3] TestAndIncrが定義され、多くの場合、競合状態を避けるために使用されるスピンロックと呼ばれます。
A MIB module designer may explicitly define a synchronization object of syntax TestAndIncr or may choose to rely on snmpSetSerialNo (a global spinlock object) as defined in SNMPv2-MIB.
MIBモジュールの設計者は、明示的構文TestAndIncrの同期オブジェクトを定義することができるとSNMPv2-MIBで定義されたようsnmpSetSerialNo（グローバルスピンロックオブジェクト）に依拠することを選択することができます。
snmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating command generator applications to coordinate their use of the SNMP set operation.
snmpSetSerialNo OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS読み取りと書き込みステータス現在の説明「SNMPの使用を調整するには、いくつかの協力コマンドジェネレータアプリケーションが操作を設定できるようにするために使用諮問ロック。
This object is used for coarse-grain coordination.
To achieve fine-grain coordination, one or more similar
objects might be defined within each MIB group, as
appropriate."
::= { snmpSet 1 }
Another prominent TestAndIncr example can be found in the SNMP-TARGET- MIB [9], snmpTargetSpinLock.
別の顕著なTestAndIncrの例は、SNMP、標的 - MIB [9]、snmpTargetSpinLockに見出すことができます。
Secondly, an agent should be able to report configuration as set by different entities as distinguishable from configuration defined external to the SNMP domain, such as application of a default or through an alternate management interface like a command line interface. Section 3.10.1 describes considerations for this practice when designing NOTIFICATION-TYPEs. The OwnerString textual convention from RMON-MIB RFC 2819 [32] has been used successfully for this purpose. More recently, RFC 3411 [1] introduced the SnmpAdminString which has been designed as a UTF8 string. This is more suitable for representing names in many languages.
第二に、薬剤は、デフォルトのアプリケーションとして、またはコマンド・ライン・インターフェースのような代替的な管理インターフェースを介してSNMPドメインの外部に定義された構成と区別などの異なるエンティティによって設定された設定を報告することができなければなりません。 NOTIFICATION-型を設計する際3.10.1は、この練習のための考慮事項について説明します。 RMON-MIBのRFC 2819 [32]からOwnerStringテキストの表記法は、この目的のために首尾よく使用されてきました。さらに最近では、RFC 3411 [1]はUTF8文字列として設計されていれるSnmpAdminStringを導入しました。これは、多くの言語で名前を表現するために、より適しています。
Experience has shown that usage of OwnerString to represent row ownership can be a useful diagnostic tool as well. Specifically, the use of the string "monitor" to identify configuration set by an agent/local management has been prevalent and useful in applications.
経験は、行の所有権を表すOwnerStringの使用が同様に有用な診断ツールとなり得ることを示しています。具体的には、エージェント/ローカル管理で設定された設定を識別するための文字列「モニタ」の使用は、アプリケーションで流行と有用でした。
Thirdly, consider whether there is a need for multiple managers to configure the same set of tables. If so, an "OwnerString" may be used as the first component of a table's index to allow VACM to be used to protect access to subsets of rows, at least at the level of securityName or groupName provided. RFC 3231 [25], Section 6 presents this technique in detail. This technique does add complexity to the managed device and to the configuration management application since the manager will need to be aware of these additional columnar objects in configuration tables and act appropriately to set them. Additionally, the agent must be configured to provide the appropriate instance-level restrictions on the modifiability of the instances.
第三に、テーブルの同じセットを構成するための複数のマネージャのための必要性があるかどうかを検討します。もしそうであれば、「OwnerString」はVACM行のサブセットへのアクセスを保護するために使用できるようにテーブルのインデックスの最初の成分として使用することができる、少なくとものsecurityName又はグループ名のレベルで提供。 RFC 3231 [25]、セクション6を詳細にこの技術を提示します。管理者は、構成表にこれらの追加の柱状の物体を認識し、それらを設定するために、適切に行動する必要がありますので、この手法は、管理対象デバイスへと構成管理アプリケーションに複雑さを加えるん。また、エージェントは、インスタンスの修正可能で適切なインスタンスレベルの制限を提供するように構成されなければなりません。
The OCTET STRING syntax can be used as an extremely flexible and useful datatype when defining managed objects that allow SET operation. An octet string is capable of modeling many things and is limited in size to 65535 octets by SMIv2[2].
SET動作を可能にする管理オブジェクトを定義するときにOCTET STRINGの構文は非常に柔軟で便利なデータ型として使用することができます。オクテット文字列は、多くのものをモデル化することが可能であり、[2]のSMIv2で65535オクテットの大きさに制限されています。
Since OCTET STRINGS are very flexible, the need to make them useful to applications requires careful definition. Otherwise, applications will at most simply be able to display and set them.
オクテット文字列は非常に柔軟なので、アプリケーションにそれらを有用なものにする必要が慎重に定義する必要があります。そうでない場合、アプリケーションは、最も簡単に表示し、それらを設定することができるようになります。
Consider the following object from RFC 3418 SNMPv2-MIB [11].
RFC 3418のSNMPv2-MIB [11]から、以下の目的を考えます。
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The physical location of this node (e.g., `telephone
closet, 3rd floor'). If the location is unknown, the value
is the zero-length string."
::= { system 6 }
Such informational object types have come to be colloquially known as "scratch pad objects". While often useful, should an application be required to do more with this information than be able to read and set the value of this object, a more precise definition of the contents of the OCTET STRING is needed, since the actual format of an instance for such an object is unstructured. Hence, alternatively, dividing the object type into several object type definitions can provide the required additional structural detail.
このような情報オブジェクトタイプは、口語的に「スクラッチパッドオブジェクト」として知られるようになってきています。しばしば有用であるが、アプリケーションが読み込まれ、このオブジェクトの値を設定することができるよりも、この情報をより多くのことを行うために必要とされるべきであり、オクテット文字列の内容のより正確な定義は、インスタンスの実際の形式のため、必要とされますこのようなオブジェクトは、構造化されていません。したがって、代わりに、いくつかのオブジェクト型定義にオブジェクトタイプを分割すると、必要な追加の構造的詳細を提供することができます。
When using OCTET STRINGS, avoid platform dependent data formats. Also avoid using OCTET STRINGS where a more precise SMI syntax such as SnmpAdminString or BITS would work.
オクテット文字列を使用する場合は、プラットフォーム依存のデータ形式を避けます。また、このようれるSnmpAdminStringまたはBITSのような、より正確なSMI構文が働くだろうオクテット文字列を使用しないでください。
There are many MIB modules that attempt to optimize the amount of data sent/received in a SET/GET PDU by packing octet strings with aggregate data. For example, the PortList syntax as defined in the Q-BRIDGE-MIB (RFC 2674 [26]) is defined as follows:
集計データとオクテット文字列を充填することによりPDUをGET / SETで受信送信されるデータの量を/最適化することを試みる多くのMIBモジュールがあります。例えば、以下のようにQ-BRIDGE-MIB（RFC 2674 [26]）で定義されているポートリストの構文が定義されます。
PortList ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Each octet within this value specifies a set of eight
ports, with the first octet specifying ports 1 through
8, the second octet specifying ports 9 through 16, etc.
Within each octet, the most significant bit represents
the lowest numbered port, and the least significant bit
represents the highest numbered port. Thus, each port
of the bridge is represented by a single bit within the
value of this object. If that bit has a value of '1'
then that port is included in the set of ports; the port
is not included if its bit has a value of '0'."
SYNTAX OCTET STRING
This compact representation saves on data transfer but has some limitations. Such complex instance information is difficult to reference outside of the object or use as an index to a table. Additionally, with this approach, if a value within the aggregate requires change, the entire aggregated object instance must be written.
このコンパクトな表現は、データ転送に保存されますが、いくつかの制限があります。このような複雑なインスタンス情報は、オブジェクトの外側の参照またはテーブルへのインデックスとして使用することは困難です。集計内の値が変更を必要とする場合に加えて、このアプローチを用いて、全体の集約オブジェクト・インスタンスが書き込まれなければなりません。
Providing an SNMP table to represent aggregate data avoids the limitations of encoding data into OCTET STRINGs and is thus the better general practice.
集計データを表現するためにSNMPテーブルを提供するオクテット列に符号化データの制限を回避し、したがって、より良好な一般的です。
Finally, as previously mentioned in Section 3.3.6.3, one should consider the practical ramifications of instance transfer for object types of SYNTAX OCTET STRING where they have typical instance data requirements close to the upper boundary of SMIv2 OCTET STRING instance encoding. Where such object types are truly necessary at all, SNMP/UDP may not be a very scalable means of transfer and alternatives should be explored.
最後に、以前のセクション3.3.6.3で述べたように、人は、彼らがSMIv2のOCTET STRINGインスタンスエンコーディングの上限に近い典型的なインスタンスデータ要件を有する構文オクテットストリングのオブジェクトタイプのインスタンスの転送の実際の影響を考慮すべきです。そのようなオブジェクトタイプがすべてで真に必要な場合には、SNMP / UDPは、転送の非常にスケーラブルな手段ではないかもしれないと選択肢が検討されるべきです。
When defining new MIB modules, one should consider if there could ever be multiple instances of this MIB module in a single SNMP entity.
新しいMIBモジュールを定義する場合、これまで単一のSNMPエンティティでこのMIBモジュールの複数のインスタンスがあることができれば、人は検討すべきです。
MIB modules exist that assume a one to many relationship, such as MIBs for routing protocols which can accommodate multiple "processes" of the underlying protocol and its administrative framework. However, the majority of MIB modules assume a one-to-one relationship between the objects found in the MIB module and how many instances will exist on a given SNMP agent. The OSPF-MIB, IP-MIB, BRIDGE-MIB are all examples that are defined for a single instance of the technology.
MIBモジュールは、基礎となるプロトコルおよびその管理フレームワークの複数の「プロセス」を収容することができるプロトコルをルーティングするためのMIBとして、それは多くの関係に1を想定存在します。しかし、MIBモジュールの大部分は、MIBモジュールにあるオブジェクトとどのように多くのインスタンスとの間の1対1の関係が所定のSNMPエージェントに存在すると仮定する。 OSPF-MIB、IP-MIB、BRIDGE-MIBは、技術の単一のインスタンスのために定義されているすべての例です。
It is clear that single instancing of these MIB modules limits implementations that might support multiple instances of OSPF, IP stacks or logical bridges.
これらのMIBモジュールの単一インスタンス化は、OSPF、IPスタックまたは論理ブリッジの複数のインスタンスをサポートする可能性がある実装を制限することは明らかです。
In such cases, the ENTITY-MIB [RFC2737] can provide a means for supporting the one-to-many relationship through naming scopes using the entLogicalTable. Keep in mind, however, that there are some drawbacks to this approach.
このような場合には、ENTITY-MIB [RFC2737]はentLogicalTableを使用して命名スコープを介して1対多の関係をサポートするための手段を提供することができます。このアプローチにはいくつかの欠点があること、しかし、覚えておいてください。
1) One cannot issue a PDU request that spans naming scopes. For example, given two instances of BRIDGE-MIB active in a single agent, one PDU cannot contain a request for dot1dBaseNumPorts from both the first and second instances.
1）一つは、スコープを命名またがるPDU要求を発行することはできません。例えば、単剤で活性BRIDGE-MIBの2つのインスタンスを与え、あるPDUは、第1および第2の両方のインスタンスからdot1dBaseNumPorts要求を含めることはできません。
2) Reliance on this technique creates a dependency on the Entity MIB for an application to be able to access multiple instances of information.
2）この技術への依存は、情報の複数のインスタンスにアクセスできるようにするアプリケーションのためのエンティティMIBの依存関係を作成します。
Alternately, completely independently of the Entity MIB, multiple MIB module instances can be scoped by different SNMP contexts. This does, however, require the coordination of this technique with the administrative establishment of contexts in the configured agent system.
代わりに、完全に独立してエンティティMIBの、複数のMIBモジュールインスタンスは異なるSNMPコンテキストによってスコープすることができます。これは、しかし、構成されたエージェントシステムにおけるコンテキストの行政の確立と、この技術の調整を必要としません。
When defining integer-based objects for read-create, read-write and read-only semantics, using the UNITS clause is recommended in addition to specification in the DESCRIPTION clause of any particular details of how UNITs are to be interpreted.
リード作成、書き込みを読み取り、読み取り専用セマンティクスに対する整数ベースのオブジェクトを定義する場合、単位句を使用すると、ユニットが解釈される方法のいずれかの特定の詳細の記述節の指定に加えて、推奨されます。
The REFERENCE clause is also recommended as a way to help an implementer track down related information on a given object. By adding a REFERENCE clause to the specific underlying technology document, multiple separate implementations will be more likely to interoperate.
REFERENCE句は、指定されたオブジェクトの関連情報を追跡実装を支援するための方法として推奨されています。特定の基礎となる技術文書にREFERENCE句を追加することにより、複数の独立した実装が相互運用する可能性が高くなります。
Successful deployment of SNMP configuration systems depends on understanding the roles of MIB module design and agent design.
SNMP設定システムの展開を成功には、MIBモジュールの設計とエージェントの設計の役割を理解することに依存します。
Both module and agent design need to be undertaken with an understanding of how UDP/IP-based SNMP behaves. A current practice in MIB design is to consider the idempotency of settable objects. Idempotency basically means being able to invoke the same set operation repeatedly but resulting in only a single activation.
モジュールおよびエージェントの設計の両方がUDP / IPベースのSNMPがどのように動作するかを理解した上で着手する必要があります。 MIBの設計における現在の慣行は、設定可能なオブジェクトの冪等を考慮することです。冪等は、基本的に繰り返し、同じセットのオペレーションを呼び出すことができることが、唯一の活性化をもたらすことを意味します。
Here is an example of the idempotency in action:
ここでアクションで冪等の例です。
Manager Agent
-------- ------
Set1 (Object A, Value B) ---> receives set OK and responds
X<-------- Response PDU(OK) is dropped by
network
Manager times out
and sends again
Set2 (Object A, Value B) ---> receives set OK (does nothing),
responds
<-------- with a Response PDU(OK)
Manager receives OK
Had object A been defined in a stateful way, the set operation might have caused the Set2 operation to fail as a result of interaction with Set1. If the agent implementation is not aware of such a possible situation on the second request, the agent may behave poorly by performing the set request again rather than doing nothing.
オブジェクトステートフルな方法で定義されていた、集合演算は、SET2操作がセット1との相互作用の結果として失敗する原因となった可能性があります。エージェント実装は、2番目の要求のような可能な状況を認識していない場合、エージェントは再びセット要求を実行するのではなく何もしないことにより、不十分な動作をする場合があります。
The example above shows that all of the software that runs on a managed element and in managed applications should be designed in concert when possible. Particular emphasis should be placed at the logical boundaries of the management system components in order to ensure correct operation.
上記の例では、可能な場合は管理対象要素にして管理するアプリケーションで動作するソフトウェアのすべてのコンサートに設計されるべきであることを示しています。特に重要なのは、正しい動作を保証するために、管理システムコンポーネントの論理的境界に配置されるべきです。
1. The first interface is between SNMP agents in managed devices and the management applications themselves. The MIB document is a contract between these two entities that defines expected behavior - it is a type of API.
1.最初のインターフェイスは、管理対象デバイスでSNMPエージェントと管理アプリケーション自体の間です。 MIBの文書は、予想される動作を定義し、これら2つのエンティティ間の契約である - それはAPIの種類です。
2. The second interface is between the agent and the instrumented subsystem. In some cases, the instrumented subsystem will require modification to allow for the dynamic nature of SNMP-based configuration, control and monitoring operations. Agent implementors must also be sensitive to the operational code and device in order to minimize the impact of management on the primary subsystems.
2.第2のインターフェースは、エージェントと計装サブシステムの間です。いくつかのケースでは、インストルメントサブシステムは、SNMPベースの設定、制御および監視業務の動的な性質を可能にするために修正が必要になります。エージェントの実装はまた、一次サブシステムの管理の影響を最小限に抑えるために、オペレーショナルコードおよびデバイスに敏感でなければなりません。
Additionally, while the SNMP protocol-level and MIB module-level modeling of configuration operations may be idempotent and stateless from one set operation to another, it may not be that way in the underlying subsystem. It is possible that an agent may need to manage this state in these subsystem architectures explicitly when it has placed the underlying subsystem into an "intermediate" state at a point in processing a series of SET PDUs. Alternatively, depending on the underlying subsystem in question, the agent may be able to buffer all of the configuration set operations prior to activating them in the subsystem all at once (to accommodate the nature of the subsystem).
また、SNMPプロトコルレベルつつ、構成操作のMIBモジュールレベルのモデリングは、一組の動作から別の冪等とステートレスすることができる、それは、基礎となるサブシステムにそのようではないかもしれません。 SET PDUの系列を処理中の時点で「中間」状態に根本的なサブシステムを置いたときに、エージェントが明示的にこれらのサブシステムのアーキテクチャで、この状態を管理する必要があることも可能です。また、問題の根本的なサブシステムに応じて、エージェントは、（サブシステムの性質に対応するために）一度にすべてのサブシステムでそれらを活性化する前に、構成設定操作のすべてをバッファリングすることができるかもしれません。
As an example, it would be reasonable to define a MIB module to control Virtual Private Network (VPN) forwarding, in which a management station could set a set of ingress/egress IP addresses for the VPN gateway. Perhaps the MIB module presumes that the level of transactionality is the establishment of a single row in a table defining the address of the ingress/egress gateway, along with some prefix information to assist in routing at the VPN layer to that gateway. However, it would be conceivable that in an underlying Layer 2 VPN subsystem instrumentation, the requirement is that all existing gateways for a VPN be deleted before a new one can be defined--that, in other words, in order to add a new gateway, g(n), to a VPN, gateways g(1)..g(n-1) need to be removed, and then all n gateways reestablished with the VPN forwarding service. In this case, one could imagine an agent which has some sort of timer to establish a bounded window for receipt of SETs for new VPN gateways, and to activate them in this removal-then-reestablishment of existing and new gateways at the end of this window.
一例として、管理ステーションは、VPNゲートウェイの入口/出口IPアドレスの組を設定することができた仮想プライベートネットワーク（VPN）の転送を制御するためのMIBモジュールを定義することが合理的であろう。おそらくMIBモジュールは、トランザクション性のレベルがそのゲートウェイにVPN層でルーティングを補助するためにいくつかのプレフィックス情報と共に、入口/出口ゲートウェイのアドレスを定義するテーブル内の単一の行の確立であることを前提。新しいゲートウェイを追加するために、他の言葉で、それを - しかし、基本的なレイヤ2 VPNサブシステムの計装で、要件は、新しいものを定義することができます前に、VPNのためのすべての既存のゲートウェイが削除されるということであるとも考えられます、G（n）は、VPNに、G（1）.. G（N-1）ゲートウェイ除去する必要があり、その後、すべてのn個のゲートウェイは、VPN転送サービスを再確立。この場合、1は、新しいVPNゲートウェイのセットの受信のための有界ウィンドウを確立するために、タイマーのいくつかの並べ替えを持っているエージェントを想像し、このの終わりに既存および新規のゲートウェイのこの除去-、その後、再確立でそれらを有効にします窓。
Devices are often modified by multiple management entities and with different management techniques. It is sometimes the case that an element is managed by different organizations such as when a device sits between administrative domains.
デバイスは、多くの場合、複数の管理エンティティによって、異なる管理技術で修飾されています。それは時々要素は、そのようなデバイスは、管理ドメインの間に位置するときのように、異なる組織によって管理されている場合です。
There are a variety of approaches that management software can use to ensure synchronization of information between the manager(s) and the managed elements.
管理ソフトウェアは、管理者（複数可）と管理対象要素間の情報の同期を確実にするために使用することができ、さまざまなアプローチがあります。
An agent should report configuration changes performed by different entities. It should also distinguish configuration defined locally such as a default or locally specified configuration made through an alternate management interface such as a command line interface. When a change has been made to the system via SNMP, CLI, or other method, a managed element should send an notification to the manager(s) configured as recipients of these applicable notifications. These management applications should update their local configuration repositories and then take whatever additional action is appropriate. This approach can also be an early warning of undesired configuration changes.
エージェントは、異なるエンティティによって実行される構成変更を報告する必要があります。それはまた、デフォルトまたはそのようなコマンド・ライン・インターフェースなどの代替管理インタフェースを介して行わローカルに指定された構成のように局所的に定義された構成を区別すべきです。変化はSNMP、CLI、または他の方法を介してシステムに加えられたときに、管理対象要素は、これらの適用の通知の受信者として構成マネージャ（複数可）に通知を送信すべきです。これらの管理アプリケーションはローカルの構成リポジトリを更新してから、追加のアクションが適切であるものは何でも取る必要があります。このアプローチは、望ましくない構成の変更を早期に警告することができます。
Managers should also develop mechanisms to ensure that they are synchronized with each other.
管理者はまた、それらが互いに同期していることを確実にするためのメカニズムを開発する必要があります。
Once a RowStatus value is active(1) for a given row, the management application should be able to determine what the semantics are for making additional changes to a row. The RMON MIB control table objects spell out explicitly what managed objects in a row can and cannot be changed once a given RowStatus goes active.
RowStatusの値が所定の行について（1）アクティブになると、管理アプリケーションは、セマンティクスが行に追加の変更を行うためのものであるかを決定することができなければなりません。 RMON MIB制御テーブルオブジェクトは列内のオブジェクトは、一度与えられたのRowStatusがアクティブになっ変更することはできませんができ、管理明示的に何を綴ります。
As described earlier, some operations take some time to complete. Some systems also require that they remain in a particular state for some period before moving to another. In some cases, a change to one value may require re-initialization of the system. In all of these cases, the DESCRIPTION clause should contain information about requirements of the managed system and special restrictions that managers should observe.
前述したように、いくつかの操作が完了するまでに多少時間がかかります。いくつかのシステムはまた、彼らは別のに移動する前に、いくつかの期間、特定の状態のままにする必要があります。いくつかのケースでは、1つの値に変化は、システムの再初期化を必要とするかもしれません。これらすべての場合には、DESCRIPTION句は、管理対象システムの要件と管理者が遵守すべき特別の制限に関する情報が含まれている必要があります。
The second version of the SNMP SMI dropped direct support for a write-only object. It is therefore necessary to return something when reading an object that you may have wished to have write-only semantics. Such objects should have a DESCRIPTION clause that details what the return values should be. However, regardless of the approach, the value returned when reading the object instance should be meaningful in the context of the object's semantics.
SNMP SMIの第二のバージョンは、書き込み専用のオブジェクトを直接サポートを落としました。あなたが書き込み専用のセマンティクスを持つことを望んだたかもしれないオブジェクトを読み込むときに何かを返すことが必要です。このようなオブジェクトは、戻り値がどうあるべきかの詳細説明節を持っている必要があります。しかし、関係なく、アプローチの、オブジェクトのインスタンスを読み込むときに返される値は、オブジェクトの意味論の文脈の中で意味のあるべき。
In this section, we describe practices that should be used when creating and deploying management software that configures one or more systems using SNMP. Functions all configuration management software should provide, regardless of the method used to convey configuration information to the managed systems are backup, fail-over, and restoration. A management system should have the following features:
このセクションでは、SNMPを使用して、1つまたは複数のシステムを設定する管理ソフトウェアを作成して展開する際に使用されるべきプラクティスについて説明します。すべての構成管理ソフトウェアを提供するべき機能は、関係なく、管理対象システムに設定情報を伝えるために使用される方法のフェイルオーバー、および復元を、バックアップされています。管理システムは、次のような特徴を持っている必要があります。
1. A method for restoring a previous configuration to one or more devices. Ideally this restoration should be time indexed so that a network can be restored to a configured state as of a specific time and date.
1.一台の以上のデバイスに以前の設定を復元する方法。ネットワークは、特定の時刻と日付のように構成された状態に戻すことができるように、理想的には、この回復は、時間インデックスを付けなければなりません。
2. A method for saving back up versions of the configuration data in case of hardware or software failure.
2.ハードウェアまたはソフトウェアの障害が発生した場合の構成データのバージョンをバックアップ保存するための方法。
3. A method of providing fail-over to a secondary (management) system in case of a primary failure. This capability should be deployed in such a way that it does not cause duplicate polling of configuration.
3.フェイルオーバ二次（管理）システムに一次障害が発生した場合に提供する方法。この機能は設定の重複ポーリングを起こさないように展開する必要があります。
These three capabilities are of course important for other types of management that are not the focus of this BCP.
これら三つの機能はもちろん、このBCPの焦点ではありません管理の他のタイプのために重要です。
From the point of view of the design of the management application, there are three basic requirements to evaluate relevant to SNMP protocol operations and configuration:
管理アプリケーションの設計の観点からは、SNMPプロトコル操作や設定に関連する評価するための3つの基本的な要件があります。
o Set and configuration activation operations
O設定し、設定起動操作
o Notifications from the device
デバイスからの通知O
o Data retrieval and collection
Oデータの検索および収集
Depending on the requirements of the specific services being configured, many other requirements may, and probably will, also be present.
設定されている特定のサービスの要件に応じて、他の多くの要件は、おそらく、また存在することがあります。
The design of the system should not assume that the objects in a device that represent configuration data will remain unchanged over time.
システムの設計には、コンフィギュレーション・データを表すデバイス内のオブジェクトは、時間をかけて変わらないと仮定してはいけません。
As standard MIB modules evolve and vendors add private extensions, the specific configuration parameters for a given operation are likely to change over time. Even in the case of a configuration application that is designed for a single vendor, the management application should allow for variability in the MIB objects that will be used to configure the device for a particular purpose. The best method to accomplish this is by separating, as much as possible, the operational semantics of a configuration operation from the actual data. One way that some applications achieve this is by having the specific configuration objects that are associated with a particular device be table driven rather than hard coded. Ideally, management software should verify the support in the devices it is expected to manage and report any unexpected deviations to the operator. This approach is particularly valuable when developing applications that are intended to support equipment or software from multiple vendors.
標準MIBモジュールが進化し、ベンダーがプライベート拡張を追加すると、特定の操作のための具体的な設定パラメータが時間とともに変化する可能性があります。単一のベンダーのために設計され、構成アプリケーションの場合には、管理アプリケーションは、特定の目的のためにデバイスを構成するために使用されるMIBオブジェクトの変動を可能にすべきです。これを実現する最良の方法は、可能な限り、実際のデータから構成操作の操作的意味論を分離することです。いくつかのアプリケーションは、これを達成する1つの方法は、特定のデバイステーブルを駆動ではなく、ハードコード化することと関連している特定の構成オブジェクトを有することです。理想的には、管理ソフトウェアは、管理し、オペレータに予想外の逸脱を報告することが期待されているデバイスでのサポートを確認する必要があります。複数のベンダーからの機器やソフトウェアをサポートすることを意図しているアプリケーションを開発する場合、このアプローチは、特に価値があります。
Management software should be mindful of the environment in which SET operations are being deployed. The intent here is to move configuration information as efficiently as possible to the managed device. There are many ways to achieve efficiency and some are specific to given devices. One general case that all management software should employ is to reduce the number of SET PDU exchanges between the managed device and the management software to the smallest reasonable number. One approach to this is to verify the largest number of variable bindings that can fit into a SET PDU for a managed device. In some cases, the number of variable bindings to be sent in a particular PDU will be influenced by the device, the specific MIB objects and other factors.
管理ソフトウェアは、SET操作が展開されている環境に留意する必要があります。ここでの意図は、管理対象デバイスに可能な限り効率的に設定情報を移動することです。そこ効率を達成するための多くの方法があり、一部は特定のデバイスに固有のものです。すべての管理ソフトウェアが採用すべき一つの一般的な場合は、管理対象デバイスと最小の合理的な数の管理ソフトウェアとの間の設定されたPDU交換の数を減らすことです。これに対する1つのアプローチは、管理対象デバイスのためのSET PDUに収まることができる変数バインディングの最大数を確認することです。いくつかのケースでは、変数バインディングの数は、デバイス、特定のMIBオブジェクトおよび他の要因によって影響されるであろう特定のPDUで送信されます。
Maximizing the number of variable bindings in a SET PDU also has benefits in the area of management application transaction initiation, as we will discuss in the following section.
我々は次のセクションで議論するようSET PDU内の変数バインディングの数を最大化することも、管理アプリケーションのトランザクション開始の領域で利点があります。
There are, though, agents that may have implementation limitations on the number and order of varbinds they can handle in a single SET PDU. In this case, sending fewer varbinds will be necessary.
彼らは、単一のSET PDUに扱うことができるのvarbindの数と順序に実装上の制限を有することができる薬剤は、しかし、があります。この場合、少数の変数バインディングを送信する必要があります。
As stated at the outset of this section, the management application software designer must be sensitive to the design of the SNMP software in the managed device. For example, the software in the managed device may require that all that all related configuration information for an operation be conveyed in a single PDU because it has no concept of a transaction beyond a single SNMP PDU. Another example has to do with the RowStatus textual convention. Some SNMP agents implement a subset of the features available and as such the management application must avoid using features that may not be supported in a specific table implementation (such as createAndWait).
このセクションの冒頭で述べたように、管理アプリケーションソフトウェアの設計者は、管理対象デバイスでSNMPソフトウェアの設計に敏感でなければなりません。たとえば、管理対象デバイスでのソフトウェアは、単一のSNMP PDUを越えた取引の概念がないため、すべての操作に関連するすべての構成情報を単一のPDUで搬送することが必要な場合があります。別の例は、RowStatusテキストの表記法に関係しています。一部のSNMPエージェントは、利用可能な機能のサブセットを実装し、そのような管理アプリケーションとして（例えばcreateAndWaitにのような）特定のテーブルの実装ではサポートされなくてもよい機能を使用しないようにしなければなりません。
There are several types of configuration transactions that can be supported by SNMP-based configuration applications. They include transactions on a scalar object, transactions in a single table (within and across row instances), transactions across several tables in a managed device and transactions across many devices. The manager's ability to support these different transactions is partly dependent on the design of the MIB objects used in the configuration operation.
SNMPベースの設定アプリケーションでサポートすることができ、構成取引のいくつかの種類があります。彼らは、スカラーオブジェクト上のトランザクション、（行インスタンス内および両端の）単一のテーブル内のトランザクション、多くのデバイス間で管理対象デバイスとのトランザクションに複数のテーブルを横切ってトランザクションを含みます。これらの異なるトランザクションをサポートする管理者の能力は、設定操作で使用されるMIBオブジェクトの設計に部分的に依存しています。
To make use of any kind of transaction semantics effectively, SNMP management software must be aware of the information in the MIB modules that it is to configure so that it can effectively utilize
効果的にトランザクションセマンティクスのいずれかの種類を使用するには、SNMP管理ソフトウェアは、それが効果的に活用できるように構成することであるMIBモジュール内の情報に注意する必要があります
RowStatus objects for the control of transactions on one or more tables. Such software must also be aware of control tables that the device supports that are used to control the status of one or more other tables.
RowStatusのは、1つまたは複数のテーブル上のトランザクションの制御のためのオブジェクト。このようなソフトウェアはまた、1つまたは複数の他のテーブルの状態を制御するために使用されているデバイスがサポートする制御テーブルを認識する必要があります。
To the greatest extent possible, the management application should provide the facility to support transactions across multiple devices. This means that if a configuration operation is desired across multiple devices, the manager can coordinate these configuration operations such that they become active as close to simultaneously as possible.
可能な限り、管理アプリケーションは、複数のデバイス間でトランザクションをサポートする機能を提供する必要があります。これは、設定動作は、複数のデバイス間で所望される場合、管理者は、彼らが可能な限り同時に近くにアクティブになるように、これらの構成の動作を調整することができることを意味します。
Several practical means are present in the SNMP model that support management application level transactions. One was mentioned in the preceding section, that transactions can be optimized by including the maximum number of SET variable bindings possible in a single PDU sent to the agent.
いくつかの実用的な手段は、管理アプリケーションレベルのトランザクションをサポートするSNMPモデルに存在しています。一つは、トランザクションがエージェントに送信される単一のPDUで可能SET変数バインディングの最大数を含むことによって最適化することができることは、前のセクションで述べました。
There is an important refinement to this. The set of read-create row data objects for tables should be sent in a single PDU, and only placed across multiple PDUs if absolutely necessary. The success of these set operations should be verified through the response(s) to the Set PDU or subsequent polling of the row data objects. The applicable RowStatus object(s), may be set to active only after this verification. This is the only tractable means of affording an opportunity for per-row rollback, particularly when the configuration change is across table row instances on multiple managed devices.
これに重要な改良があります。テーブルのリード作成行データオブジェクトのセットは、単一のPDUで送信され、絶対に必要な場合のみ、複数のPDUを横切って配置されるべきです。これらのセットの操作の成功は、Set PDU又は行データ・オブジェクトの後続のポーリングに応答して（複数可）を介して検証されなければなりません。適用RowStatusオブジェクト（複数可）は、唯一のこの検証後にアクティブに設定されてもよいです。これは、構成の変更は、複数の管理対象デバイス上の表の行インスタンス間である場合は特に、毎行のロールバックのための機会を与える唯一の扱いやすい手段です。
Finally, where a MIB module exposes the kind of helpful transaction management object types that were discussed in Section 3.3.5, it is clearly beneficial to the integrity of the management application's capacity to handle transactions to make use of them.
MIBモジュールは、3.3.5項で説明した便利トランザクション管理オブジェクトタイプの種類を公開する場所を最後に、それらを利用するために、トランザクションを処理するために、管理アプリケーションの容量の整合性に明らかに有益です。
As previously described in Section 3.3.5 (Summary Objects and State Tracking), agents should provide the capability for notifications to be sent to their configured management systems whenever a configuration operation is completed or is detected to have failed. The management application must be prepared to accept these notifications so that it knows the current configured state of the devices under its control. Upon receipt of the notification, the management application should use getBulk or getNext to retrieve the configuration from the agent and store the relevant contents in the management application database. The GetBulkRequest-PDU is useful for this whenever supported by the managed device, since it is more efficient than the GetNextRequest-PDU when retrieving large amounts of data. For the purposes of backward compatibility, the management station should also support and make use of the GetNextRequest-PDU when the agent does not support the GetBulkRequest-PDU.
以前のセクション3.3.5（概要オブジェクトおよび状態追跡）に記載されているように、薬剤は、コンフィギュレーション動作が完了するか、失敗したことが検出されるたびに、それらの構成管理システムに送信される通知のための能力を提供すべきです。管理アプリケーションは、それは、その制御下にあるデバイスの現在の構成された状態を知っているように、これらの通知を受け入れる準備する必要があります。通知を受信すると、管理アプリケーションは、エージェントから構成を取得し、管理アプリケーションのデータベースに関連した内容を保存するためにGETBULKまたはgetNextをを使用する必要があります。大量のデータを取得するとき、それはGetNextRequest-PDUよりも効率的であるため、管理対象デバイスでサポートされている時はいつでもGetBulkRequest-PDUは、この場合に便利です。下位互換性の目的のために、管理ステーションもサポートし、エージェントがGetBulkRequest-PDUをサポートしていないときGetNextRequest-PDUを利用する必要があります。
Management systems should also provide configuration options with defaults for users that tend to retrieve the smallest amount of data to achieve the particular goal of the application, to avoid unnecessary load on managed devices for the most common retrieval operations.
管理システムはまた、最も一般的な検索操作のための管理対象デバイス上の不要な負荷を避けるために、アプリケーションの特定の目標を達成するための最小量のデータを取得する傾向があるユーザーのためにデフォルトで設定オプションを提供する必要があります。
The techniques for efficient data retrieval described in the preceding sections comprise only one aspect of what application developers should consider in this regard when developing configuration applications. Management applications should provide for distributed processing of the configuration operations. This also extends to management functions that are not the focus of this document. Techniques of distributed processing can also be used to provide resilience in the case of network failures. An SNMP-based configuration management system might be deployed in a distributed fashion where three systems in different locations keep each other synchronized. This synchronization can be accomplished without additional polling of network devices through a variety of techniques. In the case of a failure, a 'backup' system can take over the configuration responsibilities from the failed manager without having to re-synchronize with the managed elements since it will already be up to date.
前のセクションで説明した効率的なデータ検索のための技術は、構成アプリケーションを開発する場合、アプリケーション開発者は、この点で考慮すべきかの一側面を含みます。管理アプリケーションは、設定操作の分散処理のために提供する必要があります。また、これは、このドキュメントの焦点ではありません管理機能を拡張します。分散処理の技術は、ネットワーク障害の場合に復元力を提供するために使用することができます。 SNMPベースの構成管理システムは、異なる場所に3つのシステムが同期して相互に保つ分散方式で展開されるかもしれません。この同期は、種々の技術を介してネットワークデバイスの追加のポーリングなしに達成することができます。障害が発生した場合には、「バックアップ」システムは、それがすでに最新のものになるので、管理対象要素に再同期することなく、失敗した管理者からの構成の責任を引き継ぐことができます。
Now that we have considered the design of SNMP MIB data for configuration, agent implementation of its access, and management application issues in configuration using SNMP, we turn to a variety of operational considerations which transcend all three areas.
今、私たちは、SNMPを使用した構成での構成、そのアクセスのエージェントの実装、および管理アプリケーションの問題のためのSNMP MIBデータの設計を検討していることを、我々は3つの領域すべてを超越運用検討事項の様々な向けます。
The following basic assumptions are made about real world configuration models.
以下の基本的な仮定が現実の世界設定モデルについて作られています。
1) Operations must understand and must be trained in the operation of a given technology. No configuration system can prevent an untrained operator from causing outages due to misconfiguration.
1）操作は理解しなければならないと与えられた技術の動作の訓練を受けなければなりません。いいえ構成システムは、設定ミスに起因する障害を引き起こすことから、訓練を受けていないオペレータのを防ぐことができません。
2) Systems undergoing configuration changes must be able to cope with unexpected loss of communication at any time.
2）システム受ける構成の変更はいつでも通信の予想外の損失に対処できなければなりません。
During configuration operations, network elements must take appropriate measures to leave the configuration in a consistent/recognizable state by either rolling back to a previously valid state or changing to a well-defined or default state.
設定操作時には、ネットワーク要素のいずれかが以前に有効な状態にロールバックするか、明確に定義された、またはデフォルトの状態に変更することにより、一貫性のある/認識可能な状態での構成を残すための適切な措置を講じなければなりません。
3) Configuration exists on a scale from relatively unchanging to a high volume, high rate of change. The former is often referred to as "set and forget" to indicate that the configuration changes quite infrequently. The latter, "near real-time change control" implies a high frequency of configuration change. Design of configuration management must take into account the rate and volume of change expected in a given configuration subsystem.
3）の構成は、大量、変化率に比較的不変のスケール上に存在します。前者はしばしば非常にまれにしか構成変更ことを示すために、「設定と忘れる」と呼ばれています。後者は、「リアルタイム変更制御近く」構成変更の高周波を意味しています。構成管理の設計を考慮に与えられた構成サブシステムに期待される変化の速度や音量を取る必要があります。
Vendors should not ship a device with a community string 'public' or 'private', and agents should not define default community strings except when needed to bootstrap devices that do not have secondary management interfaces. Defaults lead to security issues that have been recognized and exploited. When using SNMPv1, supporting read-only community strings is a common practice.
ベンダーは、コミュニティ文字列「公共」または「プライベート」でデバイスを出荷してはならない、とエージェントは、セカンダリ管理インターフェースを持っていないデバイスをブートストラップするために必要な場合を除き、デフォルトのコミュニティストリングを定義するべきではありません。デフォルトでは認識され、利用されてきたセキュリティ上の問題につながります。 SNMPv1のを使用する場合は、読み取り専用コミュニティストリングをサポートすることは一般的です。
Version 3 of the SNMP represents the current standard for the Internet Management Framework and is recommended for all network management applications. In particular, SNMPv3 provides authorization, authentication, and confidentiality protection and is essential to meeting the security considerations for all management of devices that support SNMP-based configuration.
SNMPのバージョン3は、インターネット管理フレームワークのための現在の標準を表し、すべてのネットワーク管理アプリケーションのために推奨されます。特に、SNMPv3は、認可、認証、および機密保護を提供し、SNMPベースの設定をサポートするデバイスのすべての管理のためのセキュリティの考慮事項を満たすために不可欠です。
The default state of RFC 1215 [17] Authentication notifications should be off. One does not want to risk accidentally sending out authentication failure information, which by itself could constitute a security liability. Enabling authentication Notifications should be done in the context of a management security scheme which considers the proper recipients of this information.
RFC 1215のデフォルトの状態では、[17]認証通知はオフにする必要があります。一つは、それ自体で、セキュリティの責任を構成する可能性が認証失敗情報を、送出誤って危険にさらしたくありません。認証通知を有効にすることは、この情報の適切な受信者を考慮した管理セキュリティ方式のコンテキストで実行する必要があります。
There are other liabilities where authentication notifications are generated without proper security infrastructure. When notifications are sent in SNMPv1 trap PDUs, unsolicited packets to a device can causes one or more trap PDUs to be created and sent to management stations. If these traps flow on shared access media and links, the community string from the trap may be gleaned and exploited to gain access to the device. At the very least, this risk should be mitigated by having the authentication trap PDU be conveyed with a community string which is only used for authentication traps from the agent, and would be useless for access inbound to the agent to get at other management data.
認証通知が適切なセキュリティインフラストラクチャなしで生成されたその他の負債があります。通知はSNMPv1トラップのPDUに送信されると、デバイスへの未承諾のパケットは、一の以上のトラップPDUを作成して管理ステーションに送信されますすることができます。これらのトラップは、共有アクセスメディアとリンク上を流れている場合、トラップからのコミュニティ文字列は、収集し、デバイスへのアクセスを得るために利用することができます。少なくとも、このリスクは、エージェントからの認証トラップのために使用されているコミュニティ文字列で搬送され、認証トラップPDUを持つことによって緩和されるべき、およびその他の管理データを取得するためにエージェントにアクセスインバウンドのための役に立たないだろう。
A further liability of authentication traps can be seen when they are being generated in the face of a Denial Of Service (DOS) attack, in the form of a flood of PDUs with invalid community strings, on the agent system. If it is bad enough that the system is having to respond to and recover from the invalid agent data accesses, but the problem will be compounded if a separate Authentication notification PDU is sent to each recipient on the management network.
彼らはサービス拒否（DoS）攻撃の顔に生成されているときに、認証トラップの更なる債務は、エージェントシステム上で、無効なコミュニティストリングとPDUの洪水の形で、見ることができます。それは、システムが応答してデータアクセスを無効エージェントから回復するために持っていることを十分に悪いですが、別の認証通知PDUは、管理ネットワーク上の各受信者に送信された場合、問題が配合されます。
Some MIB modules contain objects that may contain data for keys, passwords and other such sensitive information and hence must be protected from unauthorized access. MIB documents that are created in the IETF must have a 'Security Considerations' section, which details how sensitive information should be protected. Similarly, MIB module designers who create MIB documents for private MIB objects should include similar information so that users of the products containing these objects can take appropriate precautions.
一部のMIBモジュールには、キー、パスワードおよび他のそのような機密情報のためのデータが含まれる可能性があり、したがって、不正アクセスから保護されなければならないオブジェクトが含まれています。 IETFで作成されたMIBドキュメントは保護されなければならないか、機密情報の詳細「のセキュリティの考慮事項」のセクションを持っている必要があります。これらのオブジェクトを含む製品のユーザーは、適切な予防措置をとることができるように、同様に、プライベートMIBオブジェクトのためのMIBの文書を作成するMIBモジュールの設計者は、同様の情報を含める必要があります。
Even if a device does support DES, it should be noted that configuration of keys for other protocols via SNMP Sets protected by DES should not be allowed if the other keys are longer than the 56 bit DES keys protecting the SNMP transmission.
デバイスは、DESをサポートしない場合でも、他のキーは、SNMP通信を保護する56ビットDESキーよりも長い場合にDESによって保護SNMPセットを介して他のプロトコルのためのキーの設定が許可されるべきではないことに留意すべきです。
The DESCRIPTION clause for these object types and their Security Considerations sections in the documents which define them should make it clear how and why these specific objects are sensitive and that a user should only make them accessible for encrypted SNMP access. Vendors should also document sensitive objects in a similar fashion.
それらを定義文書でこれらのオブジェクトの種類とそのセキュリティに関する考慮事項セクションの説明節は明確でどのように、なぜこれらの特定のオブジェクトが敏感であり、ユーザーが唯一の暗号化されたSNMPアクセスのためにそれらにアクセスできるようにする必要があることを確認しなければなりません。ベンダーも同様の方法で機密オブジェクトをドキュメント化する必要があります。
Confidentiality is not a mandatory portion of the SNMPv3 management framework [6].
機密性は、[6]のSNMPv3管理フレームワークの必須部分ではありません。
Prior to SNMPv3, providing customized views of MIB module data was difficult. This led to objects being defined such as the following from [41].
前のSNMPv3に、MIBモジュールデータのカスタマイズされたビューを提供することは困難でした。これは、オブジェクトがそのような[41]から以下のように定義されることにつながりました。
docsDevNmAccessEntry OBJECT-TYPE
SYNTAX DocsDevNmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing access to SNMP objects by a
particular network management station. An entry in
this table is not readable unless the management station
has read-write permission (either implicit if the table
is empty, or explicit through an entry in this table.
Entries are ordered by docsDevNmAccessIndex. The first
matching entry (e.g., matching IP address and community
string) is used to derive access."
INDEX { docsDevNmAccessIndex }
::= { docsDevNmAccessTable 1 }
New MIB modules should capitalize on existing security capabilities of SNMPv3 Framework. One way they can do this is by indicating the level of security appropriate to different object types. For example, objects that change the configuration of the system might be protected by using the authentication mechanisms in SNMPv3. Specifically, it is useful to design MIB module object grouping with considerations for VACM views definition, such that users can define and properly scope what tables are visible to a given user and view.
新しいMIBモジュールは、SNMPv3のフレームワークの既存のセキュリティ機能を活用すべきです。彼らはこれを行うことができます一つの方法は、異なるオブジェクトタイプにセキュリティの適切なレベルを示すことです。例えば、システムの設定を変更するオブジェクトがSNMPv3が認証メカニズムを使用して保護されるかもしれません。具体的には、テーブルは、所与のユーザとビューに表示されているどのようなユーザーが正しくスコープを定義することができるようにVACMビュー定義の考慮事項とグルーピングMIBモジュールオブジェクトを設計するのに有用です。
In some designs and implementations, a common practice used to move large amounts of data involves using SNMP as a control channel in combination with other protocols defined for transporting bulk data. This approach is sub-optimal since it raises a number of security and other concerns. Transferring large amounts of configuration data via SNMP can be efficiently performed with several of the techniques described earlier in this document. This policy section shows how even greater efficiency can be achieved using a set of relatively new design mechanisms. This section gives background and defines terms that are relevant to this field and describes some deployment approaches.
いくつかの設計と実装では、大量のデータを移動させるために使用される一般的な方法は、バルクデータを転送するために定義された他のプロトコルとの組み合わせで制御チャネルとしてSNMPを使用することを含みます。それはセキュリティやその他の問題の数を発生させますので、このアプローチは次善です。 SNMPを介したコンフィギュレーション・大量のデータを転送することは効率的にこの文書で先に記載されている技術のいくつかを行うことができます。このポリシーセクションでは、さらに大きな効率は比較的新しいデザインメカニズムのセットを使用して達成することができる方法を示しています。このセクションでは、バックグラウンドを与え、この分野に関連する用語を定義し、いくつかの展開アプローチを説明します。
In the past few years of output from standards organizations and networking vendor marketing departments, the term 'policy' has been heavily used, touted, and contorted in meaning. The result is that the true meaning of 'policy' is unclear without greater qualification where it is used.
標準化団体とのネットワークベンダーのマーケティング部門からの出力の過去数年間では、用語「ポリシー」は重く、使用もてはやさ、との意味でねじ曲げられています。その結果は、「政策」の本当の意味は、それが使用されている大きな資格なし不明であるということです。
[42] gives the term 'policy' two explicit definitions:
[42]用語「政策」は2つの明示的な定義を与えます：
- A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit).
- 現在および将来の決定を導くと決定するアクションの明確な目標、コースや方法。 「ポリシー」は、（例えば、ビジネスユニット内で定義されたポリシーなど）、特定のコンテキスト内で実施または実行されます。
- Policies as a set of rules to administer, manage, and control access to network resources.
- 、管理、管理、およびネットワークリソースへのアクセスを制御するルールのセットとして方針。
Note that these two views are not contradictory since individual rules may be defined in support of business goals.
個々のルールは、ビジネス目標の支援に定義されていることがあるので、これらの二つのビューが矛盾していないことに注意してください。
As it pertains to our discussion of the term 'policy-based configuration', the meaning is significantly more specific. In this context, we refer to a way of integrating data and the management actions which use it in such a way that:
それは用語「ポリシーベースの設定」の議論に関係するため、意味がはるかに固有のものです。この文脈において、我々は、データとそのような方法でそれを使用する管理アクションを統合する方法を参照してください。
- there is the ability to specify "default" configuration data for a number of instances of managed elements, where those instances can be correlated in some data driven or algorithmic way. The engine to do this correlation and activate instances from defaults may reside in the agent or externally. Where the representation of these defaults are in the MIB design itself, the object types supporting this notion are referred to as "template objects".
- これらのインスタンスは、いくつかのデータ駆動又はアルゴリズム的な方法で相関させることができる管理対象要素のインスタンスの数は、「デフォルト」の設定データを指定する機能があります。この相関を行うと、デフォルトからインスタンスをアクティブにするエンジンは、エージェントにまたは外部に存在することができます。これらのデフォルトの表現は、MIBの設計自体にある場合には、この概念をサポートするオブジェクト・タイプは、「テンプレートオブジェクト」と呼ばれています。
- the activation of instance data derived from template object types results from minimal activation directives from the management application, once the instances of the template object types have been established.
- テンプレート・オブジェクト・タイプのインスタンスが確立された後、インスタンスデータの活性化は、管理アプリケーションから最小の起動指令からテンプレートオブジェクトタイプの結果に由来します。
- somewhat independently, the architecture of the overall management agent may accommodate the definition and evaluation of management and configuration policies. The side-effects of the evaluation of these policies typically include the activation of certain configuration directives. Where management data design exposes template object types, the policy-driven activation can (and ideally, should) include the application of template object instances to the analogous managed element instance-level values.
- 多少独立に、全体的な管理エージェントのアーキテクチャは、管理および構成ポリシーの定義と評価を収容することができます。これらのポリシーの評価の副作用は、典型的には、特定の構成ディレクティブの活性化を含みます。管理データのデザインテンプレート・オブジェクト・タイプを公開する場合、ポリシー駆動型の活性化は、（理想的には、必要があります）類似管理要素インスタンス・レベルの値にテンプレート・オブジェクト・インスタンスのアプリケーションを含むことができます。
As it pertains to template object data, the underlying notions implied here have been prevalent for some time in non-SNMP management regimes. A common feature of many command line interfaces for configuring routers is the specification of one or more access control lists. These typically provide a set of IP prefixes, BGP autonomous system numbers, or other such identifying constructs (see, for example, [42]). Once these access control lists are assembled, their application to various interfaces, routing processes, and the like are specified typically in the configuration of what the access control list is applied to. Consistent with the prior properties to define our use of policy-based configuration, a) the access list is defined independent from its point of application, and b) its application is independent of the access list definition. For example, changing the application of an access list from one interface to the other does not require a change in the access list itself. The first point just mentioned suggests what is necessary for template-based data organization. The second suggests its application in a policy-based manner.
それは、オブジェクトデータをテンプレートに関連するとして、ここでは暗黙の基礎となる概念は、非SNMP管理体制にいくつかの時間のために普及しています。ルータを設定するための多くのコマンドライン・インタフェースの共通の特徴は、1つまたは複数のアクセス制御リストの仕様です。これらは、典型的には、IPプレフィクスのセット、BGP自律システム番号、または他のそのような特定の構築物を（[42]、例えば、参照）を提供します。これらのアクセス制御リストが組み立てられると、各種インターフェース、ルーティングプロセス、等への応用は、アクセス制御リストが適用されるものの構成では、典型的には規定されています。ポリシーベースの設定の私達の使用を定義する前の特性と一致して、A）アクセスリストは、アプリケーションのそのポイントから独立に定義され、およびb）そのアプリケーションは、アクセスリストの定義とは無関係です。例えば、他の1つのインターフェイスからアクセスリストのアプリケーションを変更するアクセスリスト自体の変更を必要としません。今述べた最初のポイントは、テンプレートベースのデータ編成のために必要なものを示唆しています。第二は、ポリシーベースの方法におけるその適用を示唆しています。
Let us now examine the motivation for such a system or subsystem (perhaps bounded at the level of a 'template-enabled' MIB module, given the above definition). Let us explore the importance of policy-based techniques to configuration specifically.
私たちは今、（おそらく上記の定義を考えると、「テンプレート対応の」MIBモジュールのレベルで囲まれた）このようなシステムまたはサブシステムのための動機を調べてみましょう。私たちは、具体的構成にポリシーベースの技術の重要性を探求してみましょう。
The number of configurable parameters and 'instances' such as interfaces has increased as equipment has become larger and more complex.
機器は、より大きく、より複雑になってきているように設定可能なパラメータなどのインターフェースとしての「インスタンス」の数が増加しています。
At the same time, there is a need to configure many of these systems to operate in a coordinated fashion. This enables the delivery of new specialized services that require this coordinated configuration. Examples include delivery of virtual private networks and connections that guarantee specific service levels.
同時に、協調的に動作するために、これらのシステムの多くを設定する必要があります。これは、この設定を調整する必要が新しい専門的なサービスの提供を可能にします。例としては、特定のサービスレベルを保証する仮想プライベートネットワークとの接続の送達を含みます。
The growth in size and complexity of configuration information has significant implications for its organization as well as its efficient transfer to the management agent. As an example, an agent that implements the Bridge MIB [24] could be used to represent a large VLAN with some 65,000 port entries. Configuring such a VLAN would require the establishment of dot1dStpPortTable and dot1DStaticTable entries for each such virtual port. Each table entry would contain several parameters. A more efficient approach is to provide default values for the creation of new entries that are appropriate to the VLAN environment in our example. The local management infrastructure should then iterate across the system setting the default values to the selected ports as groups.
コンフィギュレーション情報のサイズと複雑さの増加は、その組織だけでなく、管理エージェントへの効率的な転送のために重要な意味を持っています。一例として、ブリッジMIB [24]を実装する薬剤は、いくつかの65,000ポート・エントリを持つ大規模なVLANを表すために使用することができます。そのようなVLANを設定するような各仮想ポートのためのdot1dStpPortTableとdot1DStaticTableエントリの確立が必要となります。各テーブルエントリは、いくつかのパラメータが含まれます。より効率的なアプローチは、我々の例では、VLAN環境に適した新しいエントリを作成するためのデフォルト値を提供することです。ローカル管理インフラストラクチャは、次いで、グループとして選択されたポートにデフォルト値を設定するシステムを横切って反復すべきです。
To date, this kind of large-scale configuration has been accomplished with file transfer, by setting individual MIB objects, or with many CLI commands. In each of these approaches the details for each instance are contained in the file, CLI commands or MIB objects. That is, they contain not only the value, and type of object, but also the exact instance of the object to which to apply the value. It is this property that tends to make configuration operations explode as the number of instances (such as interfaces) grows. This per-instance approach can work for a few machines configured by experts, but there is a need for a more scalable solution. Template-based data organization and policy-based management abstracts the details above the instance level, which means that fewer SET requests are sent to a managed device.
現在までに、大規模構成のこの種は、個々のMIBオブジェクトを設定することにより、または多くのCLIコマンドで、ファイル転送で行われてきました。これらのアプローチのそれぞれに各インスタンスの詳細をファイルに含まれている、CLIコマンドまたはMIBオブジェクト。それは、彼らが価値、およびオブジェクトの種類だけでなく、値を適用するオブジェクトの正確なインスタンスだけでなくが含まれている、です。これは、（例えばインタフェースなど）のインスタンスの数が大きくなるように設定操作が爆発する傾向がある。この特性です。このインスタンスごとのアプローチは、専門家によって構成された数台のマシンのために働くことができますが、よりスケーラブルなソリューションの必要性があります。テンプレートベースのデータ編成とポリシーベースの管理は、より少ないSET要求が管理対象デバイスに送信されることを意味し、インスタンス・レベル、上記の詳細を抽象化します。
Realization of such a policy-driven system requires agents that can take defaults and apply them to instances based on a rule that defines under what conditions the defaults (policy) are to be applied. A policy-driven configuration system which is to be scalable needs to expose a means of layering its application of defaults at discrete ranges of granularity. The spectrum of that granularity might have a starting hierarchy point to apply defaults at the breadth of a network service.
そのようなポリシー駆動型システムの実現には、デフォルト値を取り、デフォルト（ポリシー）が適用されるどのような条件の下で定義されたルールに基づいて、インスタンスに適用することができる薬剤を必要とします。スケーラブルとなるポリシー駆動型の構成システムは、粒度の離散的な範囲でのデフォルトの応用を積層する手段を露出させる必要があります。その粒度のスペクトルは、ネットワークサービスの幅にデフォルト値を適用し始め階層ポイントを持っているかもしれません。
Ultimately, such a layering ends up with features to support instance-level object instance data within the running agent.
最終的に、そのような積層は、実行中のエージェント内のインスタンスレベルオブジェクトのインスタンス・データをサポートする機能を備えてしまいます。
An example of this kind of layering is implicit in the principle of operations of a SNMPCONF Policy-Based Management MIB [36] (PM-MIB) implementation. However, other entity management systems have been employing these kinds of techniques end-to-end for some time, in some cases using SNMP, in some cases using other encodings and transfer technologies. What the PM-MIB seeks to establish, in an environment ideal for its deployment, is an adaptation between MIB module data which was not designed using template object types, and the ability to allow the PM-MIB agent engine to apply instances of that data as though it were template-based.
レイヤーのこの種の例は、SNMPCONFポリシーベースの管理MIB [36]（PM-MIB）の実装の動作原理で暗黙的です。しかしながら、他のエンティティの管理システムは、他の符号化及び転送技術を使用して、いくつかのケースでは、SNMPを使用して、いくつかのケースでは、エンドツーエンドしばらく技術のこれらの種類を採用してきました。 PM-MIBを確立しようと何を、その展開のための環境の理想的で、テンプレート・オブジェクト・タイプを使用して設計されていないMIBモジュールのデータ間の適応、およびPM-MIBエージェントエンジンはそのデータのインスタンスを適用できるようにする機能ですそれは、テンプレートベースであるかのように。
In order for effective policy management to take place, a range of information about the network elements is needed to avoid making poor policy decisions. Even in those cases where policy-based configuration is not in use, much of the information described in this section can be useful input to the decision-making process about what type of configuration operations to do.
場所を取るための効果的なポリシー管理のためのためには、ネットワーク要素に関する情報の範囲は、貧弱な政策決定をすることを避けるために必要とされます。でも、ポリシーベースの設定が使用されていないような場合には、このセクションに記載された情報の多くはどうする設定操作の種類についての意思決定プロセスに役立ち入力することができます。
For this discussion it is important to make distinctions between distribution of policy to a system, activation of a policy in a system, and changes/failures that take place during the time the policy is expected to be active. For example, if an interface is down that is included in a policy that is distributed, there may not be an error since the policy may not be scheduled for activation until a later time.
この議論のためには、システム、システム内のポリシーの活性化、およびポリシーが有効であることが予想される時間の間に起こる変更/障害に政策の分布との区別をすることが重要です。それが配布されるポリシーに含まれている下りインターフェースがある場合、ポリシーは、後の時間まで、活性化のためにスケジュールされないかもしれないので、例えば、誤差がないかもしれません。
On the other hand, if a policy is distributed and applied to an interface that should be operational and it is not, clearly this is a problem, although it is not an error in the configuration policy itself. With this as background, here are some areas to consider that are important to making good policy configuration decisions and establishing when a policy has 'failed'.
一方、ポリシーが配布され、インターフェイスに適用された場合、動作すべきことであるが、それは構成ポリシー自体に誤りはないが、それは、明らかにこれは、問題ではないれています。背景としてこれにより、ここで良いポリシー構成意思決定や政策が「失敗」したときに確立するための重要な考慮すべきいくつかの領域があります。
o The operational state of network elements that are to be configured.
Oであるネットワーク要素の動作状態が設定されます。
Care should be taken to determine if the sub-components to be configured are available for use. In some cases the elements may not be available. The policy configuration software should determine if this is a prerequisite to policy installation or if the condition is even acceptable. This decision is separate from the one to be made about policy activation. Installation is when the policy is sent from the policy manager to the managed device and activation is turning on the policy. In those cases where policy is distributed when the sub-component such as an interface or disk is not available, the managed system should send a notification to the designated management station when the policy is to become active or if the resource is still not available.
注意を構成するサブコンポーネントが使用可能であるかどうかを決定するために解釈されるべきです。いくつかのケースでは要素が使用できない場合があります。これは、ポリシーのインストールの前提条件がある場合や条件でも受け入れ可能である場合、ポリシー設定ソフトウェアが決定する必要があります。この決定は、ポリシーの活性化について行われるべきものとは別のものです。ポリシーを管理対象デバイスにポリシーマネージャから送信され、活性化が政策をオンにしたときのインストールがあります。ポリシーがアクティブまたはリソースがまだ利用可能でない場合になることである場合、インターフェースやディスクなどのサブコンポーネントが利用できない場合、ポリシーが配布されているような場合、管理システムは、指定された管理ステーションに通知を送信します。
o The capabilities of the devices in the network.
ネットワーク内のデバイスの能力、O。
A capability can be almost any unit of work a network element can perform. These include routing protocols supported, Web server and OS versions, queuing mechanisms supported on each interface that can be used to support different qualities of service, and many others. This information can be obtained from the capabilities table of the Policy MIB module [36].
能力は、ネットワーク要素が実行できる作業のほとんどすべての単位とすることができます。これらは、異なるサービス品質、および他の多くをサポートするために使用することができる各インタフェース上でサポートメカニズムをキューイングサポートされているルーティングプロトコル、WebサーバとOSのバージョンを含みます。この情報は、ポリシーMIBモジュール[36]の能力テーブルから得ることができます。
Historically, management applications have had to obtain this type of information by issuing get requests for objects they might want to use. This approach is far less efficient since it requires many get requests and is more error prone since some instances will not exist until configured. The new capabilities table is an improvement on the current technique.
歴史的に、管理アプリケーションは、彼らが使用する場合がありますオブジェクトに対するGETリクエストを発行することによって、この種の情報を入手しなければなりませんでした。それは多くのリクエストを取得し、設定されるまで、いくつかのインスタンスが存在しないため発生しやすい複数の誤りである必要があるため、このアプローチは、はるかに効率的です。新機能のテーブルには、現在の技術を改良したものです。
o The capacity of the devices to perform the desired work.
Oデバイスの容量は、所望の作業を実行します。
Capability is an ability to perform the desired work while a capacity is a measure of how much of that capability the system has. The policy configuration application should, wherever possible, evaluate the capacity of the network element to perform the work identified by the policy. In some systems it will not be possible to obtain the capacity of the managed elements to perform the desired work directly, even though it may be possible to monitor the amount of work the element performs. In these cases, the management application may benefit from pre-configured information about the capacity of different network elements so that evaluations of the resources available can be done before distributing new policies.
能力は、容量は、システムが持っている能力をどのくらいの尺度でありながら、所望の作業を行うことができることです。ポリシーの構成アプリケーションは、可能な限り、ポリシーによって識別される作業を実行するために、ネットワーク要素の能力を評価する必要があります。いくつかのシステムでは、要素が実行する作業の量を監視することが可能であっても、直接所望の作業を実行する管理対象要素の容量を得ることができないであろう。これらのケースでは、管理アプリケーションは、利用可能なリソースの評価は新しいポリシーを配布する前に行うことができるように、異なるネットワークエレメントの容量に関する事前設定された情報から利益を得ることができます。
Utilization refers to how much capacity for a particular capability has been consumed. For devices that have been under policy configuration control for any period of time, a certain percentage of the available capacity of the managed elements will be used. Policies should not be distributed to systems that do not have the resources to carry out the policy in a reasonable period of time.
利用には、特定の機能のための多くの容量が消費されている方法を指します。任意の期間のためのポリシー構成管理下にされているデバイスについては、管理対象要素の利用可能な容量の一定割合が使用されます。ポリシーは、合理的な期間で政策を遂行するためのリソースを持っていないシステムに配布すべきではありません。
This section applies equally to systems that are not policy-based as well as policy-based systems, since configuration operations often need to be synchronized across time zones. Wherever possible, the network elements should support time information using the standard DateAndTime TC that includes local time zone information. Policy-based management often requires more complex time expressions than can be conveyed with the DateAndTime TC. See the Policy-Based Management MIB document [36] for more information. Some deployed systems do not store complex notions of local time and thus may not be able to process policy directives properly that contain time zone relevant data. For this reason, policy management applications should have the ability to ascertain the time keeping abilities of the managed system and make adjustments to the policy for those systems that are time-zone challenged.
このセクションでは、設定操作は、多くの場合、タイムゾーン間で同期する必要があるため、ポリシーベースだけでなく、ポリシー・ベースのシステムではないシステムにも同様に適用されます。可能な限り、ネットワーク要素は、ローカルタイムゾーン情報を含む標準のDateAndTime TCを使用して時刻情報をサポートしなければなりません。ポリシーベースの管理は、多くの場合のDateAndTime TCに搬送することができるよりも、より複雑な時間表現が必要です。詳細については、ポリシーベースの管理MIBドキュメント[36]を参照してください。いくつかの展開システムでは、タイムゾーンの関連データが含まれている適切に政策のディレクティブを処理することができないかもしれないので、現地時間の複雑な概念を保存しないでください。このため、ポリシー管理アプリケーションは、管理対象システムの能力を維持する時間を把握し、タイムゾーンが挑戦しているそれらのシステムのための政策の調整を行う能力を持っている必要があります。
Policies sent to a device may contain conflicting instructions. Detection of such commands can occur at the device or management level and may be resolved using any number of mechanisms (examples are, last configuration set wins, or abort change). These unintended conflicts should be reported. Conflicts can occur at different levels in a chain of commands. Each 'layer' in policy management system should be able to check for some errors and report them. This is conceptually identical to programs raising an exception and passing that information on to software that can do something meaningful with it.
デバイスに送信されたポリシーが矛盾する命令を含むことができます。そのようなコマンドの検出は、デバイスまたは管理レベルで発生することができ、機構の任意の数の（例としては、最後のコンフィギュレーションセットの勝利であるか、または変更を中止する）を使用して解決することができます。これらの意図しない衝突が報告されるべきです。競合は、コマンドのチェーン内の異なるレベルで発生する可能性があります。ポリシー管理システムの各「層」は、いくつかのエラーをチェックし、それらを報告することができるはずです。これは、プログラムの例外を上げ、それに意味のある何かを行うことができますソフトウェアの上で、その情報を渡すと概念的に同じです。
At the instance level, conflict detection has been performed in a limited way for some time in software that realizes MIB objects at this level of resolution. This detection is independent of policy. The types of 'conflicts' usually checked for are resource availability and validity of the set operations. In a policy enabled system, there are no additional requirements for this software assuming that good error detection and reporting appropriate to this level have already been implemented.
インスタンスレベルでは、競合の検出分解能のこのレベルでMIBオブジェクトを実現するソフトウェアでしばらくの間限定的に行われています。この検出は、政策とは無関係です。通常のチェック「競合」の種類は、集合演算のリソースの可用性と妥当性です。政策対応のシステムでは、このレベルに合った優れたエラー検出および報告が既に実施されていると仮定して、このソフトウェアには、追加の要件はありません。
It is essential to consider changes to configuration that are initiated outside of the policy system. A goal of SNMP-based policy management is to coexist with other kinds of management software that have historically been instance based management. The best example is the command line interface.
政策体系の外で開始された構成への変更を考慮することが不可欠です。 SNMPベースのポリシー管理の目標は、歴史的にインスタンスベースの管理されている管理ソフトウェアの他の種類と共存することです。最良の例は、コマンドライン・インタフェースです。
A notification should be sent whenever an out-of-policy control change is made to an element that is under the control of policy. This notification should include the policy that was affected, the instance of the element that was changed and the object and value that it was changed to.
アウト・オブ・ポリシ制御変更がポリシーの制御下にある要素に言及するたびに通知が送られるべきです。この通知は、に変更した影響を受けたポリシー、変更された要素のインスタンスとオブジェクトと値を含むべきです。
Even for those systems that have no concept of policy control, the ideas presented above make sense. That is, if SNMP co-exists with other access methods such as a CLI, it is essential that the management station remain synchronized with changes that might have been made to the managed device using other methods. As a result, the approach of sending a notification when another access method makes a change is a good one. Of course this should be configurable by the user.
でも、ポリシー制御の概念はありませんこれらのシステムのために、上記のアイデアは意味をなさない。これは、SNMPは、CLIなどの他のアクセス方法と共存している場合、管理ステーションは、他の方法を使用して管理対象デバイスに対して行われた可能性のある変更と同期残ることが不可欠である、です。その結果、別のアクセス方法が変更を行うときに通知を送信するアプローチが良いものです。もちろん、これはユーザが設定する必要があります。
Notifications can be useful in determining a failure of a policy as a result of an error in the policy or element(s) under policy control. As with all notifications, they should be defined and controlled in such a way that they do not create a problem by sending more than are helpful over a specific period of time. For example, if a policy is controlling 1,000 interfaces and fails, one notification rather than 1,000 may be the better approach. In addition, such notifications should be defined to include as much information as possible to aid in problem resolution.
通知は、ポリシー制御下のポリシーまたは要素（複数可）の誤差の結果として、政策の失敗を決定するのに有用であり得ます。すべての通知と同じように、彼らは、特定の期間にわたり有用である以上送信することで問題を作成しないような方法で定義され、制御されなければなりません。ポリシー1000個のインタフェースを制御し、失敗した場合、例えば、一つの通知なく、1,000より良いアプローチであってもよいです。加えて、そのような通知は、問題の解決を助けるために、できるだけ多くの情報を含むように定義されるべきです。
One of the advantages of policy-based configuration with SNMP is that many configuration operations can be conveyed with a small amount of data. Changing a single configuration parameter for each of 100 interfaces on a system might require 100 CLI commands or 100 SNMP variable bindings using conventional techniques.
SNMPとポリシーベースの構成の利点の一つは、多くの構成操作を少ないデータ量で搬送することができることです。システム上の100のインターフェイスの各々に対して単一の設定パラメータを変更すると、100のCLIコマンドまたは従来の技術を用いて、100のSNMP変数バインディングを必要とするかもしれません。
Using policy-based configuration with SNMP, a single SET PDU can be sent with the policy information necessary to apply a configuration change to 100 similar interfaces. This efficiency gain is the result of eliminating the need to send the value for each instance to be configured. The 'default' for each of the instances included in the policy is sent, and the rule for selection of the instances that the default is to be applied to can also be carried (see the Policy MIB module [36]).
SNMPとポリシーベースの設定を使用して、単一のSET PDU 100の同様のインターフェイスに設定変更を適用するために必要なポリシー情報を用いて送信することができます。この効率の利得を設定するための各インスタンスの値を送信する必要性を排除した結果です。ポリシーに含まれるインスタンスのそれぞれについての「デフォルト値は」（ポリシーMIBモジュール[36]を参照）が送信され、デフォルトが適用されることをインスタンスを選択するためのルールも行うことができます。
To extend the example above, assume that there are 10 parameters that need to change. Using conventional techniques, there would now be 1,000 variable bindings, one for each instance of each new value for each interface. Using policy-based configuration with SNMP, it is still likely that all the information can be conveyed in one SET PDU. The only difference in this case is that there are ten parameters sent that will be the 'template' used to create instances on the managed interfaces.
上記の例を拡張するために、変更する必要が10個のパラメータがあると仮定する。従来の技術を用いて、今千の変数バインディング、各インターフェイスの各新しい値の各インスタンスに対して1つ存在することになります。 SNMPとポリシーベースの設定を使用して、すべての情報が1つのSET PDUに搬送することができるということはまだ可能性があります。この場合の唯一の違いは、管理インターフェイス上でインスタンスを作成するために使用される「テンプレート」となります送ら10個のパラメータがあるということです。
This efficiency gain not only applies to SET operations, but also to those management operations that require configuration information. Since the policy is also held in the storage for cross-instance defaults (for example, the pmPolicyTable in [36]), an entire data set that potentially controls hundreds of rows of information can be retrieved in a single GET request.
操作を設定するために適用されますが、また、構成情報を必要とする管理操作をするだけでなく、この効率ゲイン。ポリシーはまた、（例えば、pmPolicyTableに[36]）は、クロスインスタンスのデフォルトのために記憶装置に保持されているので、潜在的に情報の行数百を制御する全体のデータセットは、単一のGET要求で取得することができます。
A policy-friendly data organization such as this is consistent and integrates well with MIB module objects which support "summary" activation and activation reporting, of the kind discussed in Section 3.3.5.
このようなポリシーに優しいデータ編成は、一貫性があり、セクション3.3.5で説明した種類の「概要」の活性化と活性化のレポートをサポートするMIBモジュールオブジェクトと統合します。
This section defines a MIB module that controls the heating and air conditioning system for a large building. It contains both configuration and counter objects that allow operators to see how much cooling or heating a particular configuration has consumed. Objects that represent the configuration information at a "default" level (as referenced above) are also included.
このセクションでは、大きな建物の加熱および空調システムを制御MIBモジュールを定義します。これは、事業者が消費したどのくらいの冷却または特定の構成を加熱見ることができ、両方の設定とカウンタオブジェクトが含まれています。 （上記参照のように）「デフォルト」レベルの設定情報を表すオブジェクトも含まれます。
These tables, in combination with the application of the tables' row instance data as templated 'defaults', will allow operators to configure and monitor many rooms at once, change the configuration parameters based on time of day, and make a number of other sophisticated decisions based on the 'policy' implied by these defaults and their application. For this reason, these configuration controls have their instances specified from template object types.
これらのテーブルは、テーブルのアプリケーションとの組み合わせで行インスタンスのデータとして、テンプレート 『デフォルト』は、事業者が設定すると、一度に多くの部屋を監視し、その日の時間に基づいて設定パラメータを変更し、他の洗練されたの数を行うことができますこれらのデフォルト値とそのアプリケーションによって暗黙の方針」に基づいて判断。このため、これらの設定のコントロールは、テンプレートオブジェクトタイプから指定された彼らのインスタンスを持っています。
In our simplified Heating Ventilation and Air Conditioning (HVAC) model we will create three tables based on a simple analysis. More complicated systems will need more tables, but the principles will be the same.
私たちの単純化暖房換気および空調（HVAC）モデルでは、我々は簡単な分析に基づいて3つのテーブルを作成します。より複雑なシステムでは、複数のテーブルが必要になりますが、原則は同じになります。
Step 1: As with any other MIB module design, the first step is to determine what objects are necessary for configuration and control operations. The first table to be created is a fairly traditional monitoring table. It includes indices so that we will know what rooms the counters and status objects are for. It includes an object that is a RowPointer to a table that contains configuration information. The objects for the bldgHVACTable, our first table in the HVAC MIB module are:
ステップ1：任意の他のMIBモジュールの設計と同様に、最初のステップは、構成および制御動作のために必要であるかのオブジェクトを決定することです。作成された最初のテーブルには、かなり伝統的なモニタリング・テーブルです。我々が何であるかの部屋カウンタとステータスオブジェクト知っているように、これは、インデックスが含まれています。これは、コンフィギュレーション情報を含むテーブルにRowPointerであるオブジェクトを含みます。 bldgHVACTableためのオブジェクトは、HVAC MIBモジュールで私たちの最初の表は以下のとおりです。
Index objects that identify what floor and office we are managing:
私たちが管理しているものを床やオフィス識別するインデックスオブジェクト：
bldgHVACFloor
bldgHVACOffice
A single index reference to a table that 'glues' configuration information defaults with descriptive information:
テーブルに単一のインデックス参照その記述情報との「接着剤」の構成情報のデフォルト：
bldgHVACCfgTemplate
bldgHVACCfgTemplate
A set of objects that show status and units of work (bldgHVACCoolOrHeatMins) and standard per-row SnmpAdminString, StorageType, and RowStatus columnar objects:
ステータスと作業単位（bldgHVACCoolOrHeatMins）および標準当たり行れるSnmpAdminString、StorageType、およびRowStatusの円柱状のオブジェクトを表示オブジェクトのセット。
bldgHVACFanSpeed
bldgHVACCurrentTemp
bldgHVACCoolOrHeatMins
bldgHVACDiscontinuityTime
bldgHVACOwner
bldgHVACStatus
Step 2: A configuration description table. The purpose of this table is to provide a unique string identifier for templates. These may be driven by policies in a network. If it were necessary to configure devices to deliver a particular quality of service, the index string of this table could be the name and the description part, it could be a brief description of the underlying motivation such as: "provides extra heat to corner offices to counteract excessive exterior wind chill". Standard owner and status objects may also be helpful and are included here. The row columnar objects are:
ステップ2：構成記述テーブル。この表の目的は、テンプレートの一意の文字列識別子を提供することです。これらは、ネットワーク内のポリシーによって駆動されてもよいです。それはサービスの特定の品質を提供するためにデバイスを構成するために必要であった場合は、このテーブルのインデックス文字列は、名前と説明の一部とすることができる、それは、次のような根本的な動機を簡単に説明することができます：「コーナーオフィスに余分な熱を提供過度の外部の風の寒さに対抗します」。標準的な所有者とステータスのオブジェクトにも役立つかもしれないし、ここに含まれています。行円柱状のオブジェクトは、次のとおりです。
bldgHVACCfgTemplateInfoIndex
bldgHVACCfgTemplateInfoID
bldgHVACCfgTemplateInfoDescr
bldgHVACCfgTemplateInfoOwner
bldgHVACCfgTemplateInfoStatus
Notice that to this point we have provided no configuration information. That will be in the next table. Some readers may wonder why this table is not combined with the configuration template table described in the next step. In fact, they can be. The reason for having a separate table is that as systems become more complex, there may be more than one configuration table that points to these descriptions. Another reason for two tables is that this in not reproduced for every template and instance, which can save some additional data movement. Every designer will have to evaluate the tradeoffs between number of objects and data movement efficiency just as with other MIB modules.
この時点まで、我々は何の設定情報を提供していないことに注意してください。それは、次の表になります。このテーブルは、次のステップで説明した構成テンプレートテーブルと組み合わされていない理由一部の読者は疑問に思うかもしれ。実際には、彼らがすることができます。別のテーブルを有する理由は、システムがより複雑になるにつれて、これらの説明を指し、複数のコンフィギュレーションテーブルが存在する可能性があることです。二つのテーブルのためのもう一つの理由は、この中には、いくつかの追加のデータの移動を保存することができ、すべてのテンプレートおよびインスタンスのために再現されないということです。すべての設計者は、単に他のMIBモジュールと同様にオブジェクトの数とデータ移動の効率の間のトレードオフを評価する必要があります。
Step 3: The bldgHVACCfgTemplateTable contains the specific configuration parameters that are pointed to by the bldgHVACConfigPtr object. Note that many rows in the bldgHVACTable can point to an entry in this table. It is also possible for entries to be used by 1 or 0 rows of the bldgHVACTable. It is the property of allowing multiple rows (instances) in the bldgHVACTable to point to a row in this table that can produce such efficiency gains from policy-based management with SNMP. Also notice that the configuration data is tied directly to the counter data so that people can see how configurations impact behavior.
ステップ3：bldgHVACCfgTemplateTableはbldgHVACConfigPtrオブジェクトによって指し示されている特定の構成パラメータが含まれています。 bldgHVACTableで多くの行がこの表のエントリを指すことができることに注意してください。エントリはbldgHVACTableの1つの又は0行で使用することも可能です。これは、SNMPとポリシーベースの管理から、このような効率の向上を生成することができ、このテーブル内の行を指すようにbldgHVACTableの複数の行（インスタンス）を可能にする特性です。また、人々がどのように構成インパクト動作を見ることができるように構成データがカウンタデータに直接接続されていることに気づきます。
The objects in this table are all that are necessary for configuration and connection to the other tables as well as the usual SnmpAdminString, StorageType, and RowStatus objects:
このテーブルの目的は、構成および他のテーブルと同様に、通常れるSnmpAdminString、StorageType、およびRowStatusのオブジェクトへの接続のために必要であることをすべてしています。
A simple index to the table:
テーブルへの単純なインデックス：
bldgHVACCfgTemplateIndex
bldgHVACCfgTemplateIndex
The configuration objects:
構成オブジェクト：
bldgHVACCfgTemplateDesiredTemp
bldgHVACCfgTemplateCoolOrHeat
Administrative objects for SnmpAdminString and RowStatus:
れるSnmpAdminStringとRowStatusのための管理オブジェクト：
bldgHVACCfgTemplateInfo
bldgHVACCfgTemplateOwner
bldgHVACCfgTemplateStorage
bldgHVACCfgTemplateStatus
BLDG-HVAC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Counter32,
Gauge32, OBJECT-TYPE, Unsigned32, experimental
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
TEXTUAL-CONVENTION,
TimeStamp, RowStatus, StorageType
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
bldgHVACMIB MODULE-IDENTITY LAST-UPDATED "200303270000Z" ORGANIZATION "SNMPCONF working group E-mail: snmpconf@snmp.com" CONTACT-INFO "Jon Saperia Postal: JDS Consulting 174 Chapman Street Watertown, MA 02472 U.S.A. Phone: +1 617 744 1079 E-mail: saperia@jdscons.com
bldgHVACMIB MODULE-IDENTITY LAST-UPDATED "200303270000Z" ORGANIZATION "SNMPCONFワーキンググループEメール：snmpconf@snmp.com" CONTACT-INFO「ジョンSaperia郵便：JDSコンサルティング174チャップマン・ストリートウォータータウン、MA 02472 USA電話：+1 617 744 1079 Eメール：saperia@jdscons.com
Wayne Tackabury
Postal: Gold Wire Technology
411 Waverley Oaks Rd.
Waltham, MA 02452
U.S.A.
Phone: +1 781 398 8800
E-mail: wayne@goldwiretech.com
Michael MacFaden Postal: Riverstone Networks 5200 Great America Pkwy. Santa Clara, CA 95054 U.S.A. Phone: +1 408 878 6500 E-mail: mrm@riverstonenet.com
マイケルMacFaden郵便：リバーストーン・ネットワーク5200グレートアメリカパークウェイ。サンタクララ、CA 95054 U.S.A.電話：+1 408 878 6500 Eメール：mrm@riverstonenet.com
David Partain Postal: Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden E-mail: David.Partain@ericsson.com" DESCRIPTION "This example MIB module defines a set of management objects for heating ventilation and air conditioning systems. It also includes objects that can be used to create policies that are applied to rooms. This eliminates the need to send per-instance configuration commands to the system.
デビッドパーテイン郵便：エリクソンABの私書箱ボックス1248 SE-581 12リンチェピングスウェーデンEメール：David.Partain@ericsson.com「DESCRIPTION」この例MIBモジュールは、加熱、換気及び空調システムのための管理オブジェクトのセットを定義します。また、部屋に適用されるポリシーを作成するために使用できるオブジェクトが含まれています。これは、システムにインスタンスごとの構成コマンドを送信する必要がなくなります。
Copyright (C) The Internet Society (2003). This version of
this MIB module is part of RFC 3512; see the RFC itself for
full legal notices."
REVISION "200303270000Z"
DESCRIPTION
"Initial version of BLDG-HVAC-MIB as published in RFC 3512."
::= { experimental 122 }
bldgHVACObjects OBJECT IDENTIFIER ::= { bldgHVACMIB 1 }
bldgConformance OBJECT IDENTIFIER ::= { bldgHVACMIB 2 }
-- -- Textual Conventions --
- - テキストの表記法 -
BldgHvacOperation ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Operations supported by a heating and cooling system.
A reference to underlying general systems would go here."
SYNTAX INTEGER {
heat(1),
cool(2)
}
--
-- HVAC Objects Group
--
--
bldgHVACTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is the representation and data control
for building HVAC by each individual office.
The table has rows for, and is indexed by a specific
floor and office number. Each such row includes
HVAC statistical and current status information for
the associated office. The row also contains a
bldgHVACCfgTemplate columnar object that relates the
bldgHVACTable row to a row in the bldgHVACCfgTemplateTable.
If this value is nonzero, then the instance in the row
that has a value for how the HVAC has been configured
in the associated template (bldgHVACCfgTeplateTable row).
Hence, the bldgHVACCfgTeplateTable row contains the
specific configuration values for the offices as described
in this table."
::= { bldgHVACObjects 1 }
bldgHVACEntry OBJECT-TYPE
SYNTAX BldgHVACEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in the bldgHVACTable. Each row represents a particular
office in the building, qualified by its floor and office
number. A given row instance can be created or deleted by
set operations upon its bldgHVACStatus columnar
object instance."
INDEX { bldgHVACFloor, bldgHVACOffice }
::= { bldgHVACTable 1 }
BldgHVACEntry ::= SEQUENCE {
bldgHVACFloor Unsigned32,
bldgHVACOffice Unsigned32,
bldgHVACCfgTemplate Unsigned32,
bldgHVACFanSpeed Gauge32,
bldgHVACCurrentTemp Gauge32,
bldgHVACCoolOrHeatMins Counter32,
bldgHVACDiscontinuityTime TimeStamp,
bldgHVACOwner SnmpAdminString,
bldgHVACStorageType StorageType,
bldgHVACStatus RowStatus
}
bldgHVACFloor OBJECT-TYPE
SYNTAX Unsigned32 (1..1000)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This portion of the index indicates the floor of the
building. The ground floor is considered the
first floor. For the purposes of this example,
floors under the ground floor cannot be
controlled using this MIB module."
::= { bldgHVACEntry 1 }
bldgHVACOffice OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This second component of the index specifies the
office number."
::= { bldgHVACEntry 2 }
bldgHVACCfgTemplate OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The index (bldgHVACCfgTemplateIndex instance) of an entry in the 'bldgHVACCfgTemplateTable'. The bldgHVACCfgTable row instance referenced is a pre-made configuration 'template' that represents the configuration described by the bldgHVACCfgTemplateInfoDescr object. Note that not all configurations will be under a defined template. As a result, a row in this bldgHVACTable may point to an entry in the bldgHVACCfgTemplateTable that does not in turn have a reference (bldgHVACCfgTemplateInfo) to an entry in the bldgHVACCfgTemplateInfoTable. The benefit of this approach is that all configuration information is available in one table whether all elements in the system are derived from configured templates or not.
bldgHVACCfgTemplate OBJECT-TYPEの構文Unsigned32 MAX-ACCESSリード作成ステータス現在の説明「『bldgHVACCfgTemplateTable』のエントリのインデックス（bldgHVACCfgTemplateIndexインスタンス）。参照bldgHVACCfgTable行インスタンスは説明した構成を示し既製の構成の 『テンプレート』でありますbldgHVACCfgTemplateInfoDescrオブジェクトで。全ての構成が定義されたテンプレートの下であろうことに留意されたい。その結果、このbldgHVACTableの行が順次内のエントリへの参照（bldgHVACCfgTemplateInfo）を有していないbldgHVACCfgTemplateTable内のエントリを指すことbldgHVACCfgTemplateInfoTable。このアプローチの利点は、すべての設定情報は、システム内のすべての要素が構成テンプレートから派生しているか否かのテーブルで利用可能であることです。
Where the instance value for this colunmar object
is zero, this row represents data for an office
whose HVAC status can be monitored using the
read-only columnar object instances of this
row, but is not under the configuration control of the agent."
::= { bldgHVACEntry 3 }
bldgHVACFanSpeed OBJECT-TYPE
SYNTAX Gauge32
UNITS "revolutions per minute"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Shows the revolutions per minute of the fan. Fan speed
will vary based on the difference between
bldgHVACCfgTemplateDesiredTemp and bldgHVACCurrentTemp. The
speed is measured in revolutions of the fan blade per minute."
::= { bldgHVACEntry 4 }
bldgHVACCurrentTemp OBJECT-TYPE
SYNTAX Gauge32
UNITS "degrees in celsius"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current measured temperature in the office. Should
the current temperature be measured at a value of less
than zero degrees celsius, a read of the instance
for this object will return a value of zero."
::= { bldgHVACEntry 5 }
bldgHVACCoolOrHeatMins OBJECT-TYPE
SYNTAX Counter32
UNITS "minutes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of heating or cooling minutes that have
been consumed since the row was activated. Notice that
whether the minutes represent heating or cooling is a
function of the configuration of this row. If the system
is re-initialized from a cooling to heating function or
vice versa, then the counter would start over again. This
effect is similar to a reconfiguration of some network
interface cards. When parameters that impact
configuration are changed, the subsystem must be
re-initialized. Discontinuities in the value of this counter
can occur at re-initialization of the management system,
and at other times as indicated by the value of
bldgHVACDiscontinuityTime."
::= { bldgHVACEntry 6 }
bldgHVACDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at which
any heating or cooling operation for the office designated
by this row instance experienced a discontinuity. If
no such discontinuities have occurred since the last re-
initialization of the this row, then this object contains a
zero value."
::= { bldgHVACEntry 7 }
bldgHVACOwner OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the operator/system that
last modified this entry. When a new entry
is created, a valid SnmpAdminString must
be supplied. If, on the other hand, this
entry is populated by the agent 'discovering'
unconfigured rooms, the empty string is a valid
value for this object."
::= { bldgHVACEntry 8 }
bldgHVACStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The persistence of this row of the table in system storage,
as it pertains to permanence across system resets. A columnar
instance of this object with value 'permanent' need not allow
write-access to any of the columnar object instances in the
containing row."
::= { bldgHVACEntry 9 }
bldgHVACStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Controls and reflects the creation and activation status of a row in this table.
bldgHVACStatus OBJECT-TYPE構文RowStatus MAX-ACCESSステータス現在の説明「コントロールの作成、読み取りおよびこのテーブルの行の作成および活性化状態を反映します。
No attempt to modify a row columnar object instance value in the bldgHVACTable should be issued while the value of
bldgHVACStatus is active(1). Should an agent receive a SET
PDU attempting such a modification in this state, an
inconsistentValue error should be returned as a result of
the SET attempt."
::= { bldgHVACEntry 10 }
--
-- HVAC Configuration Template Table
--
bldgHVACCfgTemplateInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF BldgHVACCfgTemplateInfoEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides unique string identification for HVAC templates in a network. If it were necessary to configure rooms to deliver a particular quality of climate control with regard to cooling or heating, the index string of a row in this table could be the template name. The bldgHVACCfgCfgTemplateInfoDescription contains a brief description of the template service objective such as: provides summer cooling settings for executive offices. The bldgHVACCfgTemplateInfo in the bldgHVACCfgTemplateTable will contain the pointer to the relevant row in this table if it is intended that items that point to a row in the bldgHVACCfgTemplateInfoTable be identifiable as being under template control though this mechanism."
BldgHVACCfgTemplateInfoEntry MAX-ACCESSステータス現在の説明のbldgHVACCfgTemplateInfoTable OBJECT-TYPE構文配列は「この表は、ネットワーク内のHVACテンプレートの一意の文字列の識別を提供します。それは、冷却に関しては、気候制御の特定の品質を提供するために部屋を構成するために必要であった場合または加熱、この表の列のインデックス文字列は、テンプレート名である可能性がありbldgHVACCfgCfgTemplateInfoDescriptionは客観テンプレートサービスの簡単な説明が含まれているなど：。bldgHVACCfgTemplateTableでbldgHVACCfgTemplateInfoはへのポインタが含まれています役員室用の夏の冷房設定を提供します。この表の該当する行にはbldgHVACCfgTemplateInfoTableの行を指す項目がこの機構しかしテンプレート制御下にあるとして識別することが意図されている場合。」
::= { bldgHVACObjects 2 }
bldgHVACCfgTemplateInfoEntry OBJECT-TYPE
SYNTAX BldgHVACCfgTemplateInfoEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each row represents a particular template and
description. A given row instance can be created or
deleted by set operations upon its
bldgHVACCfgTemplateInfoStatus columnar object
instance."
INDEX { bldgHVACCfgTemplateInfoIndex }
::= { bldgHVACCfgTemplateInfoTable 1 }
BldgHVACCfgTemplateInfoEntry ::= SEQUENCE {
bldgHVACCfgTemplateInfoIndex Unsigned32,
bldgHVACCfgTemplateInfoID SnmpAdminString, bldgHVACCfgTemplateInfoDescr SnmpAdminString,
bldgHVACCfgTemplateInfoOwner SnmpAdminString,
bldgHVACCfgTemplateInfoStatus RowStatus,
bldgHVACCfgTemplateInfoStorType StorageType
}
bldgHVACCfgTemplateInfoIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index to a row in this table."
::= { bldgHVACCfgTemplateInfoEntry 1 }
bldgHVACCfgTemplateInfoID OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Textual identifier for this table row, and, consequently
the template. This should be a unique name within
an administrative domain for a particular template so that
all systems in a network that are under the same template
can have the same 'handle' (e.g., 'Executive Offices',
'Lobby Areas')."
::= { bldgHVACCfgTemplateInfoEntry 2 }
bldgHVACCfgTemplateInfoDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A general description of the template. One example might
be - Controls the cooling for offices on higher floors
during the summer."
::= { bldgHVACCfgTemplateInfoEntry 3 }
bldgHVACCfgTemplateInfoOwner OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the operator/system that last modified
this entry."
::= { bldgHVACCfgTemplateInfoEntry 4 }
bldgHVACCfgTemplateInfoStatus OBJECT-TYPE
bldgHVACCfgTemplateInfoStatusのOBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The activation status of this row.
No attempt to modify a row columnar object instance value in
the bldgHVACCfgTemplateInfo Table should be issued while the
value of bldgHVACCfgTemplateInfoStatus is active(1).
Should an agent receive a SET PDU attempting such a modification
in this state, an inconsistentValue error should be returned as
a result of the SET attempt."
::= { bldgHVACCfgTemplateInfoEntry 5 }
bldgHVACCfgTemplateInfoStorType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The persistence of this row of the table in system storage,
as it pertains to permanence across system resets. A columnar
instance of this object with value 'permanent' need not allow
write-access to any of the columnar object instances in the
containing row."
::= { bldgHVACCfgTemplateInfoEntry 6 }
--
-- HVAC Configuration Template Table
--
bldgHVACCfgTemplateTable OBJECT-TYPE
SYNTAX SEQUENCE OF BldgHVACCfgTemplateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains the templates, which
can be used to set defaults that will
be applied to specific offices. The application
of those values is accomplished by having a row
instance of the bldgHVACTable reference a row of
this table (by the value of the former's
bldgHVACCfgTemplate columnar instance). Identifying
information concerning a row instance of this table
can be found in the columnar data of the row instance
of the bldgHVACCfgTemplateInfoTable entry referenced
by the bldgHVACCfgTemplateInfo columnar object of
this table."
::= { bldgHVACObjects 3 }
bldgHVACCfgTemplateEntry OBJECT-TYPE SYNTAX BldgHVACCfgTemplateEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row represents a single set of template parameters that can be applied to selected instances - in this case offices. These policies will be turned on and off by the policy module through its scheduling facilities.
bldgHVACCfgTemplateEntry OBJECT-TYPE構文BldgHVACCfgTemplateEntry MAX-ACCESSステータス現在の説明は「各行が選択されたインスタンスに適用することができるテンプレートパラメータの単一のセット - を表す。この場合、オフィス内にこれらのポリシーは、ポリシーモジュールによってオン・オフしますそのスケジューリング機能による。
A given row instance can be created or
deleted by set operations upon its
bldgHVACCfgTemplateStatus columnar object instance."
INDEX { bldgHVACCfgTemplateIndex }
::= { bldgHVACCfgTemplateTable 1 }
BldgHVACCfgTemplateEntry ::= SEQUENCE {
bldgHVACCfgTemplateIndex Unsigned32,
bldgHVACCfgTemplateDesiredTemp Gauge32,
bldgHVACCfgTemplateCoolOrHeat BldgHvacOperation,
bldgHVACCfgTemplateInfo Unsigned32,
bldgHVACCfgTemplateOwner SnmpAdminString,
bldgHVACCfgTemplateStorage StorageType,
bldgHVACCfgTemplateStatus RowStatus
}
bldgHVACCfgTemplateIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique value for each defined template in this
table. This value can be referenced as a row index
by any MIB module that needs access to this information.
The bldgHVACCfgTemplate will point to entries in this
table."
::= { bldgHVACCfgTemplateEntry 1 }
bldgHVACCfgTemplateDesiredTemp OBJECT-TYPE
SYNTAX Gauge32
UNITS "degrees in celsius"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is the desired temperature setting. It might be
changed at different times of the day or based on
seasonal conditions. It is permitted to change this value
by first moving the row to an inactive state, making the change and then reactivating the row."
::= { bldgHVACCfgTemplateEntry 2 }
bldgHVACCfgTemplateCoolOrHeat OBJECT-TYPE
SYNTAX BldgHvacOperation
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This controls the heating and cooling mechanism and is
set-able by building maintenance. It is permitted to
change this value by first moving the row to an inactive
state, making the change and then reactivating the row."
::= { bldgHVACCfgTemplateEntry 3 }
bldgHVACCfgTemplateInfo OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object points to a row in the
bldgHVACCfgTemplateInfoTable. This controls the
heating and cooling mechanism and is set-able by
building maintenance. It is permissible to change
this value by first moving the row to an inactive
state, making the change and then reactivating
the row. A value of zero means that this entry
is not associated with a named template found
in the bldgHVACCfgTemplateInfoTable."
::= { bldgHVACCfgTemplateEntry 4 }
bldgHVACCfgTemplateOwner OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The identity of the administrative entity
that created this row of the table."
::= { bldgHVACCfgTemplateEntry 5 }
bldgHVACCfgTemplateStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The persistence of this row of the table across system resets. A columnar instance of this object with value 'permanent' need not allow write-access to any of the columnar object instances in the containing row."
bldgHVACCfgTemplateStorage OBJECT-TYPE SYNTAX StorageType MAX-ACCESSはリード作成ステータス現在の説明「システムリセット後にテーブルのこの行の永続性をこのオブジェクトの柱状インスタンス値に 『永久的な』は、柱状のいずれかへの書き込みアクセスを許可する必要はありません含む行のオブジェクトインスタンス。」
::= { bldgHVACCfgTemplateEntry 6 }
bldgHVACCfgTemplateStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The activation status of this row of the table.
bldgHVACCfgTemplateStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSリード作成ステータス現在の説明は「テーブルのこの行の活性化状態を。
No attempt to modify a row columnar object instance value in
the bldgHVACCfgTemplateTable should be issued while the
value of bldgHVACCfgTemplateStatus is active(1).
Should an agent receive a SET PDU attempting such a modification
in this state, an inconsistentValue error should be returned as
a result of the SET attempt."
::= { bldgHVACCfgTemplateEntry 7 }
-- -- Conformance Information --
- - 適合情報 -
bldgCompliances OBJECT IDENTIFIER ::= { bldgConformance 1 }
bldgGroups OBJECT IDENTIFIER ::= { bldgConformance 2 }
-- Compliance Statements
- コンプライアンスステートメント
bldgCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The requirements for conformance to the BLDG-HVAC-MIB. The bldgHVACObjects group must be implemented to conform to the BLDG-HVAC-MIB." MODULE -- this module
bldgCompliance MODULE-COMPLIANCEステータス現在の説明「BLDG-HVAC-MIBに適合性のための要件。bldgHVACObjects基はBLDG-HVAC-MIBに適合するように実装する必要があります。」 MODULE - このモジュール
GROUP bldgHVACObjectsGroup
DESCRIPTION
"The bldgHVACObjects is mandatory for all systems that
support HVAC systems."
::= { bldgCompliances 1 }
bldgHVACObjectsGroup OBJECT-GROUP
OBJECTS {
bldgHVACCfgTemplate,
bldgHVACFanSpeed, bldgHVACCurrentTemp,
bldgHVACCoolOrHeatMins, bldgHVACDiscontinuityTime,
bldgHVACOwner, bldgHVACStatus,
bldgHVACStorageType, bldgHVACCfgTemplateInfoID,
bldgHVACCfgTemplateInfoDescr, bldgHVACCfgTemplateInfoOwner, bldgHVACCfgTemplateInfoStatus,
bldgHVACCfgTemplateInfoStorType,
bldgHVACCfgTemplateDesiredTemp,
bldgHVACCfgTemplateCoolOrHeat,
bldgHVACCfgTemplateInfo,
bldgHVACCfgTemplateOwner,bldgHVACCfgTemplateStorage,
bldgHVACCfgTemplateStatus
}
STATUS current
DESCRIPTION
"The bldgHVACObjects Group."
::= { bldgGroups 1 }
END
終わり
The primary purpose of the example "HVAC" MIB module is to show how to construct a single module that includes configuration, template, counter and state information in a single module. If this were a 'real' module we would also have included definitions for notifications for the configuration change operations as previously described. We also would have included notifications for faults and other counter threshold events.
例えば、「HVAC」MIBモジュールの主な目的は、単一のモジュール構成、テンプレート、カウンタ及び状態情報を含む単一モジュールを構築する方法を示すことです。これは「実際の」モジュールであれば、前述のように、我々はまた、構成変更操作のための通知の定義が含まれているだろう。また、障害や他のカウンタしきい値イベントの通知が含まれているでしょう。
Implementation and Instance Extensions:
実装とインスタンスの拡張機能：
Just as with networking technologies, vendors may wish to add extensions that can distinguish their products from the competition. If an HVAC vendor also wanted to support humidity control, they could add that facility to their equipment and use AUGMENTS for the bldgHVACTemplateTable with two objects, one that indicates the desired humidity and the other, the actual. The bldgHVACTemplateTable could also be extended using this same approach so that HVAC policies could easily be extended to support this vendor.
ただ、ネットワーク技術と同様に、ベンダーは競争から自社製品を区別できる拡張子を追加したい場合があります。 HVACベンダーも湿度制御をサポートしたい場合、彼らは彼らの機器にその機能を追加することができますし、使用は、2つのオブジェクト、希望の湿度およびその他を示す1、実際にbldgHVACTemplateTableのために強化します。 HVACポリシーが簡単にこのベンダーをサポートするように拡張することができるようにbldgHVACTemplateTableも、これと同じアプローチを使用して拡張することができます。
The following two examples use two templates to configure the temperature in executive offices and in conference rooms. The "conference rooms" template is applied to all conference rooms (which happen to be office 104 on each floor), and the "executive offices" template is applied to executive offices.
次の2つの例は、役員室で、会議室の温度を設定するには、2つのテンプレートを使用します。 「会議室」テンプレートには、（各フロアのオフィス104に起こる）すべての会議室に適用され、「役員室」テンプレートは、役員室に適用されます。
If offices 24, 25, and 26 on the third floor are executive offices, the values in the bldgHVACTable might be:
三階のオフィス24、25、および26は役員室であれば、bldgHVACTableの値は次のようになります。
bldgHVACCfgTemplate.3.24 = 2 bldgHVACFanSpeed.3.24 = 2989 bldgHVACCurrentTemp.3.24 = 24 bldgHVACCoolOrHeatMins.3.24 = 123 bldgHVACDiscontinuityTime.3.24 = sysUpTime + 12h + 21m bldgHVACOwner.3.24 = "policy engine" bldgHVACStorageType.3.24 = nonVolatile(3) bldgHVACStatus.3.24 = active(1)
bldgHVACCfgTemplate.3.24 = 2 bldgHVACFanSpeed.3.24 = 2989 bldgHVACCurrentTemp.3.24 = 24 bldgHVACCoolOrHeatMins.3.24 = 123 bldgHVACDiscontinuityTime.3.24 =のsysUpTime + 12H + 21メートルbldgHVACOwner.3.24 = "ポリシーエンジン" bldgHVACStorageType.3.24 =不揮発性（3）bldgHVACStatus.3.24 =アクティブ（1）
bldgHVACCfgTemplate.3.25 = 2 bldgHVACFanSpeed.3.25 = 0 bldgHVACCurrentTemp.3.25 = 22 bldgHVACCoolOrHeatMins.3.25 = 298 bldgHVACDiscontinuityTime.3.25 = sysUpTime + 4h + 2m bldgHVACOwner.3.25 = "policy engine" bldgHVACStorageType.3.25 = nonVolatile(3) bldgHVACStatus.3.25 = active(1)
bldgHVACCfgTemplate.3.25 = 2 bldgHVACFanSpeed.3.25 = 0 bldgHVACCurrentTemp.3.25 = 22 bldgHVACCoolOrHeatMins.3.25 = 298 bldgHVACDiscontinuityTime.3.25 =のsysUpTime + 4H + 2メートルbldgHVACOwner.3.25 = "ポリシーエンジン" bldgHVACStorageType.3.25 =不揮発性（3）bldgHVACStatus.3.25 =アクティブ（1）
bldgHVACCfgTemplate.3.26 = 2 bldgHVACFanSpeed.3.26 = 0 bldgHVACCurrentTemp.3.26 = 22 bldgHVACCoolOrHeatMins.3.26 = 982 bldgHVACOwner.3.26 = "policy engine" bldgHVACStorageType.3.26 = nonVolatile(3) bldgHVACStatus.3.26 = active(1)
bldgHVACCfgTemplate.3.26 = 2 bldgHVACFanSpeed.3.26 = 0 bldgHVACCurrentTemp.3.26 = 22 bldgHVACCoolOrHeatMins.3.26 = 982 bldgHVACOwner.3.26 = "ポリシーエンジン" bldgHVACStorageType.3.26 =不揮発性（3）bldgHVACStatus.3.26 =アクティブ（1）
The second entry in the bldgHVACCfgTemplateTable, to which all of the above point, might have the following configuration:
bldgHVACCfgTemplateTableの2番目のエントリは、上記の点をすべてこれに、以下の構成を持っているかもしれません。
bldgHVACCfgTemplateDesiredTemp.2 = 22 bldgHVACCfgTemplateCoolOrHeat.2 = cool(2) bldgHVACCfgTemplateInfo.2 = 2 bldgHVACCfgTemplateOwner.2 = "Senior Executive assistant" bldgHVACCfgTemplateStorage.2 = nonVolatile(3) bldgHVACCfgTemplateStatus.2 = active(1) and the associated template information ("executive offices") might be:
bldgHVACCfgTemplateDesiredTemp.2 = 22 bldgHVACCfgTemplateCoolOrHeat.2 =クール（2）bldgHVACCfgTemplateInfo.2 = 2 bldgHVACCfgTemplateOwner.2 = "シニア・エグゼクティブ・アシスタント" bldgHVACCfgTemplateStorage.2 =不揮発性（3）bldgHVACCfgTemplateStatus.2 =アクティブ（1）と関連したテンプレート情報（」役員室」）は次のようになります。
bldgHVACCfgTemplateInfoID.2 = "executive offices" bldgHVACCfgTemplateInfoDescr.2 = "Controls temperature for executive offices" bldgHVACCfgTemplateInfoOwner.2 = "Senior Executive assistant" bldgHVACCfgTemplateInfoStorType.2 = nonVolatile(3) bldgHVACCfgTemplateInfoStatus.2 = active(1)
bldgHVACCfgTemplateInfoID.2 = "エグゼクティブオフィス" bldgHVACCfgTemplateInfoDescr.2 = "エグゼクティブオフィスの温度を制御する" bldgHVACCfgTemplateInfoOwner.2 = "シニア・エグゼクティブ・アシスタント" bldgHVACCfgTemplateInfoStorType.2 =不揮発性（3）bldgHVACCfgTemplateInfoStatus.2 =アクティブ（1）
The policy engine can now associate instances of executive offices with the template called "executive offices" and apply the values in the second entry of the bldgHVACCfgTemplateTable to each of the instances of the executive offices. This will then attempt to set the temperature in executive offices to 22 degrees celsius.
ポリシーエンジンは現在、「エグゼクティブ・オフィス」と呼ばれるテンプレートを役員室のインスタンスを関連付け、役員室のインスタンスのそれぞれにbldgHVACCfgTemplateTableの2番目のエントリに値を適用することができます。これは、その後、22℃に役員室の温度を設定しようとします。
It is also possible that there may be an office configured for a particular temperature, but without using a template. For example, office 28 on the third floor might look like this:
しかし、テンプレートを使用せずに、特定の温度のために構成オフィスが存在し得ることも可能です。例えば、第3階のオフィス28は次のようになります。
bldgHVACCfgTemplate.3.28 = 3 bldgHVACFanSpeed.3.28 = 50 bldgHVACCurrentTemp.3.28 = 26 bldgHVACCoolOrHeatMins.3.28 = 0 bldgHVACDiscontinuityTime.3.28 = 0 bldgHVACOwner.3.28 = "Executive with poor circulation" bldgHVACStorageType.3.28 = nonVolatile(3) bldgHVACStatus.3.28 = active(1)
bldgHVACCfgTemplate.3.28 = 3 bldgHVACFanSpeed.3.28 = 50 bldgHVACCurrentTemp.3.28 = 26 bldgHVACCoolOrHeatMins.3.28 = 0 bldgHVACDiscontinuityTime.3.28 = 0 bldgHVACOwner.3.28 = "冷え性エグゼクティブ" bldgHVACStorageType.3.28 =不揮発性（3）bldgHVACStatus.3.28 =アクティブ（1 ）
The entry in the bldgHVACCfgTemplateTable (to which bldgHVACCfgTemplate.3.28 points) might instead look like:
bldgHVACCfgTemplateTableのエントリ（そのbldgHVACCfgTemplate.3.28ポイントに）代わりに次のようになります。
bldgHVACCfgTemplateDesiredTemp.3 = 28 bldgHVACCfgTemplateCoolOrHeat.3 = cool(2) bldgHVACCfgTemplateInfo.3 = 0.0 bldgHVACCfgTemplateOwner.3 = "Executive with poor circulation" bldgHVACCfgTemplateStorage.3 = nonVolatile(3) bldgHVACCfgTemplateStatus.3 = active(1)
bldgHVACCfgTemplateDesiredTemp.3 = 28 bldgHVACCfgTemplateCoolOrHeat.3 =クール（2）bldgHVACCfgTemplateInfo.3 = 0.0 bldgHVACCfgTemplateOwner.3 = "エグゼクティブ冷え性と" bldgHVACCfgTemplateStorage.3 =不揮発性（3）bldgHVACCfgTemplateStatus.3 =アクティブ（1）
Note that this entry does not point to a template.
このエントリは、テンプレートを指していないことに注意してください。
If the executive's circulation improves so that the temperature should be aligned with other executive offices, this is accomplished by changing the value of bldgHVACCfgTemplate.3.28 from bldgHVACCfgTemplateInfoID.3 to bldgHVACCfgTemplateInfoID.2 (shown above).
温度は、他の役員室に整列されなければならないように、幹部の循環が改善されるかどうか、これがbldgHVACCfgTemplateInfoID.2（上図）にbldgHVACCfgTemplateInfoID.3からbldgHVACCfgTemplate.3.28の値を変更することによって達成されます。
Finally, there might be offices for which there is no configured temperature but management applications can read the current temperature, fan speed, and cooling or heating minutes from the bldgHVACTable. In that case, the value of bldgHVACCfgTemplate will be a zero index ("null"), as will the value of bldgHVACOwner.
最後に、bldgHVACTableからのNO現在の温度を読み取ることができ、温度が、管理アプリケーションが設定されているオフィス、ファン速度、及び冷却または加熱分があるかもしれません。 bldgHVACOwnerの値がするように、その場合には、bldgHVACCfgTemplateの値は、ゼロインデックス（「NULL」）であろう。
bldgHVACCfgTemplate.4.2 = 0 bldgHVACFanSpeed.3.28 = 50 bldgHVACCurrentTemp.3.28 = 26 bldgHVACCoolOrHeatMins.3.28 = 0 bldgHVACDiscontinuityTime.3.28 = 0 bldgHVACOwner.3.28 = "" bldgHVACStorageType.3.28 = nonVolatile(3) bldgHVACStatus.3.28 = active(1)
bldgHVACCfgTemplate.4.2 = 0 bldgHVACFanSpeed.3.28 = 50 bldgHVACCurrentTemp.3.28 = 26 bldgHVACCoolOrHeatMins.3.28 = 0 bldgHVACDiscontinuityTime.3.28 = 0 bldgHVACOwner.3.28 = "" bldgHVACStorageType.3.28 =不揮発性（3）bldgHVACStatus.3.28 =アクティブ（1）
As a second example, the conference rooms on several floors are configured using the "conference rooms" template. When the values in the bldgHVACTable pertaining to conference rooms are read, it might look like:
第2の例として、いくつかの階の会議室には、「会議室」テンプレートを使用して構成されています。部屋を会議に関連するbldgHVACTableの値が読み込まれると、それは次のようになります。
bldgHVACCfgTemplate.12.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.12.104 = 1423 bldgHVACCurrentTemp.12.104 = 21 bldgHVACCoolOrHeatMins.12.104 = 2193 bldgHVACDiscontinuityTime.12.104 = sysUpTime + 36h + 15m bldgHVACOwner.12.104 = = "Bob the Conference Guy" bldgHVACStorageType.12.104 = nonVolatile(3) bldgHVACStatus.12.104 = active(1)
bldgHVACCfgTemplate.12.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.12.104 = 1423 bldgHVACCurrentTemp.12.104 = 21 bldgHVACCoolOrHeatMins.12.104 = 2193 bldgHVACDiscontinuityTime.12.104 =のsysUpTime + 36H + 15メートルbldgHVACOwner.12.104 = = "ボブ会議ガイ" bldgHVACStorageType.12.104 =不揮発性（3） （1）アクティブbldgHVACStatus.12.104 =
bldgHVACCfgTemplate.14.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.14.104 = 1203 bldgHVACCurrentTemp.14.104 = 20 bldgHVACCoolOrHeatMins.14.104 = 293 bldgHVACDiscontinuityTime.14.104 = sysUpTime + 5h + 54m bldgHVACOwner.14.104 = = "Bob the Conference Guy" bldgHVACStorageType.14.104 = nonVolatile(3) bldgHVACStatus.14.104 = active(1)
bldgHVACCfgTemplate.14.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.14.104 = 1203 bldgHVACCurrentTemp.14.104 = 20 bldgHVACCoolOrHeatMins.14.104 = 293 bldgHVACDiscontinuityTime.14.104 =のsysUpTime + 5H + 54メートルbldgHVACOwner.14.104 = = "ボブ会議ガイ" bldgHVACStorageType.14.104 =不揮発性（3） （1）アクティブbldgHVACStatus.14.104 =
bldgHVACCfgTemplate.15.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.15.104 = 12 bldgHVACCurrentTemp.15.104 = 19 bldgHVACCoolOrHeatMins.15.104 = 1123 bldgHVACDiscontinuityTime.15.103 = sysUpTime + 2d + 2h + 7m bldgHVACOwner.15.104 = = "Bob the Conference Guy" bldgHVACStorageType.15.104 = nonVolatile(3) bldgHVACStatus.15.104 = active(1)
bldgHVACCfgTemplate.15.104 = bldgHVACCfgTemplateDesiredTemp.1 bldgHVACFanSpeed.15.104 = 12 bldgHVACCurrentTemp.15.104 = 19 bldgHVACCoolOrHeatMins.15.104 = 1123 bldgHVACDiscontinuityTime.15.103 =のsysUpTime + 2D + 2H + 7メートルbldgHVACOwner.15.104 = = "ボブ会議ガイ" bldgHVACStorageType.15.104 =不揮発性（ 3）bldgHVACStatus.15.104 =アクティブ（1）
The desired temperature and whether to heat or cool is configured in the first entry of the bldgHVACCfgTemplateTable, which tries to set the temperature to 19 degrees celsius in conference rooms:
所望の温度及び加熱又は冷却するかどうかは、会議室で19℃に温度を設定しようとbldgHVACCfgTemplateTableの最初のエントリで構成されています。
bldgHVACCfgTemplateDesiredTemp.1 = 19 bldgHVACCfgTemplateCoolOrHeat.1 = cool(2) bldgHVACCfgTemplateInfo.1 = bldgHVACCfgTemplateInfoID.1 bldgHVACCfgTemplateOwner.1 = "Bob the Conference Guy" bldgHVACCfgTemplateStorage.1 = nonVolatile(3) bldgHVACCfgTemplateStatus.1 = active(1)
bldgHVACCfgTemplateDesiredTemp.1 = 19 bldgHVACCfgTemplateCoolOrHeat.1 =クール（2）bldgHVACCfgTemplateInfo.1 = bldgHVACCfgTemplateInfoID.1 bldgHVACCfgTemplateOwner.1 = "ボブ会議ガイ" bldgHVACCfgTemplateStorage.1 =不揮発性（3）bldgHVACCfgTemplateStatus.1 =アクティブ（1）
The associated template information would then have:
関連するテンプレート情報は、必要があります：
bldgHVACCfgTemplateInfoID.1 = "conference rooms" bldgHVACCfgTemplateInfoDescr.1 = "Controls temperature in conference rooms" bldgHVACCfgTemplateInfoOwner.1 = "Bob the Conference Guy" bldgHVACCfgTemplateInfoStorType.1 = nonVolatile(3) bldgHVACCfgTemplateInfoStatus.1 = active(1)
bldgHVACCfgTemplateInfoID.1 = "会議室" がbldgHVACCfgTemplateInfoDescr.1 =は "会議室の温度を制御し、" bldgHVACCfgTemplateInfoOwner.1 = "ボブ会議ガイ" bldgHVACCfgTemplateInfoStorType.1 =不揮発性（3）bldgHVACCfgTemplateInfoStatus.1 =アクティブ（1）
The policy system can then apply this template (cool to 19 degrees Celsius) to its notion of all of the conference rooms in the building.
政策システムは、ビル内の会議室のすべてのその概念に（19℃に冷却）このテンプレートを適用することができます。
This document discusses practices and methods for using the SNMP for management and distribution of configuration information for network elements. Any effective use of the SNMP in this application must concern itself with issues of authentication of the management entities initiating configuration change and management, in addition to the integrity of the configuration data itself. Other more subtle considerations also exist.
この文書では、ネットワーク要素の管理および構成情報の配信のためにSNMPを使用するためのプラクティスおよび方法を論じています。このアプリケーションのSNMPのいずれかの効果的な使用は、構成データそのものの整合性に加えて、設定変更や管理を開始する管理エンティティの認証の問題を自分自身を懸念しなければなりません。他のより微妙な考慮事項も存在します。
To that end, the section of this document entitled "Deployment and Security Issues" covers these security considerations to the extent they affect the current practices described throughout this document. In particular, in the subsection entitled "Secure Agent Considerations", there is a recommendation for the usage of Version 3 of the SNMP, and its essential presumption as a foundation for other practices described throughout. With the exception of a small number of cases where a mention is made to the contrary to illustrate techniques for coexistence with application entities dependent upon earlier versions of the SNMP, that recommendation of usage of Version 3 of the SNMP is reiterated here.
そのために、「展開とセキュリティの問題」と題されたこの文書のセクションでは、彼らは、この文書全体で説明した電流の慣行に影響を与える程度まで、これらのセキュリティ上の考慮事項をカバーしています。具体的には、「エージェントの考慮事項セキュア」と題するサブセクションで、SNMPのバージョン3の使用方法、および全体で説明した他の実践のための基盤として、その本質的な推定のための推奨事項があります。言及はSNMP、ここでは繰り返されるSNMPのバージョン3の使用の勧告の以前のバージョンに依存したアプリケーションエンティティとの共存のための技術を説明するために、逆に行われる例少数の例外を除いて。
This document was produced by the SNMPCONF Working Group. In particular, the editors wish to thank:
この文書は、SNMPCONFワーキンググループによって作成されました。具体的には、編集者は感謝したいです。
Christopher Anderson Andy Bierman Greg Bruell Dr Jeffrey Case Chris Elliott Joel Halpern Pablo Halpern Wes Hardaker David Harrington Harrie Hazewinkel Thippanna Hongal Bob Moore David T. Perkins Randy Presuhn Dan Romascanu Shawn Routhier Steve Waldbusser Bert Wijnen
クリストファー・アンダーソンアンディBiermanグレッグBruell博士ジェフリーケースクリス・エリオットジョエル・ハルパーンパブロ・ハルパーンウェスHardakerデヴィッドハリントンHarrie Hazewinkel Thippanna Hongalボブ・ムーアデヴィッドT.パーキンスランディPresuhnダンRomascanuショーンRouthierスティーブWaldbusserバートWijnen
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[1]ハリントン、D.、PresuhnとR.とB. Wijnen、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[2] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[3] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[4] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[4] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2580、1999年4月 "SMIv2のための順応文"。
[5] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
[5]、STD 62、RFC 3417、2002年12月Presuhn、R.（編）、 "簡易ネットワーク管理プロトコル（SNMPv2の）のための輸送マッピング"。
[6] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[6]ケース、J.、ハリントンD.、Presuhn R.とB. Wijnenの、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、STD 62、RFC 3412、2002年12月。
[7] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[7]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、STD 62、RFC 3414、2002年12月。
[8] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[8] Presuhn、R.（エド。）、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[9] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol Applications", STD 62, RFC 3413, December 2002.
[9]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコルアプリケーション"、STD 62、RFC 3413、2002年12月。
[10] 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.
[10] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "ビューベースアクセス制御モデル（VACM）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3415、2002年12月。
[11] Presuhn, R. (Ed.), "Management Information Base for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3418, December 2002.
[11] Presuhn、R.（編）、 "簡易ネットワーク管理プロトコル（SNMPv2の）のための管理情報ベース"、STD 62、RFC 3418、2002年12月。
[12] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[12]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[13] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002.
[13]ダニエル、M.、ハーバーマン、B.、Routhier、S.およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 3291、2002年5月。
[14] McCloghrie, K. (Ed.), "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[14] McCloghrie、K.（編）、RFC 2011、1996年11月 "SMIv2のを使用して、インターネットプロトコルのためのSNMPv2管理情報ベース"。
[15] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[15]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月。
[16] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[16]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[17] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[17]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[18] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[18]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[19]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[20] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[21] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.
[21]ブラウン、C.およびF.ベイカー、 "SMIv2のを使用してフレームリレーのDTEのための管理情報ベース"、RFC 2115、1997年9月。
[22] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[22]ベイカー、F.（編）、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[23] Hawkinson, J. and T. Bates, "Guidelines for Creation, Selection, and Registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[23]ホーキンソン、J.およびT.ベイツ、 "作成、選択、および自律システム（AS）の登録のためのガイドライン"、BCP 6、RFC 1930、1996年3月。
[24] Decker, E., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993.
[24]デッカー、E.、Langille、P.、Rijsinghani、A.およびK. McCloghrie、 "ブリッジのための管理オブジェクトの定義"、RFC 1493、1993年7月。
[25] Levi, D. and J. Schoenwaelder "Definitions of Managed Objects for Scheduling Management Operations", RFC 3231, January 2002.
[25]レビとD.とJ. Schoenwaelder "スケジュール管理操作のための管理オブジェクトの定義"、RFC 3231、2002年1月。
[26] Bell, E., Smith, A., Langille, P., Rijsinghani, A. and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", RFC 2674, August 1999.
[26]ベル、E.、スミス、A.、Langille、P.、Rijsinghani、A.およびK. McCloghrie、 "トラフィッククラス、マルチキャストフィルタリングおよび仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義"、RFC 2674、8月1999。
[27] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997.
[27]ベイカー、F.、 "IP転送テーブルMIB"、RFC 2096、1997年1月。
[28] St. Johns, M. (Ed.), "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999.
[28]セントジョンズ、M.（編）、RFC 2670 "MCNS / DOCSIS準拠RFインターフェイスの無線周波数（RF）インターフェースの管理情報ベース"、1999年8月。
[29] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995.
[29]ベイカー、F.とR. Coltun、 "OSPFバージョン2管理情報ベース"、RFC 1850、1995年11月。
[30] Blake, S., Black, D., Carlson M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services ", RFC 2475, December 1998.
[30]ブレイク、S.、ブラック、D.、カールソンM.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[31] 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.
[31]ウィリス、S.、Burruss、J.およびJ.チュウ（編）、RFC 1657、1994年7月 "ボーダーゲートウェイプロトコルのバージョン4（BGP-4）のSMIv2を使用するための管理オブジェクトの定義"。
[32] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000.
[32] Waldbusser、S.、 "管理情報ベースのリモートネットワーク監視"、RFC 2819、2000年5月。
[33] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000.
[33] McCloghrie、K.とG.ハンソン、 "インターフェイスグループMIBへの逆積層テーブル拡張"、RFC 2864、2000年6月。
[34] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, December 1999.
[34] McCloghrie、K.およびA. Bierman、 "エンティティMIB（第2版）"、RFC 2737、1999年12月。
[35] ITU-T,, Recommendation M.3010., PRINCIPLES FOR A TELECOMMUNICATIONS MANAGEMENT NETWORK. February, 2000.
[35] ITU-T ,,勧告M.3010。、電気通信管理ネットワーク原則。 2000年2月。
[36] Waldbusser, S., Saperia, J., and Hongal, T., "Policy Based Management MIB", Work-in-progress.
[36] Waldbusser、S.、Saperia、J.、及びHongal、T.、 "ポリシーベースの管理MIB"、仕掛品。
[37] Heintz, L., "SNMP Row Operations Extensions", Work-in-progress.
[37]ハインツ、L.、「SNMP行の操作拡張機能」、作業中。
[38] Zeltserman, D., "A Practical Guide to Snmpv3 and Network Management", Prentice Hall, 1999.
[38] Zeltserman、D.、プレンティス・ホール、1999年 "SNMPv3のとネットワーク管理の実用ガイド"。
[39] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999.
[39]ノート、M.、シュピーゲル、E.およびK. Tesink、 "テキストの表記法およびATM管理のためのオブジェクトIDの定義"、RFC 2514、1999年2月。
[40] Kassaveri, R., Editor, "Distributed Management Expression MIB", RFC 2982, October 2000.
[40] Kassaveri、R.、エディタ、 "分散管理式MIB"、RFC 2982、2000年10月。
[41] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999.
[41]セントジョンズ、M.、「DOCSIS準拠のケーブルモデムやケーブルモデム終端システムのためのDOCSISケーブルデバイスMIBケーブルデバイス管理情報ベース」、RFC 2669、1999年8月。
[42] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[42] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、およびS. Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[43] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/ 11ed_cr/secur_c/scprt/scacls.pdf.
[43] http://wwww.cisco.com/univercd/cc/td/product/software/ios113ed/ 11ed_cr / secur_c / scprt / scacls.pdf。
[44] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[44] Waldbusser、S.、 "SMIv2のを使用してリモートネットワーク監視管理情報ベースバージョン2"、RFC 2021、1997年1月。
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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Michael R. MacFaden Riverstone Networks, Inc 5200 Great America Parkway Santa Clara, CA 95054
マイケルR. MacFadenリバーストーンネットワークス株式会社5200グレートアメリカパークウェイサンタクララ、CA 95054
EMail: mrm@riverstonenet.com
メールアドレス：mrm@riverstonenet.com
David Partain Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden
デビッドパーテインエリクソンABの私書箱ボックス1248 SE-581 12リンシェーピングスウェーデン
EMail: David.Partain@ericsson.com
メールアドレス：David.Partain@ericsson.com
Jon Saperia JDS Consulting 174 Chapman Street Watertown, MA 02472
ジョンSaperia JDSコンサルティング174チャップマン・ストリートウォータータウン、MA 02472
EMail: saperia@jdscons.com
メールアドレス：saperia@jdscons.com
Wayne F. Tackabury Gold Wire Technology 411 Waverley Oaks Rd. Waltham, MA 02452
ウェインF. Tackaburyゴールドワイヤーテクノロジー411ウェイバリーオークスRdを。ウォルサム、MA 02452
EMail: wayne@goldwiretech.com
メールアドレス：wayne@goldwiretech.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。