[要約] RFC 3512は、SNMPを使用してネットワークとデバイスを設定するためのガイドラインです。このRFCの目的は、SNMPを使用してネットワーク管理者が効率的にネットワークとデバイスを管理できるようにすることです。
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)
シンプルなネットワーク管理プロトコル（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.
Copyright（c）The Internet Society（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.
このドキュメントは、インターネット標準管理フレームワークとそのプロトコルであるSimple Network Management Protocol（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].
o RFC 3411 [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と呼ばれる2番目のバージョンは、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]で説明されています。プロトコル操作の2番目のセットと関連するPDU形式は、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管理フレームワークのより詳細な紹介は、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.
過去10年間で、SNMPを使用してパブリックおよびプライベートデータネットワークの構成において重要な経験が獲得されています。この間、上記のようにネットワークは大幅に増加しています。この爆発的な成長に対する対応は、ポリシーベースの構成管理の開発でした。ポリシーベースの構成管理は、構成情報がルールとネットワーク全体の目標から導き出され、管理ドメイン全体で一貫したネットワーク動作を達成することを目的として、潜在的に多くのネットワーク要素に配布される方法論です。
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) さまざまなレベルの粒度で柔軟なトランザクション制御を提供します。極端な場合、構成全体が要素に配信およびインストールされる場合があります。または、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.
計画前の構成シーケンスは、構成前のテスト結果がシステムの状態を不安定であることを示している場合に中止できます。大規模システムの2つのセットの変更の意図しない効果をデバッグすることは、テスト終了後の単一セットの効果の分析よりも困難なことが多いことがよくあります。
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スパニングツリーを管理するMIBモジュール（RFC 1493 [24]）は、論理ブリッジごとの安定性を監視するための次のオブジェクトを提供します。
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で説明した原則を促進する手段の良い例です。つまり、構成が変更される前にサブシステムの動作を理解し、同じ手段を使用して、構成変更に続いて適切な操作を再テストおよび検証する必要があります。
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およびOspfifrtrdeadeadInterval [24] Timersが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モジュールの1つである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) オブジェクトの合計（原文）を制限します。
(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モジュールで定義されたオブジェクト記述子（「人間の読み取り可能な名前」）標準MIBモジュールで定義されているオブジェクト識別子[2]）は、すべてのMIBモジュールで一意である必要があります。一般に、定義されたMIBモジュールを参照するのに役立つ各マネージドオブジェクトにプレフィックスが追加されます。たとえば、IF-MIBは、iFtable、ifstacktableなどのオブジェクトタイプの記述子に対して「if」プレフィックスを使用します。
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.
これは、障害、構成、会計、パフォーマンス、セキュリティを含むオブジェクト記述子が組織化された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テキスト条約は、テーブルの概念行の作成、削除、アクティベーション、および非アクティブ化を制御します。テーブルが列の1つとして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.
構成データを多くの柱状オブジェクトに広める必要があるマルチテーブルシナリオでは、1つのテーブルの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) オブジェクトはすべて現在設定する必要があるか、概念的なrowStatusオブジェクトをアクティブに移行するために設定する必要はありません（1）
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:
2) 概念的行のオブジェクトは、RowStatusオブジェクトがアクティブになると変更できません（1）。このようなインスタンスの変更性を制限するため、Rowstatusオブジェクトがアクティブに設定された後（1）、そのような一連のRowstatusには、コミットされた円柱状のインスタンス値に依存するエージェントシステムの副作用があるため、実際には合理的な制限です。ただし、この制限がオブジェクトに存在する場合、次のような説明条項で明確にする必要があります。
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 read-createステータス現在の説明 "プロトコルのカプセル化のテキスト説明。プローブは、カプセル化全体のサブセットのみを記述することを選択できます（例：最高層）。
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 columnarオブジェクトタイプの説明句にも表示されます。
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'.
トランザクション制御に関連する重要な原則は、異なるテーブルでの行の運命共有です。MIBモジュールの2つの概念テーブル（または2つの異なるMIBモジュールのテーブル）の間に関係が指定されている場合を考えてください。これに関連して、運命の共有とは、テーブルの行が削除されると、他のテーブルの対応する行も削除されることを意味します。トランザクションコントロールコンテキストでの運命共有は、非常に大きな構成の変更をアクティブにすると、使用することもできます。構成情報のセットを保持する2つのテーブルがある場合、1つのテーブルの行を「準備ができた」状態に配置する必要がある場合があります。その2番目のテーブルを「準備ができた」状態に配置できる場合、トランザクション全体が「コミット」されたと見なされます。
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.
SNMPテーブルデータの運命共有は、可能な限りSMIインデックス予選の増強を使用して明示的に定義する必要があります。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.
この目的のために、2つのテーブルがそのような方法で関連している場合、関連する行オブジェクトタイプの説明条項がそれぞれのテーブルのエントリの運命共有を定義することにより、このようなあいまいさを避ける必要があります。
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オブジェクトのセマンティクスで定義されているように、すべての保留中のトランザクション（設定操作の結果として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モジュールデザイナーの決定の1つは、実際に意味のある粒度のレベルであることです。たとえば、ルーティングエリアでは、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モジュールの実装が、特定の行のインスタンスを作成するために設定する必要があるオブジェクトによって異なる場合は、Agent-Requersを使用してそのテーブルの追加オブジェクトに名前を付けるためにエージェント機能ステートメントを使用する必要があります。句。
It is useful when configuring new rows to use the notReady status to indicate row activation cannot proceed.
Notreadyステータスを使用するように新しい行を構成して行のアクティベーションが続行できないことを示す場合に役立ちます。
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.
管理アプリケーションが行を作成しようとしている期間中、これらのすべての（および不定期の）柱状オブジェクトインスタンスが設定されていない期間がある場合があります。この時間を通して、エージェントは、これらの必要なインスタンス値がすべて設定されるまで、行の任意のオブジェクトインスタンスを取得するためにnosuchinstanceエラーを返す必要があります。例外は、RowStatusオブジェクトインスタンスであり、この期間中に（3）値を返す必要があります。
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オブジェクトのNot Ready Value Returnのみに関心がある必要があります。MIBモジュールを設計する際に列内構成トランザクションを簡素化する1つのアプローチは、単一のセットPDU内に収まるよりも、柱状オブジェクトのインスタンスデータがないテーブル行を構築することです。この場合、RowStatus ColumnarオブジェクトのCreateAndWait（）値は必要ありません。同じセット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
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.
したがって、エージェントがIfadmintatusにSNMPを設定して行を変更した場合、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を配信するかについての決定は、一般にローカル構成の問題です。ベンダーは、エージェントが応答の有無を使用して再送信する必要があるかどうかを知ることができるため、通知型データにトラップ上の通知の使用を推奨する必要があります。全体として、変化が確認されたエンドツーエンドの配信の可能性が高いように、トラップの代わりに情報を使用することが望ましいです。
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モジュールの設計の問題として、実用的な場合、通知タイプは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」オブジェクトを投票しなければならないことは、うまくスケーリングされません。特定のエージェントの実装で全体的な構成を表すために、グローバルなラストチェンジタイプオブジェクトを提供することを検討してください。
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オブジェクトは大量のデータには不十分です。
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: 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
マネージャーを使用して管理されたデバイスにある構成データの同期を支援するために使用できる3つの設計オプションがあります。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.
- indeger32または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エンティティがIPCIDRROTETABLEで定義されているように、デフォルトのないインターネットルーティングテーブルのコピーを公開している場合、現在約100,000行が含まれます。
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.
連想インデックスはIPCIDRROTETABLEで使用され、たとえば、特定のIPv4宛先192.0.2/24のすべてのルートを取得できます。
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
}
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]、Page 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.
2つの例が続きます。
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.
まず、RFC 2863 [20]およびIFINVSTACKTABLE RFC 2864 [33]で見つかったIfStackTableを検討してください。これらは、補助（インデックス）オブジェクトの順序と単純に逆になるという論理的な同等物です。
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 HostTableとHosttimetableは、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.
HostTableはさらに、MACアドレスの最初の3オクテットである組織的に一意の識別子（OUI）など、コレクションを合理的に検索する機能を提供する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.
HostTimetableは、バルクRMONデータを迅速に転送するために明示的に設計されています。HostControllollastDeleteTimeを提供することにより、削除と挿入に直面して多数の行を収集する方法を示します。
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.
RFC 2021 [44]で定義され、RMON2-MIBおよびQ-BRIDGE-MIB（RFC 2674 [26]）で使用されているタイムフィルターは、特定の期間以降に変更された後に変化した行のみを取得する方法を提供します。。
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 Indexテーブルの1つの欠点は、特定の行が多くの時点で表示される可能性があることです。これにより、標準の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.
転送するデータの量が、Octet文字列の場合のように、現在のSNMP設計制限許可よりも大きい場合（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.
管理されたノード内で実行されているローカルエージェントプロセスがオブジェクトインスタンスのテンプレート（インターフェイスのセットなど）のテンプレートを取り、ノード内のすべての実際のインスタンスに適応および適用できるようにするためのさまざまなアプローチが存在します。これは、ポリシーベースの構成の1つの形式のアーキテクチャです（たとえば[36]を参照）。このようなアーキテクチャは、エージェントとMIBモジュールの一部に設計する必要があり、インスタンスデータの適用をエージェントに配布する実行効率とともに、インスタンスデータの多くのコピーを1回だけ指定する効率を提供します。
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)?
Simple Integer32またはunsigned32を使用してテーブルをインデックス作成する場合は、1つ（1）から始めて、値の最大範囲を指定します。オブジェクト識別子は署名されていない長い値であるため、発生する質問は、1つではなくゼロ（0）からインデックスを付けないのはなぜですか？
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つ（つまり、ゼロからではなく）から番号を付ける必要があります。特別な場合を除き、整数値のインデックスオブジェクトタイプの値としてゼロを使用することは避ける必要があります。インターフェースグループMIBモジュール[33]から次のテキスト条約によって提供される規定を考えてみましょう。
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アドレス（構文iPaddress）をインデックスとして使用する多くのオブジェクトがあります。そのようなテーブルの1つは、RFC 2011 [14] IP-MIBのiPaddrtableです。これにより、MIBモジュールのIPv4への有用性が制限されます。このような制限を回避するには、インターネットプロトコルのアドレスを表す一般的な方法を提供する、アドレス指定のテキストコンベンションINET-ADDRESS-MIB [13]（またはそのMIBモジュールの更新）を使用します。ただし、この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のサブ識別子の制限に問題がある場合があります。この場合、オブジェクトタイプの宣言には「サイズ」節を含める必要があります。潜在的なインスタンスサブ識別子の数を制限します。
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.
Ifadmintatusがテストに設定されている場合（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オブジェクトタイプは、変化に影響を与えるIFADMINTATUSの値がこのオブジェクトの動作に関するより多くの情報を記述した可能性があります。たとえば、Ifadmintatusの各値のそれぞれについて、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.
可能な限り、テキストの規則を使用して、頻繁に繰り返されるデータ型の一貫したセマンティックを作成する必要があります。
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]。たとえば、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つのレベルの持続性があります。最初のケースでは、デバイスに送信された構成データは、後続の構成操作によって変更されるまで変更されるか、システムが再活性化されます。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 Read-Writeを使用した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]として知られるテキスト条約を使用します。
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].
例には、Sntax StorageTypeのスケジュール行オブジェクトSchedStorageTypeのRFC 3231 [25]定義、およびSNMPビューベースのアクセス制御モデルMIB [10]のほぼすべてのテーブルの同様の行オブジェクトが含まれます。
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:
永続性の2番目の方法は、説明句を使用して、インスタンスデータの持続方法を定義するだけです。RFC 2674 [26]は、次のようにDOT1QVLANSTATICANTRYデータの持続性を明示的に定義しています。
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:
現在のプラクティスは、デバイスの初期化で読み取られた不揮発性構成だけでなく、ランタイム構成を変更できるデュアル永続性モデルです。Disman-Schedule-Mibモジュール[25]は、この慣行の例を提供します。スケジュールの行エントリは、エージェントMIB変数インスタンスをある時点で特定の値に設定し、他の制約とディレクティブによって管理できるパラメーターを指定します。それらの1つは次のとおりです。
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]のこのようなオブジェクトの例は、グローバルなOSPFADMINTATです。
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の他の場所では、OSPFADMINTATを有効にするように設定するセマンティクス（2）が明確に綴られています。
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]は、スケジュールされたActions rowインスタンスに対応する統計オブジェクトタイプ（読み取り専用アクセスを含む）とともに、スケジュールされたアクションテーブルの各エントリにそのようなオブジェクトを公開します。
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つの柱状オブジェクトタイプを公開できます。読むと、このオブジェクトタイプのインスタンスは、その最後のセットまたはデフォルトの値を反映します。readのみの最大アクセスを備えたコンパニオンオペレーショナルコラムオブジェクトタイプは、管理柱のインスタンスの最後のセットから生じる活性化または非アクティブ化の現在の状態を提供します。これらの管理および運用上の列インスタンスは、アクティベーションの遅延期間にわたって異なる値を反映する可能性があるため、それらが分離されている理由が完全に期待されています。さらにセクションは、運用と管理の行列を単一のオブジェクトタイプに組み合わせようとすることから生じる可能性のある問題の一部を示しています。
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:
次の例では、SchedAdmintatusはスケジュールされたアクションのアクティブ化を制御し、SchedoperStusはその運用状況について報告します。
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）、Notinservice（2）に設定して無効にしてアクティブにします（1）再び、エージェントがエージェントが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の管理されたオブジェクトSchedadmintatusは、行のアクティベーションから行コントロールを分離する方法を示しています。schedadmintatusを無効にするように設定しても（2）、列がテーブルから老化/削除されることはありません。
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.
最後に、合理的なエージェントの実装では、誤ったアプリケーションによってリソースが使い果たされないように、準備ができていない/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.
次のオブジェクトの微妙な運用上の欠点を考慮してください。どちらも現在の状態を報告し、設定操作が新しい状態に変更されるようにします。
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.
オブジェクトが定義されている場合、次の例は1つの可能なトランザクションを表します。
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.
単一のオブジェクトタイプを使用して両方のタイプの状態を制御および報告する場合、管理および運用状態の混乱と逆説的な相互作用のこの可能性は避けられません。私たちがすでに見た一般的な慣行の1つは、目的の（設定可能な）状態を現在の状態から分離することです。RFC 2863 [20]からのオブジェクトIfadmintatusおよび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操作で2番目の方法を導入できます。これは、ゆるく結合されたサブシステムと相互作用する必要があるエージェントの実装の遅延によって引き起こされます。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のSchedadmintatusの例に示されているように）、単一の操作の一部である場合、節約と活性化の潜在的な遅延は区別できないことに留意してください。
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]に通知タイプのマクロによって説明されているとおりです。通知は、SNMPV2C [19]またはSNMPV3 TRAPまたはInformRequest PDUのいずれかで送信できます。構成情報の感度を考えると、セキュリティ機能が強化されているため、SNMPV3を使用して常に構成操作を実行することをお勧めします。InformRequest PDUの受信者は応答PDUで応答するため、PDUをトラップすることを好みに使用する必要があります。この承認は、実際に再送信が必要な場合に通知型情報の不必要な再送信を回避するために使用できます。InformRequest PDUの使用（トラップとは対照的に）は、MIBモジュール設計者またはエージェントの実装者の制御にありません。トラップまたは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で実行できる構成変更に関する通知型情報の効果的な定義に関するガイダンスを提供します。通知は、ハードウェアの障害から構成および一般的なポリシーエラーへのあらゆる種類のエラーレポートの重要な役割を果たします。これらのタイプの通知は、セクション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.
構成の変更を報告するように設計された通知タイプは、構成変更を開始する管理エンティティのIDを報告する必要があります。具体的には、エンティティがSNMPコマンドジェネレーターであることが知られている場合、RFC 3413 SNMP-Target-MIBの表SNMPTARGETPARAMSTABLEにある輸送アドレスとSNMPパラメーターを、可能であれば報告する必要があります。SNMPドメイン外の構成変更のレポートのために、該当する変更メカニズム（たとえば、CLI対HTTPベースの管理クライアントアクセス）を報告する必要があります。。
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.
新しい通知タイプを設計するときは、構成変更またはエラーイベントに応じて通知型で定義された通知情報で送信される通知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.
InformRequest PDUSは、トラップ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に関係なく、通知の不必要な生成を制限する1つの方法は、送信する必要がない場合に通知タイプの定義状況に含めることです。良い例は、Frame-Relay-Dte-Mib、RFC 2115 [21]で定義されているFRDLCistatUschangeです。
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.
通知型情報の不要な世代を減らすために使用できる他の多くの手法があります。通知を定義するとき、設計者は、通知タイプの特定のインスタンスの生成に関する多くの時間的制限を指定できます。たとえば、定義では、通知の生成につながった条件が続く間、60秒ごとに1回以上メッセージが送信されないことを指定できます。あるいは、通知タイプの説明条項は、通知の送信につながる条件の期間中に送信されるメッセージの数に固定制限を提供できます。
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.
通知タイプの伝送が何らかの方法で「集計」されている場合 - 上記のように時間的または絶対システム状態の変更によって制限されている場合 - 最適な設計手法は、通知を使用してデータを提供することです。通知について。通知タイプの実際の送信を管理するためにどのしきい値が選択されていても、アイデアは、できるだけ少ない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モジュールを追跡する標準トラックモジュールがあります。たとえば、Frame-Relay-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 [9]でSNMP-Notification-MIBモジュールが可用性であるため、このMIBモジュールのフィルタリング関数を使用することを強くお勧めします。このMIBは、指定された通知タイプとその意図した受信者のマッピングを促進します。
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モジュール設計者は、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.
理想的には、特定のセットリクエストに対して「不定」エラーが発生した場合、アプリケーションはエージェントの詳細についてエージェントをクエリすることができます。悪い値は、コマンドジェネレーターが悪いデータを送信したことを必ずしも意味するものではありません。エージェントに障害がある可能性があります。追加の詳細な診断情報は、統合システムの状態の診断に役立つ場合があります。
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:
式が評価されたときに発生するディスマンと発現-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 }
ExperRENTRYオブジェクトタイプの構文experrorentry max-accessアクセス不可能なステータス現在の説明 "式の処理におけるエラーに関する情報。エントリは、このテーブルに表示されます。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モジュールは、行のアクティベーションで発生するエラーに特有のエラー情報を含むログテーブルにColunarオブジェクトタイプを作成することにより、管理されたデバイスのエラーに関する情報を構成アプリケーションに提供できます。
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.
詳細な障害情報オブジェクトを使用した通知を使用して、構成の障害を信号することもできます。このアプローチを使用する場合、構成障害から生成された通知タイプデータの宛先の構成は、他の運用上の理由で生成される他の通知タイプのものとは独立して考慮される必要があります。言い換えれば、多くの管理環境では、構成障害から生成された通知タイプに関心のあるネットワーク演算子は、たとえばネットワークインターフェイスの障害から生成された通知型に関心のあるネットワークオペレーターのコミュニティと完全に重複していない場合があります。
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.
1つ目は、単一のPDU以上にまたがるセットプロトコル操作を発行する2つ以上の認定管理アプリケーション間のレース条件を回避することです。
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モジュール設計者は、Snmpv2-Mibで定義されているように、Snmpsetserialno（グローバルスピンロックオブジェクト）に依存することを選択するか、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オブジェクトタイプの構文testAndincr max-access read-writeステータス現在の説明 "いくつかの協力コマンドジェネレーターアプリケーションが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-Target-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ドメインの外部に定義された構成と区別できるように、異なるエンティティによって設定された設定として設定されたものを報告できる必要があります。セクション3.10.1では、通知タイプを設計する際のこのプラクティスの考慮事項について説明します。RMON-MIB RFC 2819 [32]のオーナートリングテキスト条約は、この目的のために正常に使用されています。最近では、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.
経験によると、所有権を表すための所有者の使用は、有用な診断ツールでもあることが示されています。具体的には、エージェント/ローカル管理によって設定された構成を識別するために文字列「モニター」を使用することは、アプリケーションで一般的で有用です。
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.
第三に、複数のマネージャーが同じテーブルセットを構成する必要があるかどうかを検討してください。その場合、「所有者」をテーブルのインデックスの最初のコンポーネントとして使用して、少なくともセキュリティ名またはグループ名のレベルで、行のサブセットへのアクセスを保護するためにVACMを使用できるようにすることができます。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].
Octet Stringの構文は、設定された操作を可能にする管理されたオブジェクトを定義する際に、非常に柔軟で便利なデータ型として使用できます。オクテットの弦は多くのものをモデル化することができ、SMIV2によって65535オクテットにサイズが制限されています[2]。
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.
このような情報オブジェクトタイプは、「スクラッチパッドオブジェクト」として口語的に知られるようになりました。多くの場合有用ですが、このオブジェクトの値を読み取り、設定できるよりも多くの情報を使用するためにアプリケーションが必要な場合は、Octet文字列の内容のより正確な定義が必要です。このようなオブジェクトは構造化されていません。したがって、オブジェクトタイプをいくつかのオブジェクトタイプ定義に分割すると、必要な追加の構造の詳細を提供できます。
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.
Octet文字列を使用する場合は、プラットフォームに依存するデータ形式を避けてください。また、SNMPADMINSTRINGやBITSなどのより正確なSMI構文が機能するOctet文字列の使用も避けてください。
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:
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オクテット文字列インスタンスエンコードの上限に近い典型的なインスタンスデータ要件があるオブジェクトタイプのインスタンス転送の実際の影響を考慮する必要があります。このようなオブジェクトタイプがまったく必要な場合、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モジュールは、基礎となるプロトコルとその管理フレームワークの複数の「プロセス」に対応できるルーティングプロトコルのMIBSなど、多くの関係を想定しています。ただし、MIBモジュールの大部分は、MIBモジュールで見つかったオブジェクトと、特定のSNMPエージェントに存在するインスタンスの数との間に1対1の関係を想定しています。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.
そのような場合、エンティティ-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リクエストを発行することはできません。たとえば、単一のエージェントでアクティブなブリッジ-MIBの2つのインスタンスを考慮して、1つのPDUには、最初と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コンテキストによってscopeすることができます。ただし、これには、構成されたエージェントシステム内のコンテキストの管理的確立とこの手法の調整が必要です。
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.
read-create、read-write、およびreadのみのセマンティクス用の整数ベースのオブジェクトを定義する場合、単位節を使用して、ユニットの解釈方法の特定の詳細の説明条項の仕様に加えて推奨されます。
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.
参照条項は、実装者が特定のオブジェクト上の関連情報を追跡するのを支援する方法としても推奨されます。特定の基礎となるテクノロジードキュメントに参照句を追加することにより、複数の個別の実装が相互運用する可能性が高くなります。
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設計における現在の慣行は、設定可能なオブジェクトの慣習性を考慮することです。iDempotencyは、基本的に同じセット操作を繰り返し呼び出すことができるが、単一のアクティベーションのみをもたらすことを意味します。
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.
オブジェクトAがステートフルな方法で定義されていた場合、セット操作により、SET1との相互作用の結果としてSET2操作が失敗した可能性があります。エージェントの実装が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モジュールレベルのモデリングは、あるセット操作から別のセット操作までの等であり、ステートレスである可能性がありますが、基礎となるサブシステムではそうではない場合があります。一連のセット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.
例として、MIBモジュールを定義して仮想プライベートネットワーク（VPN）転送を制御することは合理的です。この転送では、管理ステーションがVPNゲートウェイのIngress/Eugress IPアドレスのセットを設定できます。おそらく、MIBモジュールは、取引性のレベルが、イングレス/エグレスゲートウェイのアドレスを定義するテーブル内の単一行の確立であり、そのゲートウェイへのVPNレイヤーでのルーティングを支援するプレフィックス情報があると推測しています。ただし、基礎となるレイヤー2 VPNサブシステムインストゥルメンテーションでは、新しいゲートウェイを追加するために、新しいゲートウェイを定義する前に、VPNの既存のすべてのゲートウェイを削除することであると考えられます。、g（n）、a vpn、ゲートウェイG（1）.. g（n-1）を削除する必要があり、その後、すべてのNゲートウェイがVPN転送サービスで再確立されます。この場合、新しい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つの値への変更には、システムの再独立性が必要になる場合があります。これらのすべてのケースでは、説明条項には、管理されたシステムの要件に関する情報と、マネージャーが観察すべき特別な制限を含める必要があります。
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の2番目のバージョンは、書き込みのみのオブジェクトの直接サポートをドロップしました。したがって、オブジェクトを読むときに、書き込みのみのセマンティクスを持ちたいと思っていたかもしれない何かを返す必要があります。そのようなオブジェクトには、返品値がどうあるべきかを詳述する説明条項が必要です。ただし、アプローチに関係なく、オブジェクトインスタンスを読み取るときに返される値は、オブジェクトのセマンティクスのコンテキストで意味があるはずです。
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. 以前の構成を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.
もちろん、これらの3つの機能は、この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.
管理ソフトウェアは、セット操作が展開されている環境に留意する必要があります。ここでの意図は、構成情報を管理したデバイスにできるだけ効率的に移動することです。効率を達成するには多くの方法があり、一部は与えられたデバイスに固有のものです。すべての管理ソフトウェアが採用すべき一般的なケースの1つは、管理されたデバイスと管理ソフトウェアの間の設定されたPDU交換の数を最小の合理的な数に減らすことです。これに対する1つのアプローチは、管理されたデバイスのセットPDUに収まる可能性のある可変バインディングの最大数を検証することです。場合によっては、特定のPDUで送信される可変バインディングの数は、デバイス、特定のMIBオブジェクト、その他の要因の影響を受けます。
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.
セット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.
ただし、単一のセットPDUで処理できるVarbindsの数と順序に実装制限がある可能性のあるエージェントがあります。この場合、より少ないVarbindsを送信する必要があります。
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 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.
あらゆる種類のトランザクションセマンティクスを効果的に使用するために、SNMP管理ソフトウェアは、1つ以上のテーブルでトランザクションを制御するためにRowStatusオブジェクトを効果的に利用できるように構成するMIBモジュールの情報を認識する必要があります。このようなソフトウェアは、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モデルには、いくつかの実用的な手段が存在します。1つは、前のセクションで言及されており、トランザクションは、エージェントに送信された単一の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.
これには重要な洗練があります。テーブルのRead-Create行データオブジェクトのセットは、単一のPDUで送信する必要があり、絶対に必要な場合にのみ複数のPDUに配置する必要があります。これらのセット操作の成功は、応答を通じてSET PDUまたはその後の行データオブジェクトのポーリングに対する検証される必要があります。該当するRowStatusオブジェクトは、この検証後にのみアクティブに設定できます。これは、特に複数の管理されたデバイスのテーブルロウインスタンス全体に構成の変更が行われている場合、rowごとのロールバックの機会を提供する唯一の扱いやすい手段です。
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を使用してエージェントから構成を取得し、関連するコンテンツを管理アプリケーションデータベースに保存する必要があります。GetBulkRequest-PDUは、大量のデータを取得する際のGetNextre-Equest-PDUよりも効率的であるため、管理されたデバイスでサポートされる場合はいつでもこれに役立ちます。後方互換性の目的のために、管理ステーションは、エージェントがGetBulkRequest-PDUをサポートしていない場合、GetNextre-Equest-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.
前のセクションで説明されている効率的なデータ検索の手法は、構成アプリケーションを開発する際に、この点でアプリケーション開発者が考慮すべきものの1つの側面のみを含みます。管理アプリケーションは、構成操作の分散処理を提供する必要があります。これは、このドキュメントの焦点ではない管理機能にも拡張されます。分散処理の手法は、ネットワーク障害の場合に回復力を提供するために使用することもできます。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で送信されると、デバイスへの未承諾パケットにより、1つ以上のトラップ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.
認証トラップのさらなる責任は、エージェントシステム上の無効なコミュニティ文字列を備えたPDUの洪水の形で、サービス拒否（DOS）攻撃に直面して生成されている場合に見られます。システムが無効なエージェントデータアクセスに応答して回復する必要がある場合、それが十分に悪い場合は、別の認証通知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].
機密性は、SNMPV3管理フレームワークの必須部分ではありません[6]。
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フレームワークの既存のセキュリティ機能を活用する必要があります。彼らがこれを行うことができる1つの方法は、異なるオブジェクトタイプに適したセキュリティのレベルを示すことです。たとえば、システムの構成を変更するオブジェクトは、SNMPV3の認証メカニズムを使用して保護される場合があります。具体的には、MIBモジュールオブジェクトのグループ化をVACMビューの定義に関する考慮事項で設計することが役立ちます。これにより、ユーザーは特定のユーザーとビューに表示されるテーブルを定義し、適切に範囲します。
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.
個々のルールはビジネス目標をサポートするために定義される可能性があるため、これらの2つの見解は矛盾していないことに注意してください。
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）そのアプリケーションはアクセスリストの定義とは無関係です。たとえば、アクセスリストのアプリケーションをあるインターフェイスから別のインターフェースに変更しても、アクセスリスト自体の変更は必要ありません。前述の最初のポイントは、テンプレートベースのデータ組織に必要なものを示唆しています。2番目は、ポリシーベースの方法で適用を示唆しています。
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.
構成情報のサイズと複雑さの成長は、その組織に大きな意味を持ち、管理エージェントへの効率的な転送もあります。例として、Bridge MIB [24]を実装するエージェントを使用して、約65,000のポートエントリを持つ大きなVLANを表すことができます。このようなVLANを構成するには、そのような仮想ポートごとにdot1dstpporttableとdot1dstaticableエントリを確立する必要があります。各テーブルエントリには、いくつかのパラメーターが含まれます。より効率的なアプローチは、この例では、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オブジェクトに含まれています。つまり、オブジェクトの値とタイプだけでなく、値を適用するオブジェクトの正確なインスタンスも含まれています。インスタンスの数（インターフェイスなど）が増えると、構成操作を爆発させる傾向があるのはこのプロパティです。このインスタンスごとのアプローチは、専門家によって構成されたいくつかのマシンで機能しますが、よりスケーラブルなソリューションが必要です。テンプレートベースのデータ組織とポリシーベースの管理は、インスタンスレベルの上に詳細を抽象化します。つまり、管理されたデバイスに送信されるセット要求が少なくなります。
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リクエストを発行することにより、このタイプの情報を取得する必要がありました。このアプローチは、多くの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.
このセクションは、ポリシーベースのシステムとポリシーベースのシステムではないシステムに等しく適用されます。これは、構成操作をタイムゾーンで同期する必要があることが多いためです。可能な限り、ネットワーク要素は、ローカルタイムゾーン情報を含む標準のデータアンドタイム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.
通知は、ポリシー管理下でのポリシーまたは要素のエラーの結果としてポリシーの障害を決定するのに役立ちます。すべての通知と同様に、特定の期間にわたって役立つ以上のものを送信することによって問題を作成しないように定義および制御する必要があります。たとえば、ポリシーが1,000個のインターフェイスを制御して失敗している場合、1,000ではなく1つの通知がより良いアプローチになる場合があります。さらに、このような通知は、問題解決を支援するためにできるだけ多くの情報を含めるように定義する必要があります。
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を使用したポリシーベースの構成の利点の1つは、多くの構成操作を少量のデータで伝達できることです。システム上の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を使用したポリシーベースの構成を使用して、100の同様のインターフェイスに構成変更を適用するために必要なポリシー情報とともに、単一のセットPDUを送信できます。この効率ゲインは、構成する各インスタンスの値を送信する必要性を排除した結果です。ポリシーに含まれる各インスタンスの「デフォルト」が送信され、デフォルトを適用するインスタンスの選択のルールも実行できます（ポリシー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つのセット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.
この効率ゲインは、設定操作だけでなく、構成情報を必要とする管理操作にも適用されます。ポリシーは、クロスインスタンスのデフォルトのストレージにも保持されているため（たとえば、[36]、PMPolicyTableなど）、数百行の情報を制御するデータセット全体を単一の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であるオブジェクトが含まれています。HVAC MIBモジュールの最初のテーブルであるBldghvactableのオブジェクトは次のとおりです。
Index objects that identify what floor and office we are managing:
管理しているフロアとオフィスを識別するインデックスオブジェクト：
bldgHVACFloor bldgHVACOffice
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:
作業のステータスと単位（bldghvaccolorheatmins）と標準のrowあたりのSNMPADMINSTRING、STORAGETYPE、およびROWSTATUS COLOMNARオブジェクトを示す一連のオブジェクト：
bldgHVACFanSpeed bldgHVACCurrentTemp bldgHVACCoolOrHeatMins bldgHVACDiscontinuityTime bldgHVACOwner bldgHVACStatus
Bldghvacfanspeed bldghvaccurrenttemp
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
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.
この時点で、構成情報が提供されていないことに注意してください。それは次のテーブルにあります。一部の読者は、なぜこのテーブルが次のステップで説明されている構成テンプレートテーブルと組み合わされないのか疑問に思うかもしれません。実際、彼らはそうすることができます。別のテーブルを持つ理由は、システムがより複雑になるにつれて、これらの説明を指す複数の構成テーブルがある可能性があるためです。2つのテーブルのもう1つの理由は、これがすべてのテンプレートとインスタンスで再現されていないため、追加のデータの動きを節約できることです。すべてのデザイナーは、他の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
bldghvaccfgtemplatedededtemp bldghvaccfgtemplatecoolorheat
Administrative objects for SnmpAdminString and RowStatus:
snmpadminstringとrowstatusの管理オブジェクト：
bldgHVACCfgTemplateInfo bldgHVACCfgTemplateOwner bldgHVACCfgTemplateStorage bldgHVACCfgTemplateStatus
bldghvaccfgtemplateinfo bldghvaccfgtemplateowner
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モジュールのアイデンティティ最後の「2003032700z」組織 "SNMPCONFワーキンググループ電子メール：snmpconf@snmp.com" contact-info "jon saperia postal：JDSコンサルティング174チャップマンストリートウォータータウン、マサチューセッツ州02472 U.S.A：-mail：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
ウェイン・タッカベリー郵便：ゴールドワイヤーテクノロジー411 Waverley Oaks Rd。ウォルサム、マサチューセッツ州02452 U.S.A.電話：1 781 398 8800電子メール：Wayne@goldwiretech.com Michael Macfaden Postal：Riverstone Networks 5200 Great America Pkwy。Santa Clara、CA 95054 U.S.A.電話：1 408 878 6500電子メール：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.
David Partain Postal：Ericsson AB P.O.Box 1248 SE-581 12リンキングスウェーデンの電子メール：David.partain@ericsson.com "説明"この例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."
Copyright（c）The Internet Society（2003）。このMIBモジュールのこのバージョンは、RFC 3512の一部です。完全な法的通知については、RFC自体を参照してください。」
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.
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.
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."
bldghvacccftemplateinfotabobable object-type構文の構文シーケンスbldghvaccfgtemplateinfoentry max-access accessable accessable cullent cullent culere descrite "このテーブルは、ネットワーク内のHVACテンプレートにユニークな文字列識別を提供します。または加熱すると、このテーブルの行のインデックス文字列はテンプレート名になる可能性があります。Bldghvaccfgcfgcfgcfgtemplateinfodescriptionには、次のようなテンプレートサービスの目的の簡単な説明が含まれています。このテーブルの関連する行は、このメカニズムではあるがテンプレート制御下にあると識別できるbldghvaccfgtemplateInfotableの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オブジェクトタイプ構文bldghvaccfgtemplateentry max-access not-accessable accessable accessable current current current current current "各行は、選択したインスタンスに適用できるテンプレートパラメーターの単一のセットを表します。スケジューリング施設を通じて。
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."
::= { bldgHVACCfgTemplateEntry 6 }
bldgHVACCfgTemplateStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The activation status of this row of the table.
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モジュールコンプライアンスステータス現在の説明「bldg-hvac-mibへの適合の要件。bldghvacobjectsグループは、bldg-hvac-mibに準拠するために実装する必要があります。」モジュール - このモジュール
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つのオブジェクトで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:
3階のオフィス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.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.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)
The second entry in the bldgHVACCfgTemplateTable, to which all of the above point, might have the following configuration:
上記のすべてのポイントのすべてに、次の構成がある場合があります。
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:
bldghvaccfgtemplatedEriedTemp.2 = 22 bldghvaccfgtemplatecoolorheat.2 = cool（2）bldghvaccfgtemplateinfo.2 = 2 atestatus.2 = Active（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 = "Executive Offices" bldghvaccfgtemplateinfodescr.2 = "エグゼクティブオフィスの温度を制御する" .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階のOffice 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)
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)
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).
エグゼクティブの流通が改善され、気温が他の執行オフィスと整列するようにすると、これは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から現在の温度、ファン速度、冷却または暖房分を読み取ることができます。その場合、bldghvaccfgtemplateの値は、bldghvacownerの値と同様に、ゼロインデックス（ "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)
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.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.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) 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:
bldghvaccfgtemplate.15.104 = bldghvaccfgtemplatedesiredtemp.1 bldghvacfanspeed.15.104 = 12 bldghvaccurrenttemp.15.104 = 19 bldghvacolorheatmins.15.104 = 1123 bldghvacdiscdiscontimuptimutiutiutiutiutiut acowner.15.104 = = "Bob the Conference Guy" bldghvacstorageType.15.104 =非揮発性（3）bldghvacstatus.15.104 =アクティブ（1）目的の温度と加熱または冷却するかどうかは、会議室で温度を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)
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)
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.
そのために、「展開とセキュリティの問題」というタイトルのこのドキュメントのセクションは、これらのセキュリティに関する考慮事項を、このドキュメント全体で説明した現在の慣行に影響を与える範囲でカバーしています。特に、「Secure Agentの考慮事項」というタイトルのサブセクションでは、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
クリストファー・アンダーソン・アンディ・ビアマン・グレッグ・ブルーエル博士ジェフリー・ケースクリス・エリオット・ジョエル・ハルパン・パブロ・ハルパーン・ウェス・ハーディー・ハリー・ハリー・ティッパナ・ティッパナ・ティッパナ・ホンガン・ザ・ボブ・ムーア・デイビッド・デイヴィッド・デイビッド・デイヴィッド・デイビッド・デイビッド・デイビッド・デイビッド・デイビッド・
[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] Harrington、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.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[3] McCloghrie、K.、Perkins、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.、Perkins、D。およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[5] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
[5] Presuhn、R。（ed。）、「Simple Network Management Protocol（SNMPV2）の輸送マッピング」、STD 62、RFC 3417、2002年12月。
[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] Case、J.、Harrington D.、Presuhn R.およびB. Wijnen、「Simple Network Management Protocol（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] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、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。（ed。）、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[9] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol Applications", STD 62, RFC 3413, December 2002.
[9] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol Applications」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、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。（ed。）、「Simple Network Management Protocol（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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、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] Daniele、M.、Haberman、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。（編）、「SMIV2を使用したインターネットプロトコルのSNMPV2管理情報ベース」、RFC 2011、1996年11月。
[15] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[15] Rose、M。and 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] Rose、M。and K. McCloghrie、「Scise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[17] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[17] Rose、M。、「SNMPで使用するトラップを定義するための慣習」、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] Case、J.、Fedor、M.、Schoffstall、M。and J. Davin、「Simple Network Management Protocol」、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] Case、J.、McCloghrie、K.、Rose、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、「The Interfaces Group 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] Brown、C。およびF. Baker、「Smiv2を使用したフレームリレーDTEの管理情報ベース」、RFC 2115、1997年9月。
[22] Baker, F. (Ed.), "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[22] Baker、F。（ed。）、「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] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（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] Decker、E.、Langille、P.、Rijsinghani、A。and 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] Levi、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] Bell、E.、Smith、A.、Langille、P.、Rijsinghani、A。and K. McCloghrie、「交通クラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えた橋の管理されたオブジェクトの定義」、RFC 2674、1999年8月。
[27] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1997.
[27] Baker、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] St. Johns、M。（編）、「MCNS/DOCSIS準拠のRFインターフェイスの無線周波数（RF）インターフェイス管理情報ベース」、RFC 2670、1999年8月。
[29] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1850, November 1995.
[29] Baker、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] Blake、S.、Black、D.、Carlson M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Willis、S.、Burruss、J。and J. Chu（ed。）、「SMIV2を使用したBorder Gateway Protocol（BGP-4）の4番目のバージョンの管理オブジェクトの定義」、RFC 1657、1994年7月。
[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. Hanson、「インターフェースグループMIBへの逆スタックテーブル拡張」、RFC 2864、2000年6月。
[34] McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC 2737, December 1999.
[34] McCloghrie、K。およびA. Bierman、「Entity 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] Heintz、L。、「SNMP Row Operations Extensions」、進行中の作業。
[38] Zeltserman, D., "A Practical Guide to Snmpv3 and Network Management", Prentice Hall, 1999.
[38] Zeltserman、D。、「SNMPV3とネットワーク管理の実用的なガイド」、1999年Prentice Hall。
[39] Noto, M., Spiegel, E. and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999.
[39] Noto、M.、Spiegel、E。and K. Tesink、「ATM管理のテキストコンベンションとオブジェクトアイデンティティの定義」、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] St. Johns、M。、「Docsis Cable Device MIBケーブルデバイス管理情報ベースDOCSISコンプライアンスケーブルモデムおよびケーブルモデム終了システムのベース」、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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J. and 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。、「リモートネットワーク監視管理情報ベースバージョン2を使用したバージョン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
Michael R. Macfaden Riverstone Networks、Inc 5200 Great America Parkway Santa Clara、CA 95054
EMail: mrm@riverstonenet.com
David Partain Ericsson AB P.O. Box 1248 SE-581 12 Linkoping Sweden
David Partain Ericsson AB P.O.Box 1248 SE-581 12リンクススウェーデン
EMail: David.Partain@ericsson.com
Jon Saperia JDS Consulting 174 Chapman Street Watertown, MA 02472
ジョン・サペリアJDSコンサルティング174チャップマンストリートウォータータウン、マサチューセッツ州02472
EMail: saperia@jdscons.com
Wayne F. Tackabury Gold Wire Technology 411 Waverley Oaks Rd. Waltham, MA 02452
ウェインF.タッカベリーゴールドワイヤーテクノロジー411 Waverley Oaks Rd。ウォルサム、マサチューセッツ州02452
EMail: wayne@goldwiretech.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。