RFC3411 日本語訳
3411 An Architecture for Describing Simple Network Management Protocol(SNMP) Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT=140096 bytes) (Obsoletes RFC2571) (Updated by RFC5343) (Also STD0062) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Harrington
Request for Comments: 3411 Enterasys Networks
STD: 62 R. Presuhn
Obsoletes: 2571 BMC Software, Inc.
Category: Standards Track B. Wijnen
Lucent Technologies
December 2002
コメントを求めるワーキンググループD.ハリントンの要求をネットワークでつないでください: 3411EnterasysはSTDをネットワークでつなぎます: 62 R.Presuhnは以下を時代遅れにします。 2571年のBMCソフトウェアInc.カテゴリ: 標準化過程B.Wijnenルーセントテクノロジーズ2002年12月
An Architecture for Describing
Simple Network Management Protocol (SNMP) Management Frameworks
簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571.
このドキュメントは、Simple Network Managementプロトコル(SNMP)管理Frameworksについて説明するためにアーキテクチャについて説明します。 アーキテクチャは、時間がたつにつれてSNMPプロトコル標準の発展を許容するためにはモジュールであるために設計されています。 アーキテクチャの主要部は、Message Processing Subsystem、Security Subsystem、およびAccess Control Subsystemを含むSNMPエンジンと、管理データの特定の機能的な処理を提供することによると複数のSNMPアプリケーションです。 このドキュメントはRFC2571を時代遅れにします。
Table of Contents
目次
1. Introduction ................................................ 4 1.1. Overview .................................................. 4 1.2. SNMP ...................................................... 5 1.3. Goals of this Architecture ................................ 6 1.4. Security Requirements of this Architecture ................ 6 1.5. Design Decisions .......................................... 8 2. Documentation Overview ...................................... 10 2.1. Document Roadmap .......................................... 11 2.2. Applicability Statement ................................... 11
1. 序論… 4 1.1. 概要… 4 1.2. SNMP… 5 1.3. このArchitectureの目標… 6 1.4. このArchitectureのセキュリティRequirements… 6 1.5. 決定を設計してください… 8 2. ドキュメンテーション概要… 10 2.1. 道路地図を記録してください… 11 2.2. 適用性声明… 11
Harrington, et al. Standards Track [Page 1] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[1ページ]。
2.3. Coexistence and Transition ................................ 11 2.4. Transport Mappings ........................................ 12 2.5. Message Processing ........................................ 12 2.6. Security .................................................. 12 2.7. Access Control ............................................ 13 2.8. Protocol Operations ....................................... 13 2.9. Applications .............................................. 14 2.10. Structure of Management Information ...................... 15 2.11. Textual Conventions ...................................... 15 2.12. Conformance Statements ................................... 15 2.13. Management Information Base Modules ...................... 15 2.13.1. SNMP Instrumentation MIBs .............................. 15 2.14. SNMP Framework Documents ................................. 15 3. Elements of the Architecture ................................ 16 3.1. The Naming of Entities .................................... 17 3.1.1. SNMP engine ............................................. 18 3.1.1.1. snmpEngineID .......................................... 18 3.1.1.2. Dispatcher ............................................ 18 3.1.1.3. Message Processing Subsystem .......................... 19 3.1.1.3.1. Message Processing Model ............................ 19 3.1.1.4. Security Subsystem .................................... 20 3.1.1.4.1. Security Model ...................................... 20 3.1.1.4.2. Security Protocol ................................... 20 3.1.2. Access Control Subsystem ................................ 21 3.1.2.1. Access Control Model .................................. 21 3.1.3. Applications ............................................ 21 3.1.3.1. SNMP Manager .......................................... 22 3.1.3.2. SNMP Agent ............................................ 23 3.2. The Naming of Identities .................................. 25 3.2.1. Principal ............................................... 25 3.2.2. securityName ............................................ 25 3.2.3. Model-dependent security ID ............................. 26 3.3. The Naming of Management Information ...................... 26 3.3.1. An SNMP Context ......................................... 28 3.3.2. contextEngineID ......................................... 28 3.3.3. contextName ............................................. 29 3.3.4. scopedPDU ............................................... 29 3.4. Other Constructs .......................................... 29 3.4.1. maxSizeResponseScopedPDU ................................ 29 3.4.2. Local Configuration Datastore ........................... 29 3.4.3. securityLevel ........................................... 29 4. Abstract Service Interfaces ................................. 30 4.1. Dispatcher Primitives ..................................... 30 4.1.1. Generate Outgoing Request or Notification ............... 31 4.1.2. Process Incoming Request or Notification PDU ............ 31 4.1.3. Generate Outgoing Response .............................. 32 4.1.4. Process Incoming Response PDU ........................... 32 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 32
2.3. 共存と変遷… 11 2.4. マッピングを輸送してください… 12 2.5. メッセージ処理… 12 2.6. セキュリティ… 12 2.7. コントロールにアクセスしてください… 13 2.8. 操作について議定書の中で述べてください… 13 2.9. アプリケーション… 14 2.10. 経営情報の構造… 15 2.11. 原文のコンベンション… 15 2.12. 順応声明… 15 2.13. 管理情報ベースモジュール… 15 2.13.1. SNMP計装MIBs… 15 2.14. SNMPフレームワークドキュメント… 15 3. アーキテクチャのElements… 16 3.1. 実体の命名… 17 3.1.1. SNMPエンジン… 18 3.1.1.1snmpEngineID… 18 3.1.1.2. 発送者… 18 3.1.1.3. メッセージ処理サブシステム… 19 3.1.1.3.1. メッセージ処理モデル… 19 3.1.1.4. セキュリティサブシステム… 20 3.1.1.4.1. セキュリティはモデル化されます… 20 3.1.1.4.2. セキュリティは議定書を作ります… 20 3.1.2. コントロールサブシステムにアクセスしてください… 21 3.1.2.1. 規制モデルにアクセスしてください… 21 3.1.3. アプリケーション… 21 3.1.3.1. SNMPマネージャ… 22 3.1.3.2. SNMPエージェント… 23 3.2. アイデンティティの命名… 25 3.2.1. 主体… 25 3.2.2securityName… 25 3.2.3. モデル依存するセキュリティID… 26 3.3. 経営情報の命名… 26 3.3.1. SNMP文脈… 28 3.3.2contextEngineID… 28 3.3.3contextName… 29 3.3.4scopedPDU… 29 3.4. 他の構造物… 29 3.4.1maxSizeResponseScopedPDU… 29 3.4.2. 地方の構成Datastore… 29 3.4.3securityLevel… 29 4. 抽象的なサービスは連結します… 30 4.1. 発送者基関数… 30 4.1.1. 送信する要求か通知を生成してください… 31 4.1.2. 入って来る要求か通知PDUを処理してください… 31 4.1.3. 外向的な応答を生成してください… 32 4.1.4. 入って来る応答PDUを処理してください… 32 4.1.5. 取り扱いSNMP PDUsへの責任を登録します… 32
Harrington, et al. Standards Track [Page 2] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[2ページ]。
4.2. Message Processing Subsystem Primitives ................... 33 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 33 4.2.2. Prepare an Outgoing SNMP Response Message ............... 34 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 35 4.3. Access Control Subsystem Primitives ....................... 35 4.4. Security Subsystem Primitives ............................. 36 4.4.1. Generate a Request or Notification Message .............. 36 4.4.2. Process Incoming Message ................................ 36 4.4.3. Generate a Response Message ............................. 37 4.5. Common Primitives ......................................... 37 4.5.1. Release State Reference Information ..................... 37 4.6. Scenario Diagrams ......................................... 38 4.6.1. Command Generator or Notification Originator ............ 38 4.6.2. Scenario Diagram for a Command Responder Application .... 39 5. Managed Object Definitions for SNMP Management Frameworks ... 40 6. IANA Considerations ......................................... 51 6.1. Security Models ........................................... 51 6.2. Message Processing Models ................................. 51 6.3. SnmpEngineID Formats ...................................... 52 7. Intellectual Property ....................................... 52 8. Acknowledgements ............................................ 52 9. Security Considerations ..................................... 54 10. References ................................................. 54 10.1. Normative References ..................................... 54 10.2. Informative References ................................... 56 A. Guidelines for Model Designers .............................. 57 A.1. Security Model Design Requirements ........................ 57 A.1.1. Threats ................................................. 57 A.1.2. Security Processing ..................................... 58 A.1.3. Validate the security-stamp in a received message ....... 59 A.1.4. Security MIBs ........................................... 59 A.1.5. Cached Security Data .................................... 59 A.2. Message Processing Model Design Requirements .............. 60 A.2.1. Receiving an SNMP Message from the Network .............. 60 A.2.2. Sending an SNMP Message to the Network .................. 60 A.3. Application Design Requirements ........................... 61 A.3.1. Applications that Initiate Messages ..................... 61 A.3.2. Applications that Receive Responses ..................... 62 A.3.3. Applications that Receive Asynchronous Messages ......... 62 A.3.4. Applications that Send Responses ........................ 62 A.4. Access Control Model Design Requirements .................. 63 Editors' Addresses ............................................. 63 Full Copyright Statement ....................................... 64
4.2. メッセージ処理サブシステム基関数… 33 4.2.1. 送信するSNMP要求か通知メッセージを用意してください… 33 4.2.2. 外向的なSNMP応答メッセージを用意してください… 34 4.2.3. 入って来るSNMPメッセージからデータ要素を用意してください… 35 4.3. コントロールサブシステム基関数にアクセスしてください… 35 4.4. セキュリティサブシステム基関数… 36 4.4.1. 要求か通知メッセージを生成してください… 36 4.4.2. 入力メッセージを処理してください… 36 4.4.3. 応答メッセージを生成してください… 37 4.5. 一般的な基関数… 37 4.5.1. 州の参考情報を発表してください… 37 4.6. シナリオダイヤグラム… 38 4.6.1. ジェネレータか通知創始者を命令してください… 38 4.6.2. コマンド応答者アプリケーションのためのシナリオダイヤグラム… 39 5. SNMP管理フレームワークのための管理オブジェクト定義… 40 6. IANA問題… 51 6.1. セキュリティはモデル化されます… 51 6.2. メッセージ処理はモデル化されます… 51 6.3. SnmpEngineID形式… 52 7. 知的所有権… 52 8. 承認… 52 9. セキュリティ問題… 54 10. 参照… 54 10.1. 標準の参照… 54 10.2. 有益な参照… 56 モデルデザイナーへのA.ガイドライン… 57 A.1。 セキュリティは設計の品質をモデル化します… 57 A.1.1。 脅威… 57 A.1.2。 セキュリティ処理… 58 A.1.3。 受信されたメッセージでセキュリティスタンプを有効にしてください… 59 A.1.4。 セキュリティMIBs… 59 A.1.5。 セキュリティー・データをキャッシュします… 59 A.2。 メッセージ処理モデル設計の品質… 60 A.2.1。 ネットワークからSNMPメッセージを受け取ります… 60 A.2.2。 SNMPメッセージをネットワークに送ります… 60 A.3。 アプリケーション設計要件… 61 A.3.1。 アプリケーション、そのInitiate Messages… 61 A.3.2。 アプリケーション、そのReceive Responses… 62 A.3.3。 アプリケーション、そのReceive Asynchronous Messages… 62 A.3.4。 アプリケーション、そのSend Responses… 62 A.4。 コントロールモデル設計の品質にアクセスしてください… 63人のエディタのアドレス… 63 完全な著作権宣言文… 64
Harrington, et al. Standards Track [Page 3] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[3ページ]。
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
This document defines a vocabulary for describing SNMP Management Frameworks, and an architecture for describing the major portions of SNMP Management Frameworks.
このドキュメントは、SNMP Management Frameworksについて説明するためにボキャブラリーを定義して、SNMP Management Frameworksの主要部について説明するためにアーキテクチャを定義します。
This document does not provide a general introduction to SNMP. Other documents and books can provide a much better introduction to SNMP. Nor does this document provide a history of SNMP. That also can be found in books and other documents.
このドキュメントは一般的な序論をSNMPに供給しません。 他のドキュメントと本ははるかに良い序論をSNMPに供給できます。 また、このドキュメントはSNMPの歴史を供給しません。 また、本と他のドキュメントでそれを見つけることができます。
Section 1 describes the purpose, goals, and design decisions of this architecture.
セクション1はこのアーキテクチャの目的、目標、およびデザイン決定について説明します。
Section 2 describes various types of documents which define (elements of) SNMP Frameworks, and how they fit into this architecture. It also provides a minimal road map to the documents which have previously defined SNMP frameworks.
2が様々なタイプについて説明するセクションがどれを記録するか、定義、(要素、)、SNMP Frameworksと、彼らはどうこのアーキテクチャに収まるか。 また、それは以前にSNMPフレームワークを定義したドキュメントに最小量のロードマップを供給します。
Section 3 details the vocabulary of this architecture and its pieces. This section is important for understanding the remaining sections, and for understanding documents which are written to fit within this architecture.
セクション3はこのアーキテクチャとその片のボキャブラリーを詳しく述べます。 残っているセクションを理解していて、書かれているドキュメントがこのアーキテクチャの中で合うのを理解しているのに、このセクションは重要です。
Section 4 describes the primitives used for the abstract service interfaces between the various subsystems, models and applications within this architecture.
セクション4は様々なサブシステムと、モデルとアプリケーションとの抽象的なサービスインタフェースにこのアーキテクチャの中で使用された基関数について説明します。
Section 5 defines a collection of managed objects used to instrument SNMP entities within this architecture.
セクション5はこのアーキテクチャの中で器具SNMP実体に使用された管理オブジェクトの収集を定義します。
Sections 6, 7, 8, 9, 10 and 11 are administrative in nature.
セクション6、7、8、9、10、および11は現実に管理です。
Appendix A contains guidelines for designers of Models which are expected to fit within this architecture.
付録Aはこのアーキテクチャの中で合うと予想されるModelsのデザイナーへのガイドラインを含んでいます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Harrington, et al. Standards Track [Page 4] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[4ページ]。
1.2. SNMP
1.2. SNMP
An SNMP management system contains:
SNMPマネージメントシステムは以下を含んでいます。
- several (potentially many) nodes, each with an SNMP entity
containing command responder and notification originator
applications, which have access to management instrumentation
(traditionally called agents);
- 数個の(潜在的に多く)のノードと、それぞれSNMP実体が管理計装に近づく手段を持っているコマンド応答者と通知創始者アプリケーションを含んでいる(伝統的にエージェントと呼ばれます)。
- at least one SNMP entity containing command generator and/or
notification receiver applications (traditionally called a
manager) and,
- そしてコマンドジェネレータ、そして/または、通知受信側アプリケーション(伝統的にマネージャと呼ばれる)を含む少なくとも1つのSNMP実体。
- a management protocol, used to convey management information
between the SNMP entities.
- SNMP実体の間に経営情報を伝えるのに使用される管理プロトコル。
SNMP entities executing command generator and notification receiver applications monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
コマンドジェネレータと通知受信側アプリケーション監視制御装置を実行するSNMP実体が要素を管理しました。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
It is the purpose of this document to define an architecture which can evolve to realize effective management in a variety of configurations and environments. The architecture has been designed to meet the needs of implementations of:
さまざまな構成と環境で効果的な管理がわかるために発展できるアーキテクチャを定義するのは、このドキュメントの目的です。 アーキテクチャは、以下の実装の需要を満たすように設計されています。
- minimal SNMP entities with command responder and/or
notification originator applications (traditionally called SNMP
agents),
- コマンド応答者がいる最小量のSNMP実体、そして/または、通知創始者アプリケーション(伝統的にSNMPエージェントと呼ばれます)
- SNMP entities with proxy forwarder applications (traditionally
called SNMP proxy agents),
- プロキシ混載業者のアプリケーション(伝統的にSNMPプロキシエージェントと呼ばれる)があるSNMP実体
- command line driven SNMP entities with command generator and/or
notification receiver applications (traditionally called SNMP
command line managers),
- コマンドジェネレータ、そして/または、通知受信側アプリケーション(伝統的にSNMPコマンドラインマネージャと呼ばれる)があるコマンドラインやる気満々のSNMP実体
- SNMP entities with command generator and/or notification
receiver, plus command responder and/or notification originator
applications (traditionally called SNMP mid-level managers or
dual-role entities),
- コマンドジェネレータ、通知受信機、プラスコマンド応答者、そして/または、通知創始者アプリケーション(伝統的にSNMP中間レベルのマネージャかニ重の役割実体と呼ばれる)があるSNMP実体
- SNMP entities with command generator and/or notification
receiver and possibly other types of applications for managing
a potentially very large number of managed nodes (traditionally
called (network) management stations).
- 潜在的に非常に多くの管理されたノード(伝統的に(ネットワーク)管理局と呼ばれる)を管理するためのコマンドジェネレータ、そして/または、通知受信機があるSNMP実体とアプリケーションのことによると他のタイプ。
Harrington, et al. Standards Track [Page 5] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[5ページ]。
1.3. Goals of this Architecture
1.3. このArchitectureの目標
This architecture was driven by the following goals:
このアーキテクチャは以下の目標によって動かされました:
- Use existing materials as much as possible. It is heavily
based on previous work, informally known as SNMPv2u and
SNMPv2*, based in turn on SNMPv2p.
- 既存の材料をできるだけ使用してください。 それはずっしりと順番にSNMPv2pに基づくSNMPv2uとSNMPv2*として非公式に知られている前の仕事に基づいています。
- Address the need for secure SET support, which is considered
the most important deficiency in SNMPv1 and SNMPv2c.
- 安全なSETサポートの必要性を扱ってください。(サポートはSNMPv1とSNMPv2cで最も重要な欠乏であると考えられます)。
- Make it possible to move portions of the architecture forward
in the standards track, even if consensus has not been reached
on all pieces.
- 標準化過程でアーキテクチャの部分を前方へ動かせるのを可能にしてください、コンセンサスにすべての断片で達しないでも。
- Define an architecture that allows for longevity of the SNMP
Frameworks that have been and will be defined.
- それがSNMP Frameworksの寿命を考慮して、定義されるアーキテクチャを定義してください。
- Keep SNMP as simple as possible.
- できるだけ簡単にSNMPを保ってください。
- Make it relatively inexpensive to deploy a minimal conforming
implementation.
- 最小量の従う実装を配布するのを比較的安価にしてください。
- Make it possible to upgrade portions of SNMP as new approaches
become available, without disrupting an entire SNMP framework.
- 新しいアプローチが全体のSNMPフレームワークを混乱させないで利用可能になるときSNMPの一部をアップグレードさせるのを可能にしてください。
- Make it possible to support features required in large
networks, but make the expense of supporting a feature directly
related to the support of the feature.
- 大きいネットワークで必要である特徴をサポートするのを可能にしなさい、ただし、特徴をサポートする費用を直接特徴のサポートに関連させてください。
1.4. Security Requirements of this Architecture
1.4. このArchitectureのセキュリティRequirements
Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any Security Model used in an SNMP Management Framework. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance.
ネットワーク・プロトコルへのいくつかの古典的な脅威が、管理問題に適用可能であり、したがって、SNMP Management Frameworkで使用されるどんなSecurity Modelにも適切でしょう。 他の脅威は管理問題に適用可能ではありません。 このセクションは、より少なく重要な主要な脅威、セカンダリ脅威、および脅威について論じます。
The principal threats against which any Security Model used within this architecture SHOULD provide protection are:
このアーキテクチャSHOULDの中で使用されたどんなSecurity Modelも保護を提供する主要な脅威は以下の通りです。
Modification of Information
The modification threat is the danger that some unauthorized
entity may alter in-transit SNMP messages generated on behalf
of an authorized principal in such a way as to effect
unauthorized management operations, including falsifying the
value of an object.
変更、情報では、変更の脅威は何らかの権限のない実体がトランジットにおけるそのような方法で認可された元本を代表して権限のない管理操作に作用するほど生成されたSNMPメッセージを変更するかもしれないという危険です、オブジェクトの値を改竄するのを含んでいて。
Harrington, et al. Standards Track [Page 6] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[6ページ]。
Masquerade
The masquerade threat is the danger that management operations
not authorized for some principal may be attempted by assuming
the identity of another principal that has the appropriate
authorizations.
仮装してください。仮面舞踏会の脅威は何らかの主体のために認可されなかった管理操作が適切な承認を持っている別の校長のアイデンティティを仮定することによって試みられるかもしれないという危険です。
Secondary threats against which any Security Model used within this architecture SHOULD provide protection are:
このアーキテクチャSHOULDの中で使用されたどんなSecurity Modelも保護を提供するセカンダリ脅威は以下の通りです。
Message Stream Modification
The SNMP protocol is typically based upon a connectionless
transport service which may operate over any subnetwork
service. The re-ordering, delay or replay of messages can and
does occur through the natural operation of many such
subnetwork services. The message stream modification threat is
the danger that messages may be maliciously re-ordered, delayed
or replayed to an extent which is greater than can occur
through the natural operation of a subnetwork service, in order
to effect unauthorized management operations.
SNMPが議定書の中で述べるメッセージStream Modificationはどんなサブネットワークサービスの上でも作動するかもしれないコネクションレスな輸送サービスに通常基づいています。 メッセージの再注文、遅れまたは再生が、起こって、そのような多くのサブネットワークサービスの自然な操作で起こることができます。 メッセージストリーム変更の脅威はメッセージが自然なサブネットワークサービスの操作で起こることができるより大きい程度まで陰湿に再命令されるか、遅らせられるか、または再演されるかもしれないという危険です、権限のない管理操作に作用するように。
Disclosure
The disclosure threat is the danger of eavesdropping on the
exchanges between SNMP engines. Protecting against this threat
may be required as a matter of local policy.
公開、公開の脅威はSNMPエンジンの間の交換を立ち聞きするという危険です。 この脅威から守るのがローカルの方針の問題として必要であるかもしれません。
There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be of lesser importance in this context:
このアーキテクチャの中のSecurity Modelが保護する必要はない少なくとも2つの脅威があります、それらが、より少なくこのような関係においては重要であると考えられるので:
Denial of Service
A Security Model need not attempt to address the broad range of
attacks by which service on behalf of authorized users is
denied. Indeed, such denial-of-service attacks are in many
cases indistinguishable from the type of network failures with
which any viable management protocol must cope as a matter of
course.
サービス妨害A Security Modelは、認定ユーザを代表したサービスが否定される攻撃の広い声域を扱うのを試みる必要はありません。 本当に、どんな実行可能な管理プロトコルも当然のこととして対処されなければならないネットワーク失敗のタイプから区別できない多くの場合にはそのようなサービス不能攻撃があります。
Traffic Analysis
A Security Model need not attempt to address traffic analysis
attacks. Many traffic patterns are predictable - entities may
be managed on a regular basis by a relatively small number of
management stations - and therefore there is no significant
advantage afforded by protecting against traffic analysis.
A Security Modelが必要とするトラフィックAnalysisは、トラヒック分析が攻撃であると扱うのを試みません。 多くのトラフィック・パターンが予測できます、そして、(実体は定期的に比較的少ない数の管理局によって管理されるかもしれません)したがって、トラヒック分析から守ることによって提供されたどんな重要な利点もありません。
Harrington, et al. Standards Track [Page 7] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[7ページ]。
1.5. Design Decisions
1.5. デザイン決定
Various design decisions were made in support of the goals of the architecture and the security requirements:
アーキテクチャの目標とセキュリティ要件を支持して様々なデザイン決定をしました:
- Architecture
An architecture should be defined which identifies the
conceptual boundaries between the documents. Subsystems should
be defined which describe the abstract services provided by
specific portions of an SNMP framework. Abstract service
interfaces, as described by service primitives, define the
abstract boundaries between documents, and the abstract
services that are provided by the conceptual subsystems of an
SNMP framework.
- アーキテクチャAnアーキテクチャは定義されるべきです(ドキュメントの間の概念的な境界を特定します)。 サブシステムは定義されるべきです(SNMPフレームワークの特定部位によって提供された抽象的なサービスについて説明します)。 サービス基関数によって説明される抽象的なサービスインタフェースはドキュメントと、SNMPフレームワークの概念的なサブシステムで提供される抽象的なサービスの間の抽象的な境界を定義します。
- Self-contained Documents
Elements of procedure plus the MIB objects which are needed for
processing for a specific portion of an SNMP framework should
be defined in the same document, and as much as possible,
should not be referenced in other documents. This allows
pieces to be designed and documented as independent and self-
contained parts, which is consistent with the general SNMP MIB
module approach. As portions of SNMP change over time, the
documents describing other portions of SNMP are not directly
impacted. This modularity allows, for example, Security
Models, authentication and privacy mechanisms, and message
formats to be upgraded and supplemented as the need arises.
The self-contained documents can move along the standards track
on different time-lines.
- 同じドキュメントでSNMPフレームワークの特定部位のための処理に必要である手順の自己充足的なDocuments ElementsとMIBオブジェクトを定義するべきです、そして、できるだけ、他のドキュメントで参照をつけるべきではありません。 これは、断片が独立者と自己の含まれた部品として設計されていて、記録されるのを許容します(一般的なSNMP MIBモジュールアプローチと一致しています)。 SNMPの一部が時間がたつにつれて変化するとき、SNMPの他の一部について説明するドキュメントは直接影響を与えられません。 このモジュール方式は、例えばSecurity Models、認証、プライバシーメカニズム、およびメッセージ・フォーマットが必要に応じてアップグレードして、補われるのを許容します。 自己充足的なドキュメントは異なったタイムラインで標準化過程に沿って移行できます。
This modularity of specification is not meant to be interpreted
as imposing any specific requirements on implementation.
仕様のこのモジュール方式はどんな決められた一定の要求も実装に課すと解釈されることになっていません。
- Threats
The Security Models in the Security Subsystem SHOULD protect
against the principal and secondary threats: modification of
information, masquerade, message stream modification and
disclosure. They do not need to protect against denial of
service and traffic analysis.
- Security Subsystem SHOULDのSecurity Modelsが主要でセカンダリの脅威に対して保護する脅威: 情報、仮面舞踏会、メッセージストリーム変更、および公開の変更。 彼らはサービスとトラヒック分析の否定から守る必要はありません。
- Remote Configuration
The Security and Access Control Subsystems add a whole new set
of SNMP configuration parameters. The Security Subsystem also
requires frequent changes of secrets at the various SNMP
entities. To make this deployable in a large operational
environment, these SNMP parameters must be remotely
configurable.
- リモートConfigurationのSecurityとAccess Control Subsystemsは真新しいSNMP設定パラメータを加えます。 また、Security Subsystemは様々なSNMP実体で秘密の頻繁な変化を必要とします。 大きい運用環境でこの配布可能を作るために、これらのSNMPパラメタはほんの少し構成可能でなければなりません。
Harrington, et al. Standards Track [Page 8] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[8ページ]。
- Controlled Complexity
It is recognized that producers of simple managed devices want
to keep the resources used by SNMP to a minimum. At the same
time, there is a need for more complex configurations which can
spend more resources for SNMP and thus provide more
functionality. The design tries to keep the competing
requirements of these two environments in balance and allows
the more complex environments to logically extend the simple
environment.
- 制御Complexity Itによる認識されて、簡単な管理されたデバイスのそのプロデューサーがSNMPによる運用資金を最小に抑えたがっているということです。 同時に、SNMPにおける、より多くのリソースを費やして、その結果より多くの機能性を提供できるより複雑な構成の必要があります。 デザインは、バランスにおけるこれらの2つの環境の競争している要件を保とうとして、より複雑な環境が簡単な環境を論理的に広げるのを許容します。
Harrington, et al. Standards Track [Page 9] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[9ページ]。
2. Documentation Overview
2. ドキュメンテーション概要
The following figure shows the set of documents that fit within the SNMP Architecture.
以下の図はSNMP Architectureの中で合うドキュメントのセットを示しています。
+------------------------- Document Set ----------------------------+ | | | +----------+ +-----------------+ +----------------+ | | | Document | | Applicability | | Coexistence | | | | Roadmap | | Statement | | & Transition | | | +----------+ +-----------------+ +----------------+ | | | | +---------------------------------------------------------------+ | | | Message Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Transport | | Message | | Security | | | | | | Mappings | | Processing and | | | | | | | | | | Dispatcher | | | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | PDU Handling | | | | +----------------+ +-----------------+ +-----------------+ | | | | | Protocol | | Applications | | Access | | | | | | Operations | | | | Control | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | Information Model | | | | +--------------+ +--------------+ +---------------+ | | | | | Structure of | | Textual | | Conformance | | | | | | Management | | Conventions | | Statements | | | | | | Information | | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | MIB Modules written in various formats, e.g.: | | | | +----------------+ +----------------+ | | | | | SMIv1 (STD 18) | | SMIv2 (STD 58) | | | | | | format | | format | | | | | +----------------+ +----------------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
+------------------------- 文献集合----------------------------+ | | | +----------+ +-----------------+ +----------------+ | | | ドキュメント| | 適用性| | 共存| | | | 道路地図| | 声明| | 変遷| | | +----------+ +-----------------+ +----------------+ | | | | +---------------------------------------------------------------+ | | | メッセージハンドリング| | | | +----------------+ +-----------------+ +-----------------+ | | | | | 輸送| | メッセージ| | セキュリティ| | | | | | マッピング| | そして処理。| | | | | | | | | | 発送者| | | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | PDU取り扱い| | | | +----------------+ +-----------------+ +-----------------+ | | | | | プロトコル| | アプリケーション| | アクセス| | | | | | 操作| | | | コントロール| | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | 情報モデル| | | | +--------------+ +--------------+ +---------------+ | | | | | 構造| | 原文| | 順応| | | | | | 管理| | コンベンション| | 声明| | | | | | 情報| | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | 例えば様々な形式で書かれているMIB Modules: | | | | +----------------+ +----------------+ | | | | | SMIv1(STD18)| | SMIv2(STD58)| | | | | | 形式| | 形式| | | | | +----------------+ +----------------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
Harrington, et al. Standards Track [Page 10] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[10ページ]。
Each of these documents may be replaced or supplemented. This Architecture document specifically describes how new documents fit into the set of documents in the area of Message and PDU handling.
それぞれのこれらのドキュメントを取り替えるか、または補うかもしれません。 このArchitectureドキュメントは明確に新しいドキュメントがMessageとPDU取り扱いの領域にどうドキュメントのセットに収まるかを説明します。
2.1. Document Roadmap
2.1. ドキュメント道路地図
One or more documents may be written to describe how sets of documents taken together form specific Frameworks. The configuration of document sets might change over time, so the "road map" should be maintained in a document separate from the standards documents themselves.
1通以上のドキュメントが、一緒に取られたドキュメントのセットがどう特定のFrameworksを形成するかを説明するために書かれているかもしれません。 文献集合の構成が時間がたつにつれて変化するかもしれないので、「ロードマップ」は規格文書自体から別々のドキュメントで維持されるべきです。
An example of such a roadmap is "Introduction and Applicability Statements for the Internet-Standard Management Framework" [RFC3410].
そのような道路地図に関する例は「インターネット標準の管理フレームワークのための序論と適用性声明」[RFC3410]です。
2.2. Applicability Statement
2.2. 適用性証明
SNMP is used in networks that vary widely in size and complexity, by organizations that vary widely in their requirements of management. Some models will be designed to address specific problems of management, such as message security.
SNMPはサイズと複雑さでばらつきが大きいネットワークに使用されます、それらの管理の要件でばらつきが大きい組織で。 何人かのモデルが、メッセージセキュリティなどの管理のその特定の問題を訴えるように設計されるでしょう。
One or more documents may be written to describe the environments to which certain versions of SNMP or models within SNMP would be appropriately applied, and those to which a given model might be inappropriately applied.
1通以上のドキュメントが、SNMPの中のSNMPかモデルのあるバージョンが適切に適用される環境、および与えられたモデルが不適当に適用されるかもしれないそれらについて説明するために書かれているかもしれません。
2.3. Coexistence and Transition
2.3. 共存と変遷
The purpose of an evolutionary architecture is to permit new models to replace or supplement existing models. The interactions between models could result in incompatibilities, security "holes", and other undesirable effects.
進化論のアーキテクチャの目的は新しいモデルが既存のモデルを置き換えるか、または補うことを許可することです。 モデルの間の相互作用は非互換性、セキュリティ「穴」、および他の望ましくない効果をもたらすかもしれません。
The purpose of Coexistence documents is to detail recognized anomalies and to describe required and recommended behaviors for resolving the interactions between models within the architecture.
Coexistenceドキュメントの目的は、認識された例外を詳しく述べて、アーキテクチャの中でモデルの間の相互作用を決議するための必要でお勧めの振舞いについて説明することです。
Coexistence documents may be prepared separately from model definition documents, to describe and resolve interaction anomalies between a model definition and one or more other model definitions.
共存ドキュメントは、モデル定義と他の1つ以上のモデル定義の間の相互作用例外を説明して、決議するために別々にモデル定義ドキュメントから準備されるかもしれません。
Additionally, recommendations for transitions between models may also be described, either in a coexistence document or in a separate document.
また、さらに、モデルの間の変遷のための推薦は共存ドキュメントか別々のドキュメントで説明されるかもしれません。
Harrington, et al. Standards Track [Page 11] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[11ページ]。
One such coexistence document is [RFC2576], "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework".
そのようなドキュメントの共存1つは[RFC2576]、「インターネット標準のネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」です。
2.4. Transport Mappings
2.4. 輸送マッピング
SNMP messages are sent over various transports. It is the purpose of Transport Mapping documents to define how the mapping between SNMP and the transport is done.
様々な輸送の上にSNMPメッセージを送ります。 SNMPと輸送の間のマッピングがどのように完了しているかを定義するのは、Transport Mappingドキュメントの目的です。
2.5. Message Processing
2.5. メッセージ処理
A Message Processing Model document defines a message format, which is typically identified by a version field in an SNMP message header. The document may also define a MIB module for use in message processing and for instrumentation of version-specific interactions.
Message Processing Modelドキュメントはメッセージ・フォーマットを定義します。(それは、SNMPメッセージヘッダーのバージョン分野によって通常特定されます)。 また、ドキュメントはメッセージ処理における使用とバージョン特有の相互作用の計装のためのMIBモジュールを定義するかもしれません。
An SNMP engine includes one or more Message Processing Models, and thus may support sending and receiving multiple versions of SNMP messages.
SNMPエンジンは、1Message Processing Modelsを含んで、その結果、送受信がSNMPメッセージの複数のバージョンであるとサポートするかもしれません。
2.6. Security
2.6. セキュリティ
Some environments require secure protocol interactions. Security is normally applied at two different stages:
いくつかの環境が安全なプロトコル相互作用を必要とします。 通常、セキュリティは2つの異なった段階で適用されます:
- in the transmission/receipt of messages, and
- そしてメッセージのトランスミッション/領収書で。
- in the processing of the contents of messages.
- メッセージのコンテンツの処理で。
For purposes of this document, "security" refers to message-level security; "access control" refers to the security applied to protocol operations.
このドキュメントの目的について、「セキュリティ」はメッセージレベルセキュリティを示します。 「アクセスコントロール」はプロトコル操作に適用されたセキュリティを示します。
Authentication, encryption, and timeliness checking are common functions of message level security.
認証、暗号化、およびタイムリー照合はメッセージレベルセキュリティの一般的な関数です。
A security document describes a Security Model, the threats against which the model protects, the goals of the Security Model, the protocols which it uses to meet those goals, and it may define a MIB module to describe the data used during processing, and to allow the remote configuration of message-level security parameters, such as keys.
セキュリティドキュメントはSecurity Modelについて説明します、モデルが保護する脅威、Security Modelの目標、それらの目標を達成するのに使用するプロトコル、そして、処理の間に使用されるデータについて説明して、メッセージレベルセキュリティパラメタのリモート構成を許すためにMIBモジュールを定義するかもしれません、キーなどのように。
An SNMP engine may support multiple Security Models concurrently.
SNMPエンジンは同時に複数のSecurity Modelsをサポートするかもしれません。
Harrington, et al. Standards Track [Page 12] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[12ページ]。
2.7. Access Control
2.7. アクセス制御
During processing, it may be required to control access to managed objects for operations.
処理の間、それが、操作のために管理オブジェクトへのアクセスを制御するのに必要であるかもしれません。
An Access Control Model defines mechanisms to determine whether access to a managed object should be allowed. An Access Control Model may define a MIB module used during processing and to allow the remote configuration of access control policies.
Access Control Modelは、管理オブジェクトへのアクセスが許されるべきであるかどうか決定するためにメカニズムを定義します。 Access Control Modelは処理の間に使用されるMIBモジュールを定義するかもしれません、そして、アクセスのリモート構成を許すのは方針を制御します。
2.8. Protocol Operations
2.8. プロトコル操作
SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP PDUs define the operations performed by the receiving SNMP engine. It is the purpose of a Protocol Operations document to define the operations of the protocol with respect to the processing of the PDUs. Every PDU belongs to one or more of the PDU classes defined below:
SNMPメッセージはSNMPプロトコルData Unit(PDU)をカプセル化します。 SNMP PDUsは受信SNMPエンジンによって実行された操作を定義します。 PDUsの処理に関してプロトコルの操作を定義するのは、プロトコルOperationsドキュメントの目的です。 あらゆるPDUが以下で定義されたPDUのクラスの1つ以上に属します:
1) Read Class:
1) クラスを読んでください:
The Read Class contains protocol operations that retrieve
management information. For example, [RFC3416] defines the
following protocol operations for the Read Class: GetRequest-
PDU, GetNextRequest-PDU, and GetBulkRequest-PDU.
Read Classは経営情報を検索するプロトコル操作を含んでいます。 例えば、[RFC3416]はRead Classのために以下のプロトコル操作を定義します: GetRequest- PDU、GetNextRequest-PDU、およびGetBulkRequest-PDU。
2) Write Class:
2) クラスに書いてください:
The Write Class contains protocol operations which attempt to
modify management information. For example, [RFC3416] defines
the following protocol operation for the Write Class:
SetRequest-PDU.
Write Classは経営情報を変更するのを試みるプロトコル操作を含んでいます。 例えば、[RFC3416]はWrite Classのために以下のプロトコル操作を定義します: SetRequest-PDU。
3) Response Class:
3) 応答のクラス:
The Response Class contains protocol operations which are sent
in response to a previous request. For example, [RFC3416]
defines the following for the Response Class: Response-PDU,
Report-PDU.
Response Classは前の要求に対応して送られるプロトコル操作を含んでいます。 例えば、[RFC3416]はResponse Classのために以下を定義します: 応答-PDU、レポート-PDU。
4) Notification Class:
4) 通知のクラス:
The Notification Class contains protocol operations which send
a notification to a notification receiver application. For
example, [RFC3416] defines the following operations for the
Notification Class: Trapv2-PDU, InformRequest-PDU.
Notification Classは通知受信側アプリケーションに通知書を送るプロトコル操作を含んでいます。 例えば、[RFC3416]はNotification Classのために以下の操作を定義します: Trapv2-PDU、InformRequest-PDU。
Harrington, et al. Standards Track [Page 13] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[13ページ]。
5) Internal Class:
5) 内部のクラス:
The Internal Class contains protocol operations which are
exchanged internally between SNMP engines. For example,
[RFC3416] defines the following operation for the Internal
Class: Report-PDU.
Internal ClassはSNMPエンジンの間で内部的に交換されるプロトコル操作を含んでいます。 例えば、[RFC3416]はInternal Classのために以下の操作を定義します: レポート-PDU。
The preceding five classifications are based on the functional properties of a PDU. It is also useful to classify PDUs based on whether a response is expected:
前の5つの分類がPDUの機能特性に基づいています。 また、応答が予想されるかどうか基づくPDUsを分類するのも役に立ちます:
6) Confirmed Class:
6) クラスは確認しました:
The Confirmed Class contains all protocol operations which
cause the receiving SNMP engine to send back a response. For
example, [RFC3416] defines the following operations for the
Confirmed Class: GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU.
Confirmed Classは受信SNMPエンジンが応答を返送するすべてのプロトコル操作を含んでいます。 例えば、[RFC3416]はConfirmed Classのために以下の操作を定義します: GetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、およびInformRequest-PDU。
7) Unconfirmed Class:
7) 未確認のクラス:
The Unconfirmed Class contains all protocol operations which
are not acknowledged. For example, [RFC3416] defines the
following operations for the Unconfirmed Class: Report-PDU,
Trapv2-PDU, and GetResponse-PDU.
Unconfirmed Classは承諾されないすべてのプロトコル操作を含んでいます。 例えば、[RFC3416]はUnconfirmed Classのために以下の操作を定義します: レポート-PDU、Trapv2-PDU、およびGetResponse-PDU。
An application document defines which Protocol Operations are supported by the application.
アプリケーションドキュメントは、どのプロトコルOperationsがアプリケーションでサポートされるかを定義します。
2.9. Applications
2.9. アプリケーション
An SNMP entity normally includes a number of applications. Applications use the services of an SNMP engine to accomplish specific tasks. They coordinate the processing of management information operations, and may use SNMP messages to communicate with other SNMP entities.
通常、SNMP実体は応募件数を含んでいます。 アプリケーションは、特定のタスクを達成するのにSNMPエンジンのサービスを利用します。 彼らは、経営情報操作の処理を調整して、他のSNMP実体で交信するSNMPメッセージを使用するかもしれません。
An applications document describes the purpose of an application, the services required of the associated SNMP engine, and the protocol operations and informational model that the application uses to perform management operations.
アプリケーションドキュメントはアプリケーションの目的について説明します、とサービスがアプリケーションが管理操作を実行するのに使用する関連SNMPエンジン、プロトコル操作、および情報のモデルに必要としました。
An application document defines which set of documents are used to specifically define the structure of management information, textual conventions, conformance requirements, and operations supported by the application.
アプリケーションドキュメントは、どのセットのドキュメントが明確にアプリケーションでサポートされた経営情報、原文のコンベンション、順応要件、および操作の構造を定義するのに使用されるかを定義します。
Harrington, et al. Standards Track [Page 14] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[14ページ]。
2.10. Structure of Management Information
2.10. 経営情報の構造
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules.
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。
It is the purpose of a Structure of Management Information document to establish the notation for defining objects, modules, and other elements of managed information.
管理された情報のオブジェクトを定義する、モジュール、および他の要素のために記法を確立するのは、Management情報ドキュメントのStructureの目的です。
2.11. Textual Conventions
2.11. 原文のコンベンション
When designing a MIB module, it is often useful to define new types similar to those defined in the SMI, but with more precise semantics, or which have special semantics associated with them. These newly defined types are termed textual conventions, and may be defined in separate documents, or within a MIB module.
MIBモジュールを設計して、SMIで定義されたものと同様の新しいタイプを定義しますがより正確な意味論でしばしば役に立つか、または彼らに関連している特別な意味論を持っています。 これらの新たに定義されたタイプは、原文のコンベンションと呼ばれて、別々のドキュメントか、MIBモジュールの中で定義されるかもしれません。
2.12. Conformance Statements
2.12. 順応声明
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of the Conformance Statements document to define the notation used for these purposes.
実装の許容できる下界を定義するのは達成された実装の実際のレベルと共に役に立つかもしれません。 これらの目的に使用される記法を定義するのは、Conformance Statementsドキュメントの目的です。
2.13. Management Information Base Modules
2.13. 管理情報ベースモジュール
MIB documents describe collections of managed objects which instrument some aspect of a managed node.
MIBドキュメントは管理されたノードの何らかの局面に器具を取り付ける管理オブジェクトの収集について説明します。
2.13.1. SNMP Instrumentation MIBs
2.13.1. SNMP計装MIBs
An SNMP MIB document may define a collection of managed objects which instrument the SNMP protocol itself. In addition, MIB modules may be defined within the documents which describe portions of the SNMP architecture, such as the documents for Message processing Models, Security Models, etc. for the purpose of instrumenting those Models, and for the purpose of allowing their remote configuration.
SNMP MIBドキュメント自体はSNMPがそれの器具について議定書の中で述べる管理オブジェクトの収集を定義するかもしれません。 さらに、MIBモジュールはSNMPアーキテクチャの部分について説明するドキュメントの中に定義されるかもしれません、Message処理Modelsのためのドキュメント、それらのModelsに器具を取り付ける目的、および彼らのリモート構成を許す目的のためのSecurity Modelsなどのように。
2.14. SNMP Framework Documents
2.14. SNMPフレームワークドキュメント
This architecture is designed to allow an orderly evolution of portions of SNMP Frameworks.
このアーキテクチャは、SNMP Frameworksの一部の規則的な発展を許容するように設計されています。
Throughout the rest of this document, the term "subsystem" refers to an abstract and incomplete specification of a portion of a Framework, that is further refined by a model specification.
このドキュメントの残りの間中、「サブシステム」という用語はFrameworkの一部の抽象的で不完全な仕様を示して、それはモデル仕様でさらに精製されます。
Harrington, et al. Standards Track [Page 15] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[15ページ]。
A "model" describes a specific design of a subsystem, defining additional constraints and rules for conformance to the model. A model is sufficiently detailed to make it possible to implement the specification.
順応のための追加規制と規則をモデルと定義して、「モデル」はサブシステムの特定のデザインについて説明します。 モデルについて仕様を履行するのを可能にするほど詳述します。
An "implementation" is an instantiation of a subsystem, conforming to one or more specific models.
1つ以上の特定のモデルに従って、「実装」はサブシステムの具体化です。
SNMP version 1 (SNMPv1), is the original Internet-Standard Network Management Framework, as described in RFCs 1155, 1157, and 1212.
SNMPバージョン1(SNMPv1)、RFCs1155、1157、および1212に説明されて、元のインターネット規格はNetwork Management Frameworkです。
SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, and STD 62, RFCs 3416, 3417, and 3418. SNMPv2 has no message definition.
SNMPバージョン2(SNMPv2)はSNMPv1 Frameworkから派生するようにSNMPv2 Frameworkです。 それはSTD58、RFCs2578、2579、2580、STD62、RFCs3416、3417年、および3418年に説明されます。 SNMPv2には、メッセージ定義が全くありません。
The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP Framework which supplements the SNMPv2 Framework, as described in [RFC1901]. It adds the SNMPv2c message format, which is similar to the SNMPv1 message format.
CommunityベースのSNMPバージョン2(SNMPv2c)は補う実験的なSNMP Frameworkです。[RFC1901]で説明されるようなSNMPv2 Framework。 それはSNMPv2cメッセージ・フォーマットを加えます。(それは、SNMPv1メッセージ・フォーマットと同様です)。
SNMP version 3 (SNMPv3), is an extensible SNMP Framework which supplements the SNMPv2 Framework, by supporting the following:
SNMPバージョン3(SNMPv3) 以下をサポートすることによってSNMPv2 Frameworkを補う広げることができるSNMP Frameworkです:
- a new SNMP message format,
- 新しいSNMPメッセージ・フォーマット
- Security for Messages,
- メッセージのためのセキュリティ
- Access Control, and
- そしてコントロールにアクセスしてください。
- Remote configuration of SNMP parameters.
- SNMPパラメタのリモート構成。
Other SNMP Frameworks, i.e., other configurations of implemented subsystems, are expected to also be consistent with this architecture.
また、他のSNMP Frameworks(すなわち、実装しているサブシステムの他の構成)がこのアーキテクチャと一致させていると予想されます。
3. Elements of the Architecture
3. アーキテクチャのElements
This section describes the various elements of the architecture and how they are named. There are three kinds of naming:
このセクションはアーキテクチャとそれらがどう命名されるかに関する様々な要素について説明します。 3種類の命名があります:
1) the naming of entities,
1) 実体の命名
2) the naming of identities, and
そして2) アイデンティティの命名。
3) the naming of management information.
3) 経営情報の命名。
Harrington, et al. Standards Track [Page 16] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[16ページ]。
This architecture also defines some names for other constructs that are used in the documentation.
また、このアーキテクチャはドキュメンテーションで使用される他の構造物のためにいくつかの名前を定義します。
3.1. The Naming of Entities
3.1. 実体の命名
An SNMP entity is an implementation of this architecture. Each such SNMP entity consists of an SNMP engine and one or more associated applications.
SNMP実体はこのアーキテクチャの実装です。 そのようなそれぞれのSNMP実体はSNMPエンジンと1つ以上の関連するアプリケーションから成ります。
The following figure shows details about an SNMP entity and the components within it.
以下の図はそれの中にSNMP実体とコンポーネントに関する詳細を示しています。
+-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
+-------------------------------------------------------------------+ | SNMP実体| | | | +-------------------------------------------------------------+ | | | SNMPエンジン(snmpEngineIDによって特定されます)| | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | 発送者| | メッセージ| | セキュリティ| | アクセス| | | | | | | | 処理| | サブシステム| | コントロール| | | | | | | | サブシステム| | | | サブシステム| | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | アプリケーション| | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | コマンド| | 通知| | プロキシ| | | | | | ジェネレータ| | 受信機| | 混載業者| | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | コマンド| | 通知| | 他| | | | | | 応答者| | 創始者| | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
Harrington, et al. Standards Track [Page 17] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[17ページ]。
3.1.1. SNMP engine
3.1.1. SNMPエンジン
An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is a one-to-one association between an SNMP engine and the SNMP entity which contains it.
メッセージを認証して、暗号化して、管理オブジェクトへのアクセスを制御して、SNMPエンジンはメッセージの送受信のためのサービスを提供します。 SNMPエンジンとそれを含むSNMP実体との1〜1つの協会があります。
The engine contains:
エンジンは以下を含んでいます。
1) a Dispatcher,
1) 発送者
2) a Message Processing Subsystem,
2) メッセージ処理サブシステム
3) a Security Subsystem, and
そして3) セキュリティサブシステム。
4) an Access Control Subsystem.
4) アクセス制御サブシステム。
3.1.1.1. snmpEngineID
3.1.1.1. snmpEngineID
Within an administrative domain, an snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one-to- one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain. Note that it is possible for SNMP entities in different administrative domains to have the same value for snmpEngineID. Federation of administrative domains may necessitate assignment of new values.
管理ドメインの中では、snmpEngineIDはSNMPエンジンのユニークで明白な識別子です。 SNMPエンジンとSNMP実体との1〜1つの協会があるので、それはその管理ドメインの中で唯一も、明白にSNMP実体を特定します。 異なった管理ドメインのSNMP実体にはsnmpEngineIDのための同じ値があるのが、可能であることに注意してください。 管理ドメインの連邦は新しい値の課題を必要とするかもしれません。
3.1.1.2. Dispatcher
3.1.1.2. 発送者
There is only one Dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It does so by:
1DispatcherしかSNMPエンジンにありません。 それはSNMPエンジンでのSNMPメッセージの複数のバージョンの同時発生のサポートを考慮します。 それは以下でそうします。
- sending and receiving SNMP messages to/from the network,
- SNMPメッセージをネットワークからの/に送って、受け取ります。
- determining the version of an SNMP message and interacting with
the corresponding Message Processing Model,
- SNMPメッセージのバージョンを決定して、対応するMessage Processing Modelと対話します。
- providing an abstract interface to SNMP applications for
delivery of a PDU to an application.
- アプリケーションへのPDUの配送のSNMPアプリケーションに抽象的なインタフェースを提供します。
- providing an abstract interface for SNMP applications that
allows them to send a PDU to a remote SNMP entity.
- 抽象的なインタフェースをSNMPアプリケーションに提供して、それらはそれでリモートSNMP実体にPDUを送ることができます。
Harrington, et al. Standards Track [Page 18] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[18ページ]。
3.1.1.3. Message Processing Subsystem
3.1.1.3. メッセージ処理サブシステム
The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages.
Message Processing Subsystemは受信されたメッセージからデータを送って、抜粋するためにメッセージを準備するのに責任があります。
The Message Processing Subsystem potentially contains multiple Message Processing Models as shown in the next figure.
Message Processing Subsystemは次の図に示されるように潜在的に複数のMessage Processing Modelsを含んでいます。
* One or more Message Processing Models may be present.
* 1Message Processing Modelsが存在しているかもしれません。
+------------------------------------------------------------------+ | | | Message Processing Subsystem | | | | +------------+ +------------+ +------------+ +------------+ | | | * | | * | | * | | * | | | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | | | Message | | Message | | Message | | Message | | | | Processing | | Processing | | Processing | | Processing | | | | Model | | Model | | Model | | Model | | | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | | | メッセージ処理サブシステム| | | | +------------+ +------------+ +------------+ +------------+ | | | * | | * | | * | | * | | | | SNMPv3| | SNMPv1| | SNMPv2c| | 他| | | | メッセージ| | メッセージ| | メッセージ| | メッセージ| | | | 処理| | 処理| | 処理| | 処理| | | | モデル| | モデル| | モデル| | モデル| | | | | | | | | | | | | +------------+ +------------+ +------------+ +------------+ | | | +------------------------------------------------------------------+
3.1.1.3.1. Message Processing Model
3.1.1.3.1. メッセージ処理モデル
Each Message Processing Model defines the format of a particular version of an SNMP message and coordinates the preparation and extraction of each such version-specific message format.
各Message Processing ModelはSNMPメッセージの特定のバージョンの書式を定義して、そのようなそれぞれのバージョン特有のメッセージ・フォーマットの準備と抽出を調整します。
Harrington, et al. Standards Track [Page 19] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[19ページ]。
3.1.1.4. Security Subsystem
3.1.1.4. セキュリティサブシステム
The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models as shown in the following figure
Security Subsystemはメッセージの認証やプライバシーなどのセキュリティー・サービスを提供して、以下の図に示されるように潜在的に複数のSecurity Modelsを含んでいます。
* One or more Security Models may be present.
* 1Security Modelsが存在しているかもしれません。
+------------------------------------------------------------------+ | | | Security Subsystem | | | | +----------------+ +-----------------+ +-------------------+ | | | * | | * | | * | | | | User-Based | | Other | | Other | | | | Security | | Security | | Security | | | | Model | | Model | | Model | | | | | | | | | | | +----------------+ +-----------------+ +-------------------+ | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | | | セキュリティサブシステム| | | | +----------------+ +-----------------+ +-------------------+ | | | * | | * | | * | | | | ユーザベースです。| | 他| | 他| | | | セキュリティ| | セキュリティ| | セキュリティ| | | | モデル| | モデル| | モデル| | | | | | | | | | | +----------------+ +-----------------+ +-------------------+ | | | +------------------------------------------------------------------+
3.1.1.4.1. Security Model
3.1.1.4.1. 機密保護モデル
A Security Model specifies the threats against which it protects, the goals of its services, and the security protocols used to provide security services such as authentication and privacy.
Security Modelはそれが保護される脅威、サービスの目標、および認証やプライバシーなどのセキュリティー・サービスを提供するのに使用されるセキュリティプロトコルを指定します。
3.1.1.4.2. Security Protocol
3.1.1.4.2. セキュリティプロトコル
A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security service such as authentication or privacy.
Securityプロトコルは認証かプライバシーなどのセキュリティー・サービスを提供するのに用いられたメカニズム、手順、およびMIBオブジェクトを指定します。
Harrington, et al. Standards Track [Page 20] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[20ページ]。
3.1.2. Access Control Subsystem
3.1.2. アクセス制御サブシステム
The Access Control Subsystem provides authorization services by means of one or more (*) Access Control Models.
Access Control Subsystemは1(*)アクセスControl Modelsによって承認サービスを提供します。
+------------------------------------------------------------------+ | | | Access Control Subsystem | | | | +---------------+ +-----------------+ +------------------+ | | | * | | * | | * | | | | View-Based | | Other | | Other | | | | Access | | Access | | Access | | | | Control | | Control | | Control | | | | Model | | Model | | Model | | | | | | | | | | | +---------------+ +-----------------+ +------------------+ | | | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | | | アクセス制御サブシステム| | | | +---------------+ +-----------------+ +------------------+ | | | * | | * | | * | | | | 視点ベースです。| | 他| | 他| | | | アクセス| | アクセス| | アクセス| | | | コントロール| | コントロール| | コントロール| | | | モデル| | モデル| | モデル| | | | | | | | | | | +---------------+ +-----------------+ +------------------+ | | | +------------------------------------------------------------------+
3.1.2.1. Access Control Model
3.1.2.1. アクセス制御モデル
An Access Control Model defines a particular access decision function in order to support decisions regarding access rights.
Access Control Modelは、アクセス権に関する決定をサポートするために特定のアクセス決定関数を定義します。
3.1.3. Applications
3.1.3. アプリケーション
There are several types of applications, including:
である:いくつかのタイプの利用があります。
- command generators, which monitor and manipulate management
data,
- ジェネレータを命令してください。(ジェネレータは、管理データをモニターして、操ります)。
- command responders, which provide access to management data,
- 応答者を命令してください。(その応答者は、管理データへのアクセスを提供します)。
- notification originators, which initiate asynchronous messages,
- 通知創始者。(その創始者は非同期なメッセージを開始します)。
- notification receivers, which process asynchronous messages,
- 通知受信機。(その受信機は非同期なメッセージを処理します)。
and
そして
- proxy forwarders, which forward messages between entities.
- プロキシ混載業者。(その混載業者は実体の間にメッセージを転送します)。
These applications make use of the services provided by the SNMP engine.
これらのアプリケーションはSNMPエンジンによって提供されたサービスを利用します。
Harrington, et al. Standards Track [Page 21] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[21ページ]。
3.1.3.1. SNMP Manager
3.1.3.1. SNMPマネージャ
An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager.
1つ以上のコマンドジェネレータ、そして/または、通知受信側アプリケーション(それらの関連SNMPエンジンに伴う)を含むSNMP実体は伝統的にSNMPマネージャと呼ばれました。
(traditional SNMP manager)
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g., RFC 3417) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | | * One or more models may be present.
v v v
+------------------------------+
| Network |
+------------------------------+
(伝統的なSNMPマネージャ) +-------------------------------------------------------------------+ | +--------------+ +--------------+ +--------------+ SNMP実体| | | 通知| | 通知| | コマンド| | | | 創始者| | 受信機| | ジェネレータ| | | | アプリケーション| | アプリケーション| | アプリケーション| | | +--------------+ +--------------+ +--------------+ | | ^ ^ ^ | | | | | | | v vに対して| | +-------+--------+-----------------+ | | ^ | | | +---------------------+ +----------------+ | | | | メッセージ処理| | セキュリティ| | | 発送者v| サブシステム| | サブシステム| | | +-------------------+ | +------------+ | | | | | | PDU発送者| | +->| v1MP*| <、-、--、>| +------------+ | | | | | | | +------------+ | | | 他| | | | | | | | +------------+ | | | セキュリティ| | | | | | | +->| v2cMP*| <、-、--、>|、| モデル| | | | | メッセージ| | | +------------+ | | +------------+ | | | | 発送者<。--------->+| | | | | | | | | +------------+ | | +------------+ | | | | | | +->| v3MP*| <、-、--、>|、| ユーザベースです。| | | | | 輸送| | | +------------+ | | | セキュリティ| | | | | マッピング| | | +------------+ | | | モデル| | | | | (例えば、RFC3417) | | +->| otherMP*| <、-、--、>| +------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +----------------+ | | | | | v| +-------------------------------------------------------------------+ +-----+ +-----+ +-------+ | UDP| | IPX| . . . | 他| +-----+ +-----+ +-------+ ^ ^ ^ | | | * 1つか以上がプレゼントvがvであったかもしれない対+ならモデル化されます。------------------------------+ | ネットワーク| +------------------------------+
Harrington, et al. Standards Track [Page 22] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[22ページ]。
3.1.3.2. SNMP Agent
3.1.3.2. SNMPエージェント
An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine) has traditionally been called an SNMP agent.
1人以上のコマンド応答者、そして/または、通知創始者アプリケーション(それらの関連SNMPエンジンに伴う)を含むSNMP実体は伝統的にSNMPエージェントと呼ばれました。
Harrington, et al. Standards Track [Page 23] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[23ページ]。
* One or more models may be present.
* 1つ以上のモデルが出席しているかもしれません。
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g., RFC 3417) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
+------------------------------+ | ネットワーク| +------------------------------+ ^ ^ ^ | | | v対+に-----+ +-----+ +-------+ | UDP| | IPX| . . . | 他| +-----+ +-----+ +-------+ (伝統的なSNMPエージェント)+-------------------------------------------------------------------+ | ^ | | | +---------------------+ +----------------+ | | | | メッセージ処理| | セキュリティ| | | 発送者v| サブシステム| | サブシステム| | | +-------------------+ | +------------+ | | | | | | 輸送| | +->| v1MP*| <、-、--、>| +------------+ | | | | マッピング| | | +------------+ | | | 他| | | | | (例えば、RFC3417) | | | +------------+ | | | セキュリティ| | | | | | | +->| v2cMP*| <、-、--、>|、| モデル| | | | | メッセージ| | | +------------+ | | +------------+ | | | | 発送者<。--------->| +------------+ | | +------------+ | | | | | | +->| v3MP*| <、-、--、>|、| ユーザベースです。| | | | | | | | +------------+ | | | セキュリティ| | | | | PDU発送者| | | +------------+ | | | モデル| | | | +-------------------+ | +->| otherMP*| <、-、--、>| +------------+ | | | ^ | +------------+ | | | | | | +---------------------+ +----------------+ | | v| | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v vに対して| | +-------------+ +---------+ +--------------+ +-------------+ | | | コマンド| | アクセス| | 通知| | プロキシ| | | | 応答者| <->| コントロール| <->| 創始者| | 混載業者| | | | アプリケーション| | | | アプリケーション| | アプリケーション| | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | vに対して| | +----------------------------------------------+ | | | MIB計装| SNMP実体| +-------------------------------------------------------------------+
Harrington, et al. Standards Track [Page 24] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[24ページ]。
3.2. The Naming of Identities
3.2. アイデンティティの命名
principal
^
|
|
+----------------------------|-------------+
| SNMP engine v |
| +--------------+ |
| | | |
| +-----------------| securityName |---+ |
| | Security Model | | | |
| | +--------------+ | |
| | ^ | |
| | | | |
| | v | |
| | +------------------------------+ | |
| | | | | |
| | | Model | | |
| | | Dependent | | |
| | | Security ID | | |
| | | | | |
| | +------------------------------+ | |
| | ^ | |
| | | | |
| +-------------------------|----------+ |
| | |
| | |
+----------------------------|-------------+
|
v
network
主要な^| | +----------------------------|-------------+ | SNMPエンジンv| | +--------------+ | | | | | | +-----------------| securityName|---+ | | | 機密保護モデル| | | | | | +--------------+ | | | | ^ | | | | | | | | | v| | | | +------------------------------+ | | | | | | | | | | | モデル| | | | | | 扶養家族| | | | | | セキュリティID| | | | | | | | | | | +------------------------------+ | | | | ^ | | | | | | | | +-------------------------|----------+ | | | | | | | +----------------------------|-------------+ | vネットワーク
3.2.1. Principal
3.2.1. 主体
A principal is the "who" on whose behalf services are provided or processing takes place.
元本はだれのものを利益サービスを提供するか、または処理が取るかの「だれ」場所であるか。
A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof.
元本は特に特定の役割で行動している個人であるかもしれません。 特定の役割における各芝居をもっている1セットの個人。 アプリケーションかアプリケーションのセット。 そして、それの組み合わせ。
3.2.2. securityName
3.2.2. securityName
A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model.
securityNameは元本の代理をする人間の読み込み可能なストリングです。 それは、モデルから独立している形式を持って、特定のSecurity Modelの外で使用できます。
Harrington, et al. Standards Track [Page 25] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[25ページ]。
3.2.3. Model-dependent security ID
3.2.3. モデル依存するセキュリティID
A model-dependent security ID is the model-specific representation of a securityName within a particular Security Model.
モデル依存するセキュリティIDは特定のSecurity Modelの中のsecurityNameのモデル特有の表現です。
Model-dependent security IDs may or may not be human readable, and have a model-dependent syntax. Examples include community names, and user names.
モデル依存するセキュリティIDは、人間読み込み可能であり、モデル依存する構文を持っているかもしれません。 例は共同体名、およびユーザ名を含んでいます。
The transformation of model-dependent security IDs into securityNames and vice versa is the responsibility of the relevant Security Model.
securityNamesへのモデル依存するセキュリティIDの変換は逆もまた同様に関連Security Modelの責任です。
3.3. The Naming of Management Information
3.3. 経営情報の命名
Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. This application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine.
Command Responder Applicationがどこに潜在的に複数の文脈に地方のアクセスを持っているかという経営情報はSNMP実体であります。 このアプリケーションは関連SNMPエンジンのsnmpEngineIDと等しいcontextEngineIDを使用します。
Harrington, et al. Standards Track [Page 26] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[26ページ]。
+-----------------------------------------------------------------+ | SNMP entity (identified by snmpEngineID, for example: | | '800002b804616263'H (enterpise 696, string "abc") | | | | +------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | Command Responder Application | | | | (contextEngineID, example: '800002b804616263'H) | | | | | | | | example contextNames: | | | | | | | | "bridge1" "bridge2" "" (default) | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | other MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | SNMP実体、(例えば、snmpEngineIDによって特定されます; | | | | | | | | | | 例のcontextNames; | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | other MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+
Harrington, et al. Standards Track [Page 27] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[27ページ]。
3.3.1. An SNMP Context
3.3.1. SNMP文脈
An SNMP context, or just "context" for short, is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts.
SNMP文脈、またはまさしく略して「文脈」がSNMP実体によってアクセス可能な経営情報の収集です。 経営情報の項目は1つ以上の文脈に存在するかもしれません。 SNMP実体は潜在的に多くの文脈に近づく手段を持っています。
Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within a management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices, but a context is always defined as a subset of a single SNMP entity. Thus, in order to identify an individual item of management information within the management domain, its contextName and contextEngineID must be identified in addition to its object type and its instance.
管理ドメインの中に通常、それぞれの管理オブジェクトタイプの多くのインスタンスがあります。 簡単さのために、MIBモジュールで指定されたインスタンスを特定するためのメソッドは、各インスタンスが管理ドメインの中のすべてのインスタンスのセットの中で区別されるのを許容しません。 むしろ、それは管理ドメインの中に各いくらかの範囲だけの中で特定されるべきインスタンスかある「文脈」複数のそのようなものに文脈を許容します。 しばしば、文脈は、フィジカル・デバイス、または恐らく論理的なデバイスです、また、文脈が複数のデバイスを取り囲むことができますか、または単一のデバイスの部分集合、または複数のデバイスの部分集合さえ、しかし、文脈がいつもただ一つのSNMP実体の部分集合と定義されますが。 したがって、管理ドメインの中で経営情報の個別品目を特定するために、オブジェクト・タイプとそのインスタンスに加えてそのcontextNameとcontextEngineIDを特定しなければなりません。
For example, the managed object type ifDescr [RFC2863], is defined as
the description of a network interface. To identify the description
of device-X's first network interface, four pieces of information are
needed: the snmpEngineID of the SNMP entity which provides access to
the management information at device-X, the contextName (device-X),
the managed object type (ifDescr), and the instance ("1").
例えば、管理オブジェクトは、ifDescr[RFC2863]をタイプして、ネットワーク・インターフェースの記述と定義されます。 デバイスXの最初のネットワーク・インターフェースの記述を特定するために、情報の4つの断片が必要です: デバイスX、contextName(デバイスX)、管理オブジェクトタイプ(ifDescr)、およびインスタンスで経営情報へのアクセスを提供するSNMP実体のsnmpEngineID、(「1インチ)」
Each context has (at least) one unique identification within the management domain. The same item of management information can exist in multiple contexts. An item of management information may have multiple unique identifications. This occurs when an item of management information exists in multiple contexts, and this also occurs when a context has multiple unique identifications.
各文脈は管理ドメインの中に(少なくとも)1つのユニークな識別を持っています。 経営情報の同じ項目は複数の文脈に存在できます。 経営情報の項目には、複数のユニークな識別があるかもしれません。 経営情報の項目が複数の文脈に存在していると、これは起こります、そして、また、文脈に複数のユニークな識別があるとき、起こります。
The combination of a contextEngineID and a contextName unambiguously identifies a context within an administrative domain; note that there may be multiple unique combinations of contextEngineID and contextName that unambiguously identify the same context.
contextEngineIDとcontextNameの組み合わせは管理ドメインの中で明白に文脈を特定します。 明白に同じ文脈を特定するcontextEngineIDとcontextNameの複数のユニークな組み合わせがあるかもしれないことに注意してください。
3.3.2. contextEngineID
3.3.2. contextEngineID
Within an administrative domain, a contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.
管理ドメインの中では、contextEngineIDは唯一特定のcontextNameと共に文脈のインスタンスがわかるかもしれないSNMP実体を特定します。
Harrington, et al. Standards Track [Page 28] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[28ページ]。
3.3.3. contextName
3.3.3. contextName
A contextName is used to name a context. Each contextName MUST be unique within an SNMP entity.
contextNameは、文脈を命名するのに使用されます。 それぞれのcontextNameはSNMP実体の中でユニークであるに違いありません。
3.3.4. scopedPDU
3.3.4. scopedPDU
A scopedPDU is a block of data containing a contextEngineID, a contextName, and a PDU.
scopedPDUはcontextEngineID、contextName、およびPDUを含む1ブロックのデータです。
The PDU is an SNMP Protocol Data Unit containing information named in the context which is unambiguously identified within an administrative domain by the combination of the contextEngineID and the contextName. See, for example, RFC 3416 for more information about SNMP PDUs.
PDUは管理ドメインの中でcontextEngineIDとcontextNameの組み合わせで明白に特定される文脈で指定された情報を含むSNMPプロトコルData Unitです。 SNMP PDUsに関する詳しい情報に関して例えばRFC3416を見てください。
3.4. Other Constructs
3.4. 他の構造物
3.4.1. maxSizeResponseScopedPDU
3.4.1. maxSizeResponseScopedPDU
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that a PDU's sender would be willing to accept. Note that the size of a scopedPDU does not include the size of the SNMP message header.
maxSizeResponseScopedPDUはPDUの送付者が受け入れても構わないと思っているscopedPDUの最大サイズです。 scopedPDUのサイズがSNMPメッセージヘッダーのサイズを含んでいないことに注意してください。
3.4.2. Local Configuration Datastore
3.4.2. 地方の構成Datastore
The subsystems, models, and applications within an SNMP entity may need to retain their own sets of configuration information.
SNMP実体の中のサブシステム、モデル、およびアプリケーションは、それら自身の設定情報のセットを保有する必要があるかもしれません。
Portions of the configuration information may be accessible as managed objects.
設定情報の部分は管理オブジェクトとしてアクセスしやすいかもしれません。
The collection of these sets of information is referred to as an entity's Local Configuration Datastore (LCD).
これらのセットの情報の収集は実体のLocal Configuration Datastore(LCD)と呼ばれます。
3.4.3. securityLevel
3.4.3. securityLevel
This architecture recognizes three levels of security:
このアーキテクチャは3つのレベルのセキュリティを認識します:
- without authentication and without privacy (noAuthNoPriv)
- 認証とプライバシー(noAuthNoPriv)
- with authentication but without privacy (authNoPriv)
- 認証にもかかわらず、プライバシー(authNoPriv)
- with authentication and with privacy (authPriv)
- 認証とプライバシー(authPriv)
Harrington, et al. Standards Track [Page 29] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[29ページ]。
These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv.
これらの3つの値が命令されるのでnoAuthNoPrivがauthNoPriv以下であり、authNoPrivはauthPriv以下です。
Every message has an associated securityLevel. All Subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing the message and its contents.
あらゆるメッセージには、関連securityLevelがあります。 すべてのSubsystems(メッセージProcessing、Security、Access Control)とアプリケーションはsecurityLevelの値を供給するか、またはメッセージとそのコンテンツを処理している間にsecurityLevelの供給値を守るREQUIREDです。
4. Abstract Service Interfaces
4. 抽象的なサービスインタフェース
Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. The abstract service interfaces are intended to help clarify the externally observable behavior of SNMP entities, and are not intended to constrain the structure or organization of implementations in any way. Most specifically, they should not be interpreted as APIs or as requirements statements for APIs.
抽象的なサービスインタフェースは、SNMP実体の中で様々なサブシステムの間の概念的なインタフェースについて説明するために定義されました。 抽象的なサービスインタフェースは、SNMP実体の外部的に観察可能な振舞いをはっきりさせるのを助けることを意図して、何らかの方法で実装の構造か組織を抑制することを意図しません。 最も明確に、APIとして、または、APIのための要件声明としてそれらを解釈するべきではありません。
These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that are to be passed when the services are invoked. This section lists the primitives that have been defined for the various subsystems.
これらの抽象的なサービスインタフェースは提供されたサービスを定義する1セットの基関数とサービスが呼び出されるとき渡されることになっている抽象的なデータ要素によって定義されます。 このセクションは様々なサブシステムのために定義された基関数をリストアップします。
4.1. Dispatcher Primitives
4.1. 発送者基関数
The Dispatcher typically provides services to the SNMP applications via its PDU Dispatcher. This section describes the primitives provided by the PDU Dispatcher.
DispatcherはPDU Dispatcherを通してSNMPアプリケーションに対するサービスを通常提供します。 このセクションはPDU Dispatcherによって提供された基関数について説明します。
Harrington, et al. Standards Track [Page 30] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[30ページ]。
4.1.1. Generate Outgoing Request or Notification
4.1.1. 送信する要求か通知を生成してください。
The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity:
PDU Dispatcherはアプリケーションが別のSNMP実体にSNMP RequestかNotificationを送るためには原始の以下を提供します:
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
statusInformation=--、sendPduHandle、成功であるなら--errorIndication、失敗sendPduです。(IN transportDomain--中古のIN messageProcessingModelになるようにアドレスを輸送してください--通常、SNMPバージョンIN securityModel--この主要なIN securityLevelを代表してIN securityNameを使用するセキュリティModel--Securityのレベルがこのような関係においては/IN pduVersionからIN contextEngineID--この実体IN contextNameの/からのデータ--データを要求したという中古のIN transportAddress PDU IN PDUのバージョン--SNMPプロトコルData Unit IN expectResponse--TRUEかFALSEになるようにドメインを輸送します)
4.1.2. Process Incoming Request or Notification PDU
4.1.2. 入って来る要求か通知PDUを処理してください。
The PDU Dispatcher provides the following primitive to pass an incoming SNMP PDU to an application:
PDU Dispatcherは入って来るSNMP PDUをアプリケーションに渡すためには原始の以下を提供します:
processPdu( -- process Request/Notification PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
) -- needed when sending a response
processPdu; (--この主要なIN securityLevelを代表したIN securityNameが平らにするSecurity IN contextEngineIDの使用--このSNMP実体IN contextNameの/からのデータ--このような関係においては/IN pduVersion--PDU IN PDUのバージョン--SNMPプロトコルData Unit IN maxSizeResponseScopedPDUからのデータ--Response PDU IN stateReferenceの最大サイズ--参照でRequest/通知PDU IN messageProcessingModel--通常SNMPバージョンIN securityModel--セキュリティModelを処理する、情報を述べてください); -- 応答を送るとき、必要です。
Harrington, et al. Standards Track [Page 31] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[31ページ]。
4.1.3. Generate Outgoing Response
4.1.3. 外向的な応答を生成してください。
The PDU Dispatcher provides the following primitive for an application to return an SNMP Response PDU to the PDU Dispatcher:
PDU DispatcherはアプリケーションがSNMP Response PDUをPDU Dispatcherに返すためには原始の以下を提供します:
result = -- SUCCESS or FAILURE
returnResponsePdu(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size sender can accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
) -- error counter OID/value if error
結果=; 成否; returnResponsePdu; ( IN messageProcessingModel--通常、セキュリティModelが中でこの主要なIN securityLevelを代表してIN securityNameを使用するという入来と同じSNMPバージョンIN securityModelはこのような関係においては/IN pduVersionからIN contextEngineID--このSNMP実体IN contextNameの/からのデータ--データを要求します; 要求IN statusInformationを与える場合最大サイズ送付者がIN stateReference(情報を述べる参照)を認めることができるPDU IN PDU(SNMPプロトコルData Unit IN maxSizeResponseScopedPDU)のバージョン--成功かerrorIndication; ) -- 誤りは誤りであるならOID/値を打ち返します。
4.1.4. Process Incoming Response PDU
4.1.4. 入って来る応答PDUを処理してください。
The PDU Dispatcher provides the following primitive to pass an incoming SNMP Response PDU to an application:
PDU Dispatcherは入って来るSNMP Response PDUをアプリケーションに渡すためには原始の以下を提供します:
processResponsePdu( -- process Response PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN statusInformation -- success or errorIndication
IN sendPduHandle -- handle from sendPdu
)
processResponsePdu(--この主要なIN securityLevel--Security IN contextEngineIDのレベル--このSNMP実体IN contextNameの/からのデータ--このような関係においては/IN pduVersionからのデータ--PDU IN PDUのバージョン--SNMPプロトコルData Unit IN statusInformation--成功かerrorIndication IN sendPduHandleを代表したIN securityNameがsendPduから扱う使用でResponse PDU IN messageProcessingModel--通常SNMPバージョンIN securityModel--セキュリティModelを処理してください)
4.1.5. Registering Responsibility for Handling SNMP PDUs
4.1.5. 取り扱いSNMP PDUsへの登録責任
Applications can register/unregister responsibility for a specific contextEngineID, for specific pduTypes, with the PDU Dispatcher according to the following primitives. The list of particular pduTypes that an application can register for is determined by the Message Processing Model(s) supported by the SNMP entity that contains the PDU Dispatcher.
アプリケーションは特定のcontextEngineID、特定のpduTypesへの以下の基関数に従ったPDU Dispatcherがあるレジスタ/「非-レジスタ」責任をそうすることができます。 アプリケーションが登録できる特定のpduTypesのリストはPDU Dispatcherを含むSNMP実体によってサポートされたMessage Processing Model(s)によって決定されます。
Harrington, et al. Standards Track [Page 32] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[32ページ]。
statusInformation = -- success or errorIndication
registerContextEngineID(
IN contextEngineID -- take responsibility for this one
IN pduType -- the pduType(s) to be registered
)
statusInformation=--成功かerrorIndication registerContextEngineID(IN contextEngineID--この1IN pduTypeへの責任を取ってください--登録されるべきpduType(s))
unregisterContextEngineID(
IN contextEngineID -- give up responsibility for this one
IN pduType -- the pduType(s) to be unregistered
)
unregisterContextEngineID(IN contextEngineID--この1IN pduTypeへの責任をあきらめてください--登録されていないpduType(s))
Note that realizations of the registerContextEngineID and unregisterContextEngineID abstract service interfaces may provide implementation-specific ways for applications to register/deregister responsibility for all possible values of the contextEngineID or pduType parameters.
registerContextEngineIDとunregisterContextEngineIDの抽象的なサービスインタフェースの実現がcontextEngineIDかpduTypeパラメタのすべての可能な値へのレジスタ/「反-レジスタ」責任にアプリケーションのための実装特有の方法を提供するかもしれないことに注意してください。
4.2. Message Processing Subsystem Primitives
4.2. メッセージ処理サブシステム基関数
The Dispatcher interacts with a Message Processing Model to process a specific version of an SNMP Message. This section describes the primitives provided by the Message Processing Subsystem.
Dispatcherは、SNMP Messageの特定のバージョンを処理するためにMessage Processing Modelと対話します。 このセクションはMessage Processing Subsystemによって提供された基関数について説明します。
4.2.1. Prepare Outgoing SNMP Request or Notification Message
4.2.1. 送信するSNMP要求か通知メッセージを用意してください。
The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Request or Notification Message:
Message Processing Subsystemは出発しているSNMP RequestかNotification Messageを準備するのにおける、原始のこのサービスを提供します:
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
-- incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
statusInformation=--成功かerrorIndication prepareOutgoingMessage( IN transportDomain--中古のIN transportAddressになるようにドメインを輸送してください--中古のIN messageProcessingModelになるようにアドレスを輸送してください--通常、SNMPバージョンIN securityModel--この主要なIN securityLevelを代表してIN securityNameを使用するセキュリティModel--Securityのレベルはこのような関係においては/IN pduVersionからIN contextEngineID--この実体IN contextNameの/からのデータ--データを要求しました; PDU IN PDUのバージョン--SNMPプロトコルData Unit IN expectResponse--TRUEかFALSE IN sendPduHandle--マッチングのためのハンドル--入って来る応答OUT destTransportDomain--目的地輸送ドメインOUT destTransportAddress--目的地輸送アドレスOUT outgoingMessage--OUT outgoingMessageLengthを送るメッセージ--その長さ; )
Harrington, et al. Standards Track [Page 33] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[33ページ]。
4.2.2. Prepare an Outgoing SNMP Response Message
4.2.2. 外向的なSNMP応答メッセージを用意してください。
The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Response Message:
Message Processing Subsystemは出発しているSNMP Response Messageを準備するのにおける、原始のこのサービスを提供します:
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- same as on incoming request
IN securityName -- same as on incoming request
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size able to accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
結果=--SUCCESSかFAILURE prepareResponseMessage( 通常、入って来る要求IN securityNameと同じ入来と同じSNMPバージョンIN securityModelがIN securityLevelを要求するという入来と同じIN messageProcessingModelはこのような関係においては/IN pduVersion--PDU IN PDUのバージョン--SNMPプロトコルData Unit IN maxSizeResponseScopedPDUからIN contextEngineID--このSNMP実体IN contextNameの/からのデータ--データを要求します; 誤りOUT destTransportDomain--目的地輸送ドメインOUT destTransportAddress--目的地輸送アドレスOUT outgoingMessage--OUT outgoingMessageLengthを送るメッセージ--長さであるなら要求IN statusInformation--成功かerrorIndication--誤りカウンタOID/価値を与えるので、IN stateReference(情報を述べる参照)を受け入れることができる最大サイズ; )
Harrington, et al. Standards Track [Page 34] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[34ページ]。
4.2.3. Prepare Data Elements from an Incoming SNMP Message
4.2.3. 入って来るSNMPメッセージからデータ要素を用意してください。
The Message Processing Subsystem provides this service primitive for preparing the abstract data elements from an incoming SNMP message:
Message Processing Subsystemは入って来るSNMPメッセージから抽象的なデータ要素を準備するのにおける、原始のこのサービスを提供します:
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)
結果=--SUCCESSかerrorIndication prepareDataElements( IN transportDomain--OUT securityNameを使用するためにネットワークOUT messageProcessingModel--通常SNMPバージョンOUT securityModel--セキュリティModelから受け取るようにこの主要なOUT securityLevelを代表してネットワークIN wholeMsgLengthから受け取られる発生源輸送ドメインIN transportAddress(発生源輸送アドレスIN wholeMsg)--SecurityのレベルはOUT contextEngineIDを要求しました--この実体OUT contextNameの/からのデータ; このような関係においては/OUT pduVersionからのデータ--PDU OUT PDUのバージョン--SNMP PDUがOUT sendPduHandleをタイプするというSNMPプロトコルData Unit OUT pduTypeは最大サイズ送付者が誤りOUT stateReferenceであるならOUT statusInformation--成功かerrorIndication--誤りカウンタOID/価値を受け入れることができるという取り組んでいる要求OUT maxSizeResponseScopedPDUのために州の情報に参照を扱います--可能なResponseに使用されるために; )
4.3. Access Control Subsystem Primitives
4.3. アクセス制御サブシステム基関数
Applications are the typical clients of the service(s) of the Access Control Subsystem.
アプリケーションはAccess Control Subsystemのサービスの典型的なクライアントです。
The following primitive is provided by the Access Control Subsystem to check if access is allowed:
以下の基関数はアクセスが許されているかどうかチェックするためにAccess Control Subsystemによって提供されます:
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)
statusInformation=--成功かerrorIndication isAccessAllowed(IN securityModel(IN securityName(IN securityLevelにアクセスすることでありたい主体)が平らにするSecurity IN viewTypeの使用でのセキュリティModel)は管理オブジェクトのために視点IN contextName--variableName IN variableNameを含む文脈--OIDに読むか、書くか、または通知します)
Harrington, et al. Standards Track [Page 35] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[35ページ]。
4.4. Security Subsystem Primitives
4.4. セキュリティサブシステム基関数
The Message Processing Subsystem is the typical client of the services of the Security Subsystem.
Message Processing SubsystemはSecurity Subsystemのサービスの典型的なクライアントです。
4.4.1. Generate a Request or Notification Message
4.4.1. 要求か通知メッセージを生成してください。
The Security Subsystem provides the following primitive to generate a Request or Notification message:
Security SubsystemはRequestかNotificationメッセージを生成するためには原始の以下を提供します:
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
statusInformationはgenerateRequestMsgと等しいです。( IN messageProcessingModel--送信されるメッセージIN securityEngineIDのための送付SNMP実体IN securityModelの通常SNMPバージョンIN globalData(メッセージヘッダー、アドミンデータIN maxMessageSize)--正式のSNMP実体IN securityName; この主要なIN securityLevel--Securityの要求されたIN scopedPDU--メッセージ(平文)ペイロードOUT securityParameters(Security Module OUT wholeMsgによって記入される)の完全な発生しているメッセージOUT wholeMsgLengthのレベル--発生しているメッセージの長さを代表して; )
4.4.2. Process Incoming Message
4.4.2. 入力メッセージを処理してください。
The Security Subsystem provides the following primitive to process an incoming message:
Security Subsystemは入力メッセージを処理するためには原始の以下を提供します:
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
statusInformation=--errorIndicationか成功; 誤りは誤りであるならOID/値を打ち返します; processIncomingMsg、(受信されたメッセージIN securityModel、ワイヤIN wholeMsgLength--ワイヤOUT securityEngineIDに受け取られる長さ--正式のSNMP実体OUT securityName--主要なOUT scopedPDUの識別--メッセージに受け取られる受信されたメッセージIN securityLevel(Security IN wholeMsgのレベル)のためのIN messageProcessingModel(送付SNMP実体IN securityParametersの通常SNMPバージョンIN maxMessageSize)、(平文; )、最大サイズ送付者がOUT securityStateReferenceを扱うことができるというOUT maxSizeResponseScopedPDUがセキュリティ状態に参照をつけるペイロード); -- 情報; 応答に必要です。
Harrington, et al. Standards Track [Page 36] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[36ページ]。
4.4.3. Generate a Response Message
4.4.3. 応答メッセージを生成してください。
The Security Subsystem provides the following primitive to generate a Response message:
Security SubsystemはResponseメッセージを生成するためには原始の以下を提供します:
statusInformation =
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
statusInformationはgenerateResponseMsgと等しいです。( IN messageProcessingModel--通常SNMPバージョンIN globalData--メッセージヘッダー(この主要なIN securityLevelを代表した送信されるメッセージIN securityEngineID(正式のSNMP実体IN securityName)のための送付SNMP実体IN securityModelのアドミンデータIN maxMessageSize); 送信されるメッセージIN scopedPDU--メッセージ(平文)ペイロードIN securityStateReference--Security Module OUT wholeMsg--完全な発生しているメッセージOUT wholeMsgLength--発生しているメッセージの長さによって記入されたセキュリティ状態(オリジナルの要求OUT securityParametersからの情報)の参照のために; )
4.5. Common Primitives
4.5. 一般的な基関数
These primitive(s) are provided by multiple Subsystems.
原始の(s)が複数のSubsystemsによって提供されるこれら。
4.5.1. Release State Reference Information
4.5.1. リリース州の参考情報
All Subsystems which pass stateReference information also provide a primitive to release the memory that holds the referenced state information:
また、情報をstateReferenceに通過するすべてのSubsystemsが参照をつけられた州の情報を保持するメモリを発表するために基関数を提供します:
stateRelease(
IN stateReference -- handle of reference to be released
)
stateRelease(IN stateReference--リリースされるべき参照のハンドル)
Harrington, et al. Standards Track [Page 37] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[37ページ]。
4.6. Scenario Diagrams
4.6. シナリオダイヤグラム
4.6.1. Command Generator or Notification Originator
4.6.1. コマンドジェネレータか通知創始者
This diagram shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application.
このダイヤグラムは、Command GeneratorかNotification Originatorアプリケーションが、PDUが送られるようどのように要求するか、そして、応答がどのようにそのアプリケーションに返されるかを(非同期に)示します。
Command Dispatcher Message Security Generator | Processing Model | | Model | | sendPdu | | | |------------------->| | | | | prepareOutgoingMessage | | : |----------------------->| | : | | generateRequestMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | : | | | : |------------------+ | | : | Send SNMP | | | : | Request Message | | | : | to Network | | | : | v | | : : : : : : : : : : : : : : : : | | | | : | Receive SNMP | | | : | Response Message | | | : | from Network | | | : |<-----------------+ | | : | | | : | prepareDataElements | | : |----------------------->| | : | | processIncomingMsg | : | |-------------------->| : | | | : | |<--------------------| : | | | : |<-----------------------| | | processResponsePdu | | | |<-------------------| | | | | | |
コマンド発送者メッセージセキュリティジェネレータ| 処理モデル| | モデル| | sendPdu| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| prepareOutgoingMessage| | : |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : | | generateRequestMsg| : | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| : | | | : | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| : | | | : | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : | | | : |------------------+ | | : | SNMPを送ってください。| | | : | 要求メッセージ| | | : | ネットワークに| | | : | v| | : : : : : : : : : : : : : : : : | | | | : | SNMPを受けてください。| | | : | 応答メッセージ| | | : | ネットワークから| | | : | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | : | | | : | prepareDataElements| | : |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : | | processIncomingMsg| : | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| : | | | : | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| : | | | : | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| processResponsePdu| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|
Harrington, et al. Standards Track [Page 38] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[38ページ]。
4.6.2. Scenario Diagram for a Command Responder Application
4.6.2. コマンド応答者アプリケーションのためのシナリオダイヤグラム
This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after an SNMP message is received, and how the Response is (asynchronously) send back to the network.
このダイヤグラムはpduTypeを扱うためのCommand ResponderかNotification Receiverアプリケーションレジスタと、ResponseがSNMPメッセージが受信されていた後にPDUがどうアプリケーションに派遣されるか、そして、どうあるかが(非同期に)どうネットワークを送り返すかを示しています。
Command Dispatcher Message Security Responder | Processing Model | | Model | | | | | | registerContextEngineID | | | |------------------------>| | | |<------------------------| | | | | | Receive SNMP | | | : | Message | | | : | from Network | | | : |<-------------+ | | : | | | : |prepareDataElements | | : |------------------->| | : | | processIncomingMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | | processPdu | | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu | | | |------------------------>| | | : | prepareResponseMsg | | : |------------------->| | : | |generateResponseMsg | : | |------------------->| : | | | : | |<-------------------| : | | | : |<-------------------| | : | | | : |--------------+ | | : | Send SNMP | | | : | Message | | | : | to Network | | | : | v | |
コマンド発送者のメッセージセキュリティ応答者| 処理モデル| | モデル| | | | | | registerContextEngineID| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| SNMPを受けてください。| | | : | メッセージ| | | : | ネットワークから| | | : | <、-、-、-、-、-、-、-、-、-、-、-、--+ | | : | | | : |prepareDataElements| | : |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : | | processIncomingMsg| : | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| : | | | : | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| : | | | : | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| processPdu| | | |<------------------------| | | | | | | : : : : : : : : | returnResponsePdu| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| : | prepareResponseMsg| | : |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| : | |generateResponseMsg| : | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| : | | | : | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| : | | | : | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| : | | | : |--------------+ | | : | SNMPを送ってください。| | | : | メッセージ| | | : | ネットワークに| | | : | v| |
Harrington, et al. Standards Track [Page 39] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[39ページ]。
5. Managed Object Definitions for SNMP Management Frameworks
5. SNMP管理フレームワークのための管理オブジェクト定義
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
SNMPフレームワークMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
SNMPv2-CONFからのSNMPv2-Tcモジュールコンプライアンス、オブジェクトグループからの原文のコンベンションのSNMPv2-SMIからモジュールアイデンティティ、オブジェクト・タイプ、オブジェクトアイデンティティ、snmpModulesをインポートします。
snmpFrameworkMIB MODULE-IDENTITY
LAST-UPDATED "200210140000Z"
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com
Subscribe: snmpv3-request@lists.tislabs.com
snmpFrameworkMIBモジュールアイデンティティは「以下をWGメールしてください」という"200210140000Z"組織「SNMPv3作業部会」コンタクトインフォメーションをアップデートしました。 snmpv3@lists.tislabs.com は申し込まれます: snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
EMail: mundy@tislabs.com
phone: +1 301-947-7107
共同議長: ラスマンディNetwork Associates研究所、郵便: 15204オメガドライブ、Suite300ロックビル、MD20850-4601米国はメールされます: mundy@tislabs.com 電話: +1 301-947-7107
Co-Chair &
Co-editor: David Harrington
Enterasys Networks
postal: 35 Industrial Way
P. O. Box 5005
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
phone: +1 603-337-2614
共同議長と共同エディタ: デヴィッドハリントンEnterasys Networks郵便: 35の産業方法、私書箱5005ニューハンプシャー03866-5005ロチェスター(米国)はメールされます: dbh@enterasys.com 電話: +1 603-337-2614
Co-editor: Randy Presuhn
BMC Software, Inc.
postal: 2141 North First Street
San Jose, California 95131
USA
EMail: randy_presuhn@bmc.com
phone: +1 408-546-1006
共同エディタ: ランディPresuhn BMC Software Inc.郵便: 2141北に、最初に、通りカリフォルニア95131サンノゼ(米国)はメールされます: randy_presuhn@bmc.com 電話: +1 408-546-1006
Co-editor: Bert Wijnen
Lucent Technologies
postal: Schagen 33
3461 GL Linschoten
Netherlands
共同エディタ: バートWijnenルーセントテクノロジーズ郵便: Schagen33 3461GLリンスホーテン・オランダ
Harrington, et al. Standards Track [Page 40] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[40ページ]。
EMail: bwijnen@lucent.com
phone: +31 348-680-485
"
DESCRIPTION "The SNMP Management Architecture MIB
メール: bwijnen@lucent.com 電話: +31 348-680-485、「記述、「SNMP管理体系MIB」
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3411;
see the RFC itself for full legal notices.
"
Copyright(C)インターネット協会(2002)。 このMIBモジュールのこのバージョンはRFC3411の一部です。 完全な法定の通知に関してRFC自身を見てください。 "
REVISION "200210140000Z" -- 14 October 2002
DESCRIPTION "Changes in this revision:
- Updated various administrative information.
- Corrected some typos.
- Corrected typo in description of SnmpEngineID
that led to range overlap for 127.
- Changed '255a' to '255t' in definition of
SnmpAdminString to align with current SMI.
- Reworded 'reserved' for value zero in
DESCRIPTION of SnmpSecurityModel.
- The algorithm for allocating security models
should give 256 per enterprise block, rather
than 255.
- The example engine ID of 'abcd' is not
legal. Replaced with '800002b804616263'H based
on example enterprise 696, string 'abc'.
- Added clarification that engineID should
persist across re-initializations.
This revision published as RFC 3411.
"
REVISION "199901190000Z" -- 19 January 1999
DESCRIPTION "Updated editors' addresses, fixed typos.
Published as RFC 2571.
"
REVISION "199711200000Z" -- 20 November 1997
DESCRIPTION "The initial version, published in RFC 2271.
"
::= { snmpModules 10 }
REVISION"200210140000Z"--2002年10月14日の記述は「この改正で以下を変えます」。 - 様々な管理情報をアップデートしました。 - いくつかの誤植を修正しました。 - 127のための範囲オーバラップに通じたSnmpEngineIDの記述における直っている誤植。 - 現在のSMIに並べるSnmpAdminStringの定義における'255への変えられた'255a't'。 - '予約されていた'状態で、SnmpSecurityModelの記述における値ゼロのために言い換えられます。 - 機密保護モデルを割り当てるためのアルゴリズムは255よりむしろ企業ブロックあたり256を与えるべきです。 - 'abcd'の例のエンジンIDは法的ではありません。 '例の企業696、ストリング'abc'に基づいたH。''800002b804616263に取り替えて、 - engineIDが再初期化処理の向こう側に固持するはずである明確化を加えました。 この改正はRFC3411として発行されました。 「"REVISION"199901190000Z」--1999年1月19日の記述は「エディタのアドレス、固定誤植をアップデートしました」。 RFC2571として、発行されます。 「"REVISION"199711200000Z」--「初期のバージョンであって、RFC2271で発行された」1997年11月20日の記述。 " ::= snmpModules10
-- Textual Conventions used in the SNMP Management Architecture ***
-- SNMP Management Architecture***で使用される原文のConventions
SnmpEngineID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.
SnmpEngineID:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「SNMPエンジンの行政上ユニークな識別子。」 このタイプのオブジェクトはアドレシングではなく、識別のためのものです、アドレスが特定の価値の世代に使用されたのが、可能ですが。
Harrington, et al. Standards Track [Page 41] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[41ページ]。
The value for this object may not be all zeros or
all 'ff'H or the empty (zero length) string.
そうであるというわけではありません。
The initial value for this object may be configured
via an operator console entry or via an algorithmic
function. In the latter case, the following
example algorithm is recommended.
このオブジェクトのための初期の値はオペレータコンソールエントリーを通ってアルゴリズムの機能で構成されるかもしれません。 後者の場合では、以下の例のアルゴリズムはお勧めです。
In cases where there are multiple engines on the
same system, the use of this algorithm is NOT
appropriate, as it would result in all of those
engines ending up with the same ID value.
同じシステムの上に複数のエンジンがある場合では、このアルゴリズムの使用は適切ではありません、それらのエンジンのすべての結果が同じID値で終わって、そうするように。
1) The very first bit is used to indicate how the
rest of the data is composed.
1) 最初に非常に噛み付かれるのは、データの残りがどう落ち着いているかを示すのに使用されます。
0 - as defined by enterprise using former methods
that existed before SNMPv3. See item 2 below.
0--前のメソッドを使用することで企業によって定義されるように、それはSNMPv3の前に存在しました。 以下の項目2を見てください。
1 - as defined by this architecture, see item 3
below.
1--このアーキテクチャによって定義されるように、以下の項目3を見てください。
Note that this allows existing uses of the
engineID (also known as AgentID [RFC1910]) to
co-exist with any new uses.
engineID(また、AgentID[RFC1910]として、知られている)の既存の用途がこれでどんな新しい用途とも共存できることに注意してください。
2) The snmpEngineID has a length of 12 octets.
2) snmpEngineIDには、12の八重奏の長さがあります。
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
インターネットAssigned民数記Authority(IANA)によって割り当てられるように最初の4つの八重奏がエージェントのSNMP管理私企業番号の2進の同等物に設定されます。 例えば、Acme Networksが企業696に配属されたなら、'000002b8'H'は最初の4つの八重奏に割り当てられるでしょう。
The remaining eight octets are determined via
one or more enterprise-specific methods. Such
methods must be designed so as to maximize the
possibility that the value of this object will
be unique in the agent's administrative domain.
For example, it may be the IP address of the SNMP
entity, or the MAC address of one of the
interfaces, with each address suitably padded
with random octets. If multiple methods are
defined, then it is recommended that the first
octet indicate the method being used and the
remaining octets be a function of the method.
残っている8つの八重奏が1つ以上の企業特有のメソッドで決定しています。 このオブジェクトの値がエージェントの管理ドメインでユニークになる可能性を最大にするようにそのようなメソッドを設計しなければなりません。 例えば、それは、SNMP実体のIPアドレス、またはインタフェースの1つのMACアドレスであるかもしれません、各アドレスが無作為の八重奏で適当に水増しされている状態で。 複数のメソッドが定義されるなら、最初の八重奏が、使用されるメソッドと残っている八重奏がメソッドの機能であることを示すのは、お勧めです。
Harrington, et al. Standards Track [Page 42] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[42ページ]。
3) The length of the octet string varies.
3) 八重奏ストリングの長さは異なります。
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
インターネットAssigned民数記Authority(IANA)によって割り当てられるように最初の4つの八重奏がエージェントのSNMP管理私企業番号の2進の同等物に設定されます。 例えば、Acme Networksが企業696に配属されたなら、'000002b8'H'は最初の4つの八重奏に割り当てられるでしょう。
The very first bit is set to 1. For example, the
above value for Acme Networks now changes to be
'800002b8'H.
最初に非常に噛み付かれるのは1に設定されます。 例えば、Acme Networksのための上の値は、現在、'800002b8'H'になるように変化します。
The fifth octet indicates how the rest (6th and
following octets) are formatted. The values for
the fifth octet are:
5番目の八重奏は残り(6番目の、そして、次の八重奏)がどうフォーマットされるかを示します。 5番目の八重奏のための値は以下の通りです。
0 - reserved, unused.
0--予約されていて、未使用です。
1 - IPv4 address (4 octets)
lowest non-special IP address
1--IPv4は、(4つの八重奏)が最も低い非特別なIPアドレスであると扱います。
2 - IPv6 address (16 octets)
lowest non-special IP address
2--IPv6は、(16の八重奏)が最も低い非特別なIPアドレスであると扱います。
3 - MAC address (6 octets)
lowest IEEE MAC address, canonical
order
3--MACは、(6つの八重奏)が最も低いIEEE MACアドレス、正準なオーダーであると扱います。
4 - Text, administratively assigned
Maximum remaining length 27
4--テキスト、長さ27のままで残っている行政上割り当てられたMaximum
5 - Octets, administratively assigned
Maximum remaining length 27
5--八重奏は行政上長さ27のままで残っているMaximumを割り当てました。
6-127 - reserved, unused
予約されて、未使用の6-127
128-255 - as defined by the enterprise
Maximum remaining length 27
"
SYNTAX OCTET STRING (SIZE(5..32))
128-255、長さ27の「構文八重奏ストリング」のままで残っている企業Maximumによって定義されます。(サイズ(5 .32))
Harrington, et al. Standards Track [Page 43] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[43ページ]。
SnmpSecurityModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a
Security Model of the Security Subsystem within
this SNMP Management Architecture.
SnmpSecurityModel:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このSNMP Management Architectureの中で唯一Security SubsystemのSecurity Modelを特定する識別子。」
The values for securityModel are allocated as
follows:
以下の通りsecurityModelのための値を割り当てます:
- The zero value does not identify any particular
security model.
- 少しの特定の機密保護モデルも特定しませんゼロが、評価する。
- Values between 1 and 255, inclusive, are reserved
for standards-track Security Models and are
managed by the Internet Assigned Numbers Authority
(IANA).
- Values greater than 255 are allocated to
enterprise-specific Security Models. An
enterprise-specific securityModel value is defined
to be:
- 1と255の間の包括的な値は、標準化過程Security Modelsのために予約されて、インターネットAssigned民数記Authority(IANA)によって管理されます。 - 企業特有のSecurity Modelsに値より多くの255を割り当てます。 企業特有のsecurityModel値は、である:なるように定義されます。
enterpriseID * 256 + security model within
enterprise
企業の中のenterpriseID*256+機密保護モデル
For example, the fourth Security Model defined by
the enterprise whose enterpriseID is 1 would be
259.
例えば、enterpriseIDが1である企業によって定義された第4Security Modelは259歳でしょう。
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
256 Security Models per enterprise.
securityModel値の配分が最大255の規格を考慮するので、この体系は、Security Modelsを基礎づけて、1企業あたり最大256Security Modelsのためにそうしました。
It is believed that the assignment of new
securityModel values will be rare in practice
because the larger the number of simultaneously
utilized Security Models, the larger the
chance that interoperability will suffer.
Consequently, it is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
同時に利用されたSecurity Modelsの数が大きければ大きいほど、その相互運用性が受ける機会が、より大きいので、新しいsecurityModel値の課題が実際にはまれになると信じられています。 その結果、そのような範囲が十分であると信じられています。 規格委員会が時間がたつにつれて不十分になるようにこの数を見つけるありそうもないイベントでは、256の追加可能な値を得るために企業番号を割り当てることができます。
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
最も重要なビットがゼロであるに違いないというメモ。 したがって、設計して、定義する様々な組織のために割り当てられた23ビットがある、標準的でなさ
Harrington, et al. Standards Track [Page 44] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[44ページ]。
securityModels. This limits the ability to
define new proprietary implementations of Security
Models to the first 8,388,608 enterprises.
securityModels。 これはSecurity Modelsの新しい独占実装を最初の838万8608の企業と定義する能力を制限します。
It is worthwhile to note that, in its encoded
form, the securityModel value will normally
require only a single byte since, in practice,
the leftmost bits will be zero for most messages
and sign extension is suppressed by the encoding
rules.
コード化されたフォームで一番左ビットがほとんどのメッセージのために実際にはゼロになるので通常、securityModel値が1バイトだけを必要として、符号拡張が符号化規則で抑圧されることに注意する価値があります。
As of this writing, there are several values
of securityModel defined for use with SNMP or
reserved for use with supporting MIB objects.
They are as follows:
この書くこと現在、使用のためにSNMPと共に定義されるか、または使用のためにMIBにオブジェクトを支えるのに予約されたsecurityModelのいくつかの値があります。 それらは以下の通りです:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)
"
SYNTAX INTEGER(0 .. 2147483647)
0 'any'の1のために予約されていた状態で予約されて、SNMPv1 2はSNMPv2c3ベースのUser Security Model(USM)のために「構文整数」を予約しました。(0 .. 2147483647)
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within this SNMP Management Architecture.
SnmpMessageProcessingModel:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「このSNMP Management Architectureの中で唯一Message Processing SubsystemのMessage Processing Modelを特定する識別子。」
The values for messageProcessingModel are
allocated as follows:
以下の通りmessageProcessingModelのための値を割り当てます:
- Values between 0 and 255, inclusive, are
reserved for standards-track Message Processing
Models and are managed by the Internet Assigned
Numbers Authority (IANA).
- 0と255の間の包括的な値は、標準化過程Message Processing Modelsのために予約されて、インターネットAssigned民数記Authority(IANA)によって管理されます。
- Values greater than 255 are allocated to
enterprise-specific Message Processing Models.
An enterprise messageProcessingModel value is
defined to be:
- 企業特有のMessage Processing Modelsに値より多くの255を割り当てます。 企業messageProcessingModel価値は、である:なるように定義されます。
enterpriseID * 256 +
messageProcessingModel within enterprise
企業の中のenterpriseID*256+messageProcessingModel
For example, the fourth Message Processing Model
defined by the enterprise whose enterpriseID
例えば、Message Processing Modelが企業で定義した4番目 enterpriseID
Harrington, et al. Standards Track [Page 45] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[45ページ]。
is 1 would be 259.
1が259であるだろうということです。
This scheme for allocating messageProcessingModel
values allows for a maximum of 255 standards-
based Message Processing Models, and for a
maximum of 256 Message Processing Models per
enterprise.
値をmessageProcessingModelに割り当てると最大255の規格が考慮されるので、この体系は、Message Processing Modelsを基礎づけて、1企業あたり最大256Message Processing Modelsのためにそうしました。
It is believed that the assignment of new
messageProcessingModel values will be rare
in practice because the larger the number of
simultaneously utilized Message Processing Models,
the larger the chance that interoperability
will suffer. It is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
同時に利用されたMessage Processing Modelsの数が大きければ大きいほど、その相互運用性が受ける機会が、より大きいので、新しいmessageProcessingModel値の課題が実際にはまれになると信じられています。 そのような範囲が十分であると信じられています。 規格委員会が時間がたつにつれて不十分になるようにこの数を見つけるありそうもないイベントでは、256の追加可能な値を得るために企業番号を割り当てることができます。
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
messageProcessingModels. This limits the ability
to define new proprietary implementations of
Message Processing Models to the first 8,388,608
enterprises.
最も重要なビットがゼロであるに違いないというメモ。 したがって、様々な組織が標準的でないmessageProcessingModelsを設計して、定義するように割り当てられた23ビットがあります。 これはMessage Processing Modelsの新しい独占実装を最初の838万8608の企業と定義する能力を制限します。
It is worthwhile to note that, in its encoded
form, the messageProcessingModel value will
normally require only a single byte since, in
practice, the leftmost bits will be zero for
most messages and sign extension is suppressed
by the encoding rules.
コード化されたフォームで一番左ビットがほとんどのメッセージのために実際にはゼロになるので通常、messageProcessingModel値が1バイトだけを必要として、符号拡張が符号化規則で抑圧されることに注意する価値があります。
As of this writing, there are several values of
messageProcessingModel defined for use with SNMP.
They are as follows:
この書くこと現在、SNMPとの使用のために定義されたmessageProcessingModelのいくつかの値があります。 それらは以下の通りです:
0 reserved for SNMPv1
1 reserved for SNMPv2c
2 reserved for SNMPv2u and SNMPv2*
3 reserved for SNMPv3
"
SYNTAX INTEGER(0 .. 2147483647)
0 SNMPv2cのために予約されたSNMPv1 1のために予約されて、2はSNMPv2uとSNMPv2のためにSNMPv3「構文整数」のために予約された*3を予約しました。(0 .. 2147483647)
Harrington, et al. Standards Track [Page 46] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[46ページ]。
SnmpSecurityLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:
SnmpSecurityLevel:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「SNMPメッセージを送ることができるか、または操作が処理されているSecurityのLevel」。 特に1、:
noAuthNoPriv - without authentication and
without privacy,
authNoPriv - with authentication but
without privacy,
authPriv - with authentication and
with privacy.
noAuthNoPriv--認証なしでプライバシーにもかかわらず、認証があるauthNoPrivにもかかわらず、認証とプライバシーがあるプライバシーのないauthPrivなしで。
These three values are ordered such that
noAuthNoPriv is less than authNoPriv and
authNoPriv is less than authPriv.
"
SYNTAX INTEGER { noAuthNoPriv(1),
authNoPriv(2),
authPriv(3)
}
これらの3つの値が命令されるのでnoAuthNoPrivがauthNoPriv以下であり、authNoPrivはauthPriv以下です。 「構文整数」noAuthNoPriv(1)、authNoPriv(2)、authPriv(3)
SnmpAdminString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255t"
STATUS current
DESCRIPTION "An octet string containing administrative
information, preferably in human-readable form.
SnmpAdminString:、:= TEXTUAL-CONVENTION DISPLAY-ヒント、「255 「望ましくは人間読み込み可能なフォームに管理情報を含んでいて、八重奏は結ぶ」t」STATUSの現在の記述。
To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].
国際化を容易にするために、この情報は表された使用ISO/IECが八重奏ストリングとして[RFC2279]で説明されたUTF-8変換形式を使用することでコード化された10646-1文字集合であるということです。
Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.
追加コード・ポイントが10646規格の修正で時々加えられるので、0×00000000から0x7fffffffまであらゆるコード・ポイントに遭遇するように実装を準備しなければなりません。 コード・ポイントの有効なUTF-8コード化に対応していないか、またはこの範囲の外にあるバイト列は禁止されています。
The use of control codes should be avoided.
制御コードの使用は避けられるべきです。
When it is necessary to represent a newline,
the control code sequence CR LF should be used.
ニューラインを表すのが必要であるときに、制御コード系列CR LFは使用されるべきです。
Harrington, et al. Standards Track [Page 47] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[47ページ]。
The use of leading or trailing white space should
be avoided.
主であるか引きずっている余白の使用は避けられるべきです。
For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.
ユーザーインタフェースハードウェアかソフトウェアによって直接サポートされなかったコード・ポイントにおいて、エントリーの代替の手段と16進などのディスプレイを提供するかもしれません。
For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.
7ビットの米国-ASCIIでコード化された情報に関しては、UTF-8コード化は米国-ASCIIコード化と同じです。
UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded. Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.
UTF-8は1キャラクタ/コード・ポイントを表すために複数のバイトを必要とするかもしれません。 したがって、八重奏における、このオブジェクトの長さはコード化されたキャラクタの数と異なっているかもしれません。 同様に、サイズ規制はコード化で代理をされたキャラクタの数ではなく、コード化された八重奏の数について言及します。
Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].
このTCが使用されるために使用されるか、または思い描かれるオブジェクトに使用されたらどんなオブジェクトインスタンスのためのサブ識別子の数もインデックス、次に、SIZE制限を指定しなければならないので128の限界を超えないように、それに注意してください、[RFC3416]によって定義されるように。
Note that the size of an SnmpAdminString object is
measured in octets, not characters.
"
SYNTAX OCTET STRING (SIZE (0..255))
SnmpAdminStringオブジェクトのサイズがキャラクタではなく、八重奏で測定されることに注意してください。 「構文八重奏ストリング」(サイズ(0 .255))
-- Administrative assignments ***************************************
-- 管理課題***************************************
snmpFrameworkAdmin
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
snmpFrameworkAdminオブジェクト識別子:、:= snmpFrameworkMIB1snmpFrameworkMIBObjectsオブジェクト識別子:、:= snmpFrameworkMIB2snmpFrameworkMIBConformanceオブジェクト識別子:、:= snmpFrameworkMIB3
-- the snmpEngine Group ********************************************
-- snmpEngineグループ********************************************
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
snmpEngineオブジェクト識別子:、:= snmpFrameworkMIBObjects1
Harrington, et al. Standards Track [Page 48] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[48ページ]。
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineIDのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「SNMPエンジンの行政上ユニークな識別子。」
This information SHOULD be stored in non-volatile
storage so that it remains constant across
re-initializations of the SNMP engine.
"
::= { snmpEngine 1 }
この情報SHOULD、非揮発性記憶装置で、SNMPエンジンの再初期化処理の向こう側に一定のままで残るように保存されてください。 " ::= snmpEngine1
snmpEngineBoots OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the SNMP engine has
(re-)initialized itself since snmpEngineID
was last configured.
"
::= { snmpEngine 2 }
snmpEngineBoots OBJECT-TYPE SYNTAX INTEGER(1 .2147483647)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「SNMPエンジンが持っている回数、(再、)、snmpEngineIDが最後に構成されて以来それ自体を初期化する、」 " ::= snmpEngine2
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the value of
the snmpEngineBoots object last changed.
When incrementing this object's value would
cause it to exceed its maximum,
snmpEngineBoots is incremented as if a
re-initialization had occurred, and this
object's value consequently reverts to zero.
"
::= { snmpEngine 3 }
「snmpEngineBootsオブジェクトの値以来の秒数は最後に変えた」snmpEngineTime OBJECT-TYPE SYNTAX INTEGER(0 .2147483647)UNITS「秒」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 オブジェクトのこのものを増加するとき、値で最大を超えているでしょう、そして、まるで再初期化が起こったかのようにsnmpEngineBootsは増加されています、そして、その結果、このオブジェクトの値はゼロに戻ります。 " ::= snmpEngine3
snmpEngineMaxMessageSize OBJECT-TYPE
SYNTAX INTEGER (484..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.
"
::= { snmpEngine 4 }
snmpEngineMaxMessageSize OBJECT-TYPE SYNTAX INTEGER(484 .2147483647)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「SNMPメッセージの八重奏におけるこのSNMPエンジンが送るか、または受けることができる最大の長さと輸送のすべて中でエンジンによって利用可能でサポートされた状態でサポートされた最大のメッセージサイズ値の最小限として決定するプロセス。」 " ::= snmpEngine4
Harrington, et al. Standards Track [Page 49] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[49ページ]。
-- Registration Points for Authentication and Privacy Protocols **
-- 認証のための登録ポイントとプライバシープロトコル**
snmpAuthProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.
"
::= { snmpFrameworkAdmin 1 }
「標準化過程認証プロトコルのための登録ポイントはSNMP Management Frameworksで使用した」snmpAuthProtocols OBJECT-IDENTITY STATUSの現在の記述。 " ::= snmpFrameworkAdmin1
snmpPrivProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.
"
::= { snmpFrameworkAdmin 2 }
「標準化過程プライバシープロトコルのための登録ポイントはSNMP Management Frameworksで使用した」snmpPrivProtocols OBJECT-IDENTITY STATUSの現在の記述。 " ::= snmpFrameworkAdmin2
-- Conformance information ******************************************
-- 順応情報******************************************
snmpFrameworkMIBCompliances
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
snmpFrameworkMIBCompliancesオブジェクト識別子:、:= snmpFrameworkMIBConformance1snmpFrameworkMIBGroupsオブジェクト識別子:、:= snmpFrameworkMIBConformance2
-- compliance statements
-- 承諾声明
snmpFrameworkMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP Management Framework MIB.
"
MODULE -- this module
MANDATORY-GROUPS { snmpEngineGroup }
snmpFrameworkMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「SNMP Management Framework MIBを実装するSNMPエンジンのための承諾声明。」 「MODULE--、このモジュールMANDATORY-GROUPS、」snmpEngineGroup
::= { snmpFrameworkMIBCompliances 1 }
::= snmpFrameworkMIBCompliances1
-- units of conformance
-- ユニットの順応
snmpEngineGroup OBJECT-GROUP
OBJECTS {
snmpEngineID,
snmpEngineBoots,
snmpEngineTime,
snmpEngineMaxMessageSize
}
STATUS current
DESCRIPTION "A collection of objects for identifying and
determining the configuration and current timeliness
snmpEngineGroup OBJECT-GROUP OBJECTS、snmpEngineID、snmpEngineBoots、snmpEngineTime、snmpEngineMaxMessageSize、STATUSの現在の記述、「構成と現在のタイムリーさであるのを特定して、決定するためのオブジェクトの収集」
Harrington, et al. Standards Track [Page 50] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[50ページ]。
values of an SNMP engine.
"
::= { snmpFrameworkMIBGroups 1 }
SNMPエンジンの値。 " ::= snmpFrameworkMIBGroups1
END
終わり
6. IANA Considerations
6. IANA問題
This document defines three number spaces administered by IANA, one for security models, another for message processing models, and a third for SnmpEngineID formats.
このドキュメントはIANA、機密保護モデルのためのもの、メッセージ処理モデルのための別のもの、およびSnmpEngineID形式のための3分の1までに管理された3つの数の空間を定義します。
6.1. Security Models
6.1. 機密保護モデル
The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are in the range from 0 to 255 inclusive, and are reserved for standards-track Security Models. If this range should in the future prove insufficient, an enterprise number can be allocated to obtain an additional 256 possible values.
IANAによって管理されたSnmpSecurityModel TEXTUAL-CONVENTION値は、0〜255まで包括的な範囲にあって、標準化過程Security Modelsのために予約されます。 この範囲が将来不十分であると判明するなら、256の追加可能な値を得るために数を割り当てることができる企業です。
As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows:
この書くこと現在、使用のためにSNMPと共に定義されるか、または使用のためにMIBにオブジェクトを支えるのに予約されたsecurityModelのいくつかの値があります。 それらは以下の通りです:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)
0 'any'の1のために予約されていた状態で予約されて、SNMPv1 2はSNMPv2c3のためにベースのUser Security Modelを予約しました。(USM)
6.2. Message Processing Models
6.2. メッセージ処理モデル
The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by IANA are in the range 0 to 255, inclusive. Each value uniquely identifies a standards-track Message Processing Model of the Message Processing Subsystem within the SNMP Management Architecture.
IANAによって管理されたSnmpMessageProcessingModel TEXTUAL-CONVENTION値が範囲に0〜255にあります。包括的。 各値はSNMP Management Architectureの中で唯一Message Processing Subsystemの標準化過程Message Processing Modelを特定します。
Should this range prove insufficient in the future, an enterprise number may be obtained for the standards committee to get an additional 256 possible values.
この範囲が将来不十分であると判明するなら、規格委員会が256の追加可能な値を得るように、企業番号を得るかもしれません。
As of this writing, there are several values of messageProcessingModel defined for use with SNMP. They are as follows:
この書くこと現在、SNMPとの使用のために定義されたmessageProcessingModelのいくつかの値があります。 それらは以下の通りです:
0 reserved for SNMPv1
1 reserved for SNMPv2c
2 reserved for SNMPv2u and SNMPv2*
3 reserved for SNMPv3
0 SNMPv2cのために予約されたSNMPv1 1のために予約されて、2はSNMPv2uとSNMPv2のためにSNMPv3のために予約された*3を予約しました。
Harrington, et al. Standards Track [Page 51] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[51ページ]。
6.3. SnmpEngineID Formats
6.3. SnmpEngineID形式
The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format identifier. The values managed by IANA are in the range 6 to 127, inclusive. Each value uniquely identifies a standards-track SnmpEngineID format.
SnmpEngineID TEXTUAL-CONVENTIONの5番目の八重奏は形式IDを含んでいます。 IANAによって管理された値が範囲に6〜127にあります。包括的。 各値は唯一標準化過程SnmpEngineID形式を特定します。
7. Intellectual Property
7. 知的所有権
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 RFC 2028. 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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 RFC2028で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
8. Acknowledgements
8. 承認
This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members:
このドキュメントはSNMPv3作業部会の取り組みの結果です。 いくつかの特別な感謝がそうである、以下のSNMPv3 WGメンバー:
Harald Tveit Alvestrand (Maxware)
Dave Battle (SNMP Research, Inc.)
Alan Beard (Disney Worldwide Services)
Paul Berrevoets (SWI Systemware/Halcyon Inc.)
Martin Bjorklund (Ericsson)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
Mike Daniele (Compaq Computer Corporation)
T. Max Devlin (Eltrax Systems)
John Flick (Hewlett Packard)
Rob Frye (MCI)
Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
ハラルドTveit Alvestrand(Maxware)デーヴBattle(SNMP研究Inc.) アランBeard(ディズニーの世界的なServices)ポールBerrevoets(SWI Systemware/アルキュオーン株式会社) マーチンBjorklund(エリクソン)ユリ・ブルーメンソル(IBM T.J.ワトソン研究所) ジェフCase(SNMP研究Inc.) ジョン・カラン(BBN)・マイク・ダニエル(コンパックコンピュータ社)・T.マックス・デブリン(Eltraxシステム)ジョンFlick(ヒューレットパッカード)ロブフライ(MCI)ウェスHardaker(U.C.デイヴィス、情報技術--直流、A.S.)
Harrington, et al. Standards Track [Page 52] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[52ページ]。
David Harrington (Cabletron Systems Inc.)
Lauren Heintz (BMC Software, Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Michael Kirkham (InterWorking Labs, Inc.)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Joe Marzot (Nortel Networks)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Bob Moore (IBM)
Russ Mundy (TIS Labs at Network Associates)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reeder (TIS Labs at Network Associates)
David Reid (SNMP Research, Inc.)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Mike Thatcher (Independent Consultant)
Bert Wijnen (IBM T.J. Watson Research Center)
デヴィッド・ハリントン(CabletronシステムInc.) ローレン・ハインツ(BMCソフトウェアInc.) ノースカロライナ州Hien(IBM T.J.ワトソン研究所) マイケル・カーカム(研究室Inc.を織り込みます) デーヴ・レビ(SNMP研究Inc.) ルイスはMamakos(UUNET技術Inc.)です。 ジョーMarzot(ノーテルネットワーク)ポール・マイヤー(安全なコンピューティング社)キースMcCloghrie(シスコシステムズ)ボブ・ムーア(IBM)・ラス・マンディ(ネットワーク関連のTIS研究室)ボブNatale(ACE*COMM社)マイク・オデル(UUNET技術Inc.) デーヴ・パーキンス(DeskTalk)・ピーター・ポーキングホーン(Brunel大学)ランディPresuhn(BMCソフトウェアInc.) デヴィッド・リーダー(ネットワーク関連のTIS研究室)・デヴィッド・リード(SNMP研究Inc.) アレックセイ・ロマーノフ(上質の定足数)ショーンRouthier(エピローグ)ユルゲンSchoenwaelder(TUブラウンシュバイク)ボブ・スチュワート(シスコシステムズ)マイク屋根を葺く人(独立しているコンサルタント)バートWijnen(IBM T.J.ワトソン研究所)
The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were:
ドキュメントはSNMP Advisory TeamのためのIETF SecurityとAdministrative Framework Evolutionの推薦に基づいています。 そのAdvisory Teamのメンバーは以下の通りでした。
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
デヴィッド・ハリントン(CabletronシステムInc.) ジェフ・ジョンソン(シスコシステムズ)・デヴィッド・レビ(SNMP研究Inc.) ジョン・リン(Openvision)・ラス・マンディ(情報システムを信じる)いすショーンRouthier(エピローグ)グレンWaters(ノーテル)バートWijnen(IBM T.J.ワトソン研究所)
As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*:
Advisory TeamとSNMPv3作業部会憲章によって推薦されるように、デザインは前のRFCsと草稿によって実用的であるのと同じくらい多くを取り入れます。 その結果、特別な感謝はSNMPv2uとSNMPv2*として知られている前のデザインの作者のためです:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
ジェフCase(SNMP研究Inc.) デヴィッド・ハリントン(CabletronシステムInc.) デヴィッド・レビ(SNMP研究Inc.) キースMcCloghrie(シスコシステムズ)ブライアン・オキーフ(ヒューレットパッカード)
Harrington, et al. Standards Track [Page 53] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[53ページ]。
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング)ジョンSaperia(BGSシステムInc.) スティーブWaldbusser(国際ネットワークサービス)グレンW.水域(ベル-北研究株式会社)
9. Security Considerations
9. セキュリティ問題
This document describes how an implementation can include a Security Model to protect management messages and an Access Control Model to control access to management information.
このドキュメントは実装が経営情報へのアクセスを制御するために管理メッセージとAccess Control Modelを保護するためにどうSecurity Modelを含むことができるかを説明します。
The level of security provided is determined by the specific Security Model implementation(s) and the specific Access Control Model implementation(s) used.
提供されたセキュリティのレベルは実装が使用した特定のSecurity Model実装と特定のAccess Control Modelによって決定されます。
Applications have access to data which is not secured. Applications SHOULD take reasonable steps to protect the data from disclosure.
アプリケーションは保証されないデータに近づく手段を持っています。 アプリケーションSHOULDは、公開からデータを保護するために合理的な方法を採ります。
It is the responsibility of the purchaser of an implementation to ensure that:
それを確実にするのは、実装の購入者の責任です:
1) an implementation complies with the rules defined by this
architecture,
1) 実装はこのアーキテクチャによって定義される規則に応じます。
2) the Security and Access Control Models utilized satisfy the
security and access control needs of the organization,
2) 利用されたSecurityとAccess Control Modelsはコントロールが必要とする組織のセキュリティとアクセスを満たします。
3) the implementations of the Models and Applications comply with
the model and application specifications,
3) ModelsとApplicationsの実装はモデルとアプリケーション仕様に従います。
4) and the implementation protects configuration secrets from
inadvertent disclosure.
4)と実装は不注意な公開から構成秘密を保護します。
This document also contains a MIB definition module. None of the objects defined is writable, and the information they represent is not deemed to be particularly sensitive. However, if they are deemed sensitive in a particular environment, access to them should be restricted through the use of appropriately configured Security and Access Control models.
また、このドキュメントはMIB定義モジュールを含んでいます。 定義されたオブジェクトのいずれも書き込み可能ではありません、そして、彼らが表す情報が特に敏感であると考えられません。 しかしながら、それらが特定の環境で敏感であると考えられるなら、それらへのアクセスは適切に構成されたSecurityとAccess Controlモデルの使用で制限されるべきです。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Harrington, et al. Standards Track [Page 54] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[54ページ]。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3412] 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.
[RFC3412] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3413] レビとD.とマイヤーとP.とB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3413、2002年12月。
[RFC3414] 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.
[RFC3414] ブルーメンソル、U.、およびB.Wijnen、「簡単なネットワークマネージメントのバージョン3のためのユーザベースのセキュリティモデル(USM)は(SNMPv3)について議定書の中で述べます」、STD62、RFC3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3415] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Protocol Operations for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3416, December
2002.
[RFC3416]Presuhn(R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMP)のための操作について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
[RFC3417]Presuhn(R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMP)のためのマッピングを輸送します」、STD62、RFC3417、2002年12月。
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3418] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
Harrington, et al. Standards Track [Page 55] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[55ページ]。
10.2. Informative References
10.2. 有益な参照
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC1155] ローズ、M.、K.McCloghrie、および「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The
Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
for SNMPv2", RFC 1909, February 1996.
[RFC1909] McCloghrie、K.、エディタ、「SNMPv2"、RFC1909、1996年2月のための管理インフラストラクチャ。」
[RFC1910] Waters, G., Editor, "User-based Security Model for
SNMPv2", RFC 1910, February 1996.
[RFC1910] 水域、G.、エディタ、「SNMPv2"、RFC1910、1996年2月のためのユーザベースの機密保護モデル。」
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2028] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-Standard Network Management Framework",
RFC 2576, March 2000.
[RFC2576]フライとR.とレビとD.、RouthierとS.とB.Wijnen、「インターネット標準のネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」RFC2576(2000年3月)。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」RFC3410(2002年12月)。
Harrington, et al. Standards Track [Page 56] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[56ページ]。
Appendix A
付録A
A. Guidelines for Model Designers
A。 モデルデザイナーへのガイドライン
This appendix describes guidelines for designers of models which are expected to fit into the architecture defined in this document.
この付録は本書では定義されたアーキテクチャに収まると予想されるモデルのデザイナーのためにガイドラインについて説明します。
SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to provide trivial authentication and access control. SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed according to this architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks could be designed to meet the requirements of this architecture, but this document does not provide guidelines for that coexistence.
SNMPv1とSNMPv2cは些細な認証とアクセスコントロールを提供するのに共同体を使用する2つのSNMPフレームワークです。 SNMPv1とSNMPv2c Frameworksはこのアーキテクチャによると、設計されているFrameworksに共存できます、そして、このアーキテクチャに関する必要条件を満たすようにSNMPv1とSNMPv2c Frameworksの変更されたバージョンを設計できましたが、このドキュメントはその共存のためのガイドラインを供給しません。
Within any subsystem model, there should be no reference to any specific model of another subsystem, or to data defined by a specific model of another subsystem.
どんなサブシステムモデルの中にも、別のサブシステムのどんな特定のモデル、または別のサブシステムの特定のモデルによって定義されたデータについての言及も全くあるべきではありません。
Transfer of data between the subsystems is deliberately described as a fixed set of abstract data elements and primitive functions which can be overloaded to satisfy the needs of multiple model definitions.
サブシステムの間のデータ転送は故意に複数のモデル定義の需要を満たすために積みすぎることができる固定セットの抽象的なデータ要素と原始関数として記述されています。
Documents which define models to be used within this architecture SHOULD use the standard primitives between subsystems, possibly defining specific mechanisms for converting the abstract data elements into model-usable formats. This constraint exists to allow subsystem and model documents to be written recognizing common borders of the subsystem and model. Vendors are not constrained to recognize these borders in their implementations.
このアーキテクチャSHOULDの中で使用されるためにモデルを定義するドキュメントがサブシステムの間の標準の基関数を使用します、抽象的なデータ要素をモデル使用可能な形式に変換するためにことによると特定のメカニズムを定義して。 この規制は、サブシステムとモデルの一般的な境界を認識しながらサブシステムとモデルドキュメントが書かれているのを許容するために存在しています。 ベンダーがそれらの実装におけるこれらの境界を認識するのが抑制されません。
The architecture defines certain standard services to be provided between subsystems, and the architecture defines abstract service interfaces to request these services.
アーキテクチャはサブシステムの間に提供するためにある標準のサービスを定義します、そして、アーキテクチャはこれらのサービスを要求するために抽象的なサービスインタフェースを定義します。
Each model definition for a subsystem SHOULD support the standard service interfaces, but whether, or how, or how well, it performs the service is dependent on the model definition.
サブシステムSHOULDサポートのためのそれぞれのモデル定義、さて、実行するか、標準のサービスインタフェースにもかかわらず、またはそれがどのようにかどのようにサービスを実行するか、モデル定義での扶養家族はそうです。
A.1. Security Model Design Requirements
A.1。 機密保護モデル設計の品質
A.1.1. Threats
A.1.1。 脅威
A document describing a Security Model MUST describe how the model protects against the threats described under "Security Requirements of this Architecture", section 1.4.
Security Modelについて説明するドキュメントはモデルがどう「このArchitectureのセキュリティRequirements」の下で説明された脅威から守るかを説明しなければなりません、セクション1.4。
Harrington, et al. Standards Track [Page 57] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[57ページ]。
A.1.2. Security Processing
A.1.2。 セキュリティ処理
Received messages MUST be validated by a Model of the Security Subsystem. Validation includes authentication and privacy processing if needed, but it is explicitly allowed to send messages which do not require authentication or privacy.
Security SubsystemのModelは受信されたメッセージを有効にしなければなりません。 必要であるなら、合法化は認証とプライバシー処理を含んでいますが、それは明らかに認証かプライバシーを必要としないメッセージを送ることができます。
A received message contains a specified securityLevel to be used during processing. All messages requiring privacy MUST also require authentication.
受信されたメッセージは処理の間に使用されるべき指定されたsecurityLevelを含んでいます。 また、プライバシーを必要とするすべてのメッセージが認証を必要としなければなりません。
A Security Model specifies rules by which authentication and privacy are to be done. A model may define mechanisms to provide additional security features, but the model definition is constrained to using (possibly a subset of) the abstract data elements defined in this document for transferring data between subsystems.
Security Modelは行われる認証とプライバシーがことである規則を指定します。 モデルが追加担保機能を提供するためにメカニズムを定義するかもしれませんが、モデル定義が使用に抑制される、(ことによると部分集合、)、本書ではサブシステムの間にデータを移すために定義された抽象的なデータ要素。
Each Security Model may allow multiple security protocols to be used concurrently within an implementation of the model. Each Security Model defines how to determine which protocol to use, given the securityLevel and the security parameters relevant to the message. Each Security Model, with its associated protocol(s) defines how the sending/receiving entities are identified, and how secrets are configured.
各Security Modelは、複数のセキュリティプロトコルが同時にモデルの実装の中で使用されるのを許容するかもしれません。 各Security Modelはどのプロトコルを使用したらよいかを決定する方法を定義します、メッセージに関連しているsecurityLevelとセキュリティパラメタを考えて。 Security Model、それぞれ、関連プロトコルで、(s)は発信/受信実体がどのように特定されるか、そして、秘密がどのように構成されるかを定義します。
Authentication and Privacy protocols supported by Security Models are uniquely identified using Object Identifiers. IETF standard protocols for authentication or privacy should have an identifier defined within the snmpAuthProtocols or the snmpPrivProtocols subtrees. Enterprise specific protocol identifiers should be defined within the enterprise subtree.
Security Modelsによってサポートされた認証とPrivacyプロトコルは、Object Identifiersを使用することで唯一特定されます。 認証かプライバシーのためのIETF標準プロトコルには、snmpAuthProtocolsかsnmpPrivProtocols下位木の中で定義された識別子があるべきです。 エンタープライズの特定のプロトコル識別子は企業下位木の中で定義されるべきです。
For privacy, the Security Model defines what portion of the message is encrypted.
プライバシーのために、Security Modelは、メッセージのどんな部分が暗号化されているかを定義します。
The persistent data used for security should be SNMP-manageable, but the Security Model defines whether an instantiation of the MIB is a conformance requirement.
セキュリティに使用される永続的なデータはSNMP処理しやすいはずですが、Security Modelは、MIBの具体化が順応要件であるかどうかを定義します。
Security Models are replaceable within the Security Subsystem. Multiple Security Model implementations may exist concurrently within an SNMP engine. The number of Security Models defined by the SNMP community should remain small to promote interoperability.
セキュリティModelsはSecurity Subsystemの中で取替え可能です。 複数のSecurity Model実装が同時にSNMPエンジンの中に存在するかもしれません。 SNMP共同体によって定義されたSecurity Modelsの数は相互運用性を促進するために小さいままで残るべきです。
Harrington, et al. Standards Track [Page 58] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[58ページ]。
A.1.3. Validate the security-stamp in a received message
A.1.3。 受信されたメッセージでセキュリティスタンプを有効にしてください。
A Message Processing Model requests that a Security Model:
Message Processing Modelはそのa Security Modelを要求します:
- verifies that the message has not been altered,
- メッセージが変更されていないことを確かめます。
- authenticates the identification of the principal for whom the
message was generated.
- メッセージが生成された主体の識別を認証します。
- decrypts the message if it was encrypted.
- それが暗号化されたなら、メッセージを解読します。
Additional requirements may be defined by the model, and additional services may be provided by the model, but the model is constrained to use the following primitives for transferring data between subsystems. Implementations are not so constrained.
追加要件はモデルによって定義されるかもしれません、そして、追加サービスはモデルによって提供されるかもしれませんが、モデルがサブシステムの間にデータを移すのに以下の基関数を使用するのが抑制されます。実装は非常に抑制されません。
A Message Processing Model uses the processIncomingMsg primitive as described in section 4.4.2.
Message Processing Modelはセクション4.4.2で説明されるように原始的にprocessIncomingMsgを使用します。
A.1.4. Security MIBs
A.1.4。 セキュリティMIBs
Each Security Model defines the MIB module(s) required for security processing, including any MIB module(s) required for the security protocol(s) supported. The MIB module(s) SHOULD be defined concurrently with the procedures which use the MIB module(s). The MIB module(s) are subject to normal access control rules.
各Security Modelはセキュリティ処理に必要であるMIBモジュールを定義します、(s)がサポートしたセキュリティプロトコルに必要であるMIBモジュールを含んでいて。 MIBモジュールSHOULD、同時に、MIBモジュールを使用する手順で、定義されてください。 MIBモジュールは正常なアクセス制御規則を受けることがあります。
The mapping between the model-dependent security ID and the securityName MUST be able to be determined using SNMP, if the model- dependent MIB is instantiated and if access control policy allows access.
モデル依存するセキュリティIDとsecurityNameの間のマッピングはSNMPを使用することで断固とすることができなければなりません、そして、依存するMIBはモデルであるなら例示されます、そして、アクセスコントロールであるなら、方針はアクセサリーを許容します。
A.1.5. Cached Security Data
A.1.5。 キャッシュされたセキュリティー・データ
For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response.
受け取られた各メッセージに関しては、Security Modelは同じセキュリティ情報を使用することでResponseメッセージを生成することができるように州の情報をキャッシュします、Local Configuration Datastoreが入って来る要求の時間と外向的な応答の間で変更されても。
A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model.
Message Processing Modelには、そのようなデータはもう必要でないなら明らかにキャッシュされたデータを発表することへの責任があります。 これを可能にするために、抽象的なsecurityStateReferenceデータ要素はSecurity ModelからMessage Processing Modelまで渡されます。
The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in section 4.5.1.
キャッシュされたセキュリティー・データは、応答の世代を通してそれとなく発表されるか、または原始的にstateReleaseを使用することによって、明らかに発表されるかもしれません、セクション4.5.1で説明されるように。
Harrington, et al. Standards Track [Page 59] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[59ページ]。
A.2. Message Processing Model Design Requirements
A.2。 メッセージ処理モデル設計の品質
An SNMP engine contains a Message Processing Subsystem which may contain multiple Message Processing Models.
SNMPエンジンは複数のMessage Processing Modelsを含むかもしれないMessage Processing Subsystemを含んでいます。
The Message Processing Model MUST always (conceptually) pass the complete PDU, i.e., it never forwards less than the complete list of varBinds.
Message Processing ModelはvarBindsに関する全リストよりいつも(概念的に)完全なPDU、すなわち、それを決して前方でないのに通過しなければならないというわけではありません。
A.2.1. Receiving an SNMP Message from the Network
A.2.1。 ネットワークからSNMPメッセージを受け取ります。
Upon receipt of a message from the network, the Dispatcher in the SNMP engine determines the version of the SNMP message and interacts with the corresponding Message Processing Model to determine the abstract data elements.
ネットワークからのメッセージを受け取り次第、SNMPエンジンのDispatcherは、SNMPメッセージのバージョンを決定して、抽象的なデータ要素を測定するために対応するMessage Processing Modelと対話します。
A Message Processing Model specifies the SNMP Message format it supports and describes how to determine the values of the abstract data elements (like msgID, msgMaxSize, msgFlags, msgSecurityParameters, securityModel, securityLevel etc). A Message Processing Model interacts with a Security Model to provide security processing for the message using the processIncomingMsg primitive, as described in section 4.4.2.
Message Processing ModelはそれがサポートするSNMP Message形式を指定して、抽象的なデータ要素の値を決定する方法を説明します(msgID、msgMaxSize、msgFlags、msgSecurityParameters、securityLevel securityModelなどのように)。 Message Processing Modelは原始的にprocessIncomingMsgを使用することでメッセージのためのセキュリティ処理を提供するためにSecurity Modelと対話します、セクション4.4.2で説明されるように。
A.2.2. Sending an SNMP Message to the Network
A.2.2。 SNMPメッセージをネットワークに送ります。
The Dispatcher in the SNMP engine interacts with a Message Processing Model to prepare an outgoing message. For that it uses the following primitives:
SNMPエンジンのDispatcherは、送信されるメッセージを準備するためにMessage Processing Modelと対話します。 それのために、以下の基関数を使用します:
- for requests and notifications: prepareOutgoingMessage, as
described in section 4.2.1.
- 要求と通知のために: セクション4.2.1で説明されるようなprepareOutgoingMessage。
- for response messages: prepareResponseMessage, as described in
section 4.2.2.
- 応答メッセージのために: セクション4.2.2で説明されるようなprepareResponseMessage。
A Message Processing Model, when preparing an Outgoing SNMP Message, interacts with a Security Model to secure the message. For that it uses the following primitives:
Outgoing SNMP Messageを準備するとき、Message Processing Modelは、メッセージを保証するためにSecurity Modelと対話します。 それのために、以下の基関数を使用します:
- for requests and notifications: generateRequestMsg, as
described in section 4.4.1.
- 要求と通知のために: セクション4.4.1で説明されるようなgenerateRequestMsg。
- for response messages: generateResponseMsg as described in
section 4.4.3.
- 応答メッセージのために: セクション4.4.3で説明されるgenerateResponseMsg。
Harrington, et al. Standards Track [Page 60] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[60ページ]。
Once the SNMP message is prepared by a Message Processing Model, the Dispatcher sends the message to the desired address using the appropriate transport.
SNMPメッセージがMessage Processing Modelによっていったん準備されると、Dispatcherは、適切な輸送を使用することで必要なアドレスにメッセージを送ります。
A.3. Application Design Requirements
A.3。 アプリケーション設計要件
Within an application, there may be an explicit binding to a specific SNMP message version, i.e., a specific Message Processing Model, and to a specific Access Control Model, but there should be no reference to any data defined by a specific Message Processing Model or Access Control Model.
アプリケーションの中に、特定のSNMPメッセージバージョン、特定のMessage Processing Modelと、そして、すなわち、特定のAccess Control Modelとの明白な結合があるかもしれませんが、特定のMessage Processing ModelかAccess Control Modelによって定義されたどんなデータの参照も全くあるべきではありません。
Within an application, there should be no reference to any specific Security Model, or any data defined by a specific Security Model.
アプリケーションの中に、どんな特定のSecurity Model、または特定のSecurity Modelによって定義されたどんなデータの参照も全くあるべきではありません。
An application determines whether explicit or implicit access control should be applied to the operation, and, if access control is needed, which Access Control Model should be used.
アプリケーションは、明白であるか内在しているアクセスコントロールが操作に適用されるべきであるかどうかと、どのAccess Control Modelがアクセスコントロールが必要であるなら使用されるべきであるかを決定します。
An application has the responsibility to define any MIB module(s) used to provide application-specific services.
アプリケーションには、アプリケーション特有のサービスを提供するのに使用されるどんなMIBモジュールも定義する責任があります。
Applications interact with the SNMP engine to initiate messages, receive responses, receive asynchronous messages, and send responses.
アプリケーションは、メッセージを開始して、応答を受けて、非同期なメッセージを受け取って、応答を送るためにSNMPエンジンと対話します。
A.3.1. Applications that Initiate Messages
A.3.1。 アプリケーションはそのInitiate Messagesです。
Applications may request that the SNMP engine send messages containing SNMP commands or notifications using the sendPdu primitive as described in section 4.1.1.
アプリケーションは、SNMPエンジンがセクション4.1.1で説明されるように原始的にsendPduを使用することでSNMPコマンドか通知を含むメッセージを送るよう要求するかもしれません。
If it is desired that a message be sent to multiple targets, it is the responsibility of the application to provide the iteration.
メッセージがマルチターゲットに送られることが望まれているなら、繰り返しを提供するのは、アプリケーションの責任です。
The SNMP engine assumes necessary access control has been applied to the PDU, and provides no access control services.
SNMPエンジンは、必要なアクセスコントロールがPDUに適用されて、どんなアクセス制御にもサービスを提供しないと仮定します。
The SNMP engine looks at the "expectResponse" parameter, and if a response is expected, then the appropriate information is cached such that a later response can be associated to this message, and can then be returned to the application. A sendPduHandle is returned to the application so it can later correspond the response with this message as well.
SNMPエンジンは"expectResponse"パラメタを見ます、そして、応答が予想されるなら、後の応答をこのメッセージに関連づけることができるように適切な情報をキャッシュします、そして、次に、アプリケーションに返すことができます。 sendPduHandleによるそうすることができるようにアプリケーションに返して、また、このメッセージがある応答が、より遅く対応するということです。
Harrington, et al. Standards Track [Page 61] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[61ページ]。
A.3.2. Applications that Receive Responses
A.3.2。 アプリケーションはそのReceive Responsesです。
The SNMP engine matches the incoming response messages to outstanding messages sent by this SNMP engine, and forwards the response to the associated application using the processResponsePdu primitive, as described in section 4.1.4.
SNMPエンジンは、このSNMPエンジンによって送られた傑出しているメッセージに入って来る応答メッセージを合わせて、原始的にprocessResponsePduを使用することで関連するアプリケーションへの応答を送ります、セクション4.1.4で説明されるように。
A.3.3. Applications that Receive Asynchronous Messages
A.3.3。 アプリケーションはそのReceive Asynchronous Messagesです。
When an SNMP engine receives a message that is not the response to a request from this SNMP engine, it must determine to which application the message should be given.
SNMPエンジンがこのSNMPエンジンから要求への応答でないメッセージを受け取るとき、それは、メッセージがどのアプリケーションに与えられるべきであるかを決定しなければなりません。
An Application that wishes to receive asynchronous messages registers itself with the engine using the primitive registerContextEngineID as described in section 4.1.5.
非同期なメッセージを受け取りたがっているApplicationはセクション4.1.5で説明されるように原始のregisterContextEngineIDを使用するエンジンにそれ自体を登録します。
An Application that wishes to stop receiving asynchronous messages should unregister itself with the SNMP engine using the primitive unregisterContextEngineID as described in section 4.1.5.
非同期なメッセージを受け取るのを止めたいApplicationはSNMPエンジンがセクション4.1.5で説明されるように原始のunregisterContextEngineIDを使用している「非-レジスタ」自体がそうするべきです。
Only one registration per combination of PDU type and contextEngineID is permitted at the same time. Duplicate registrations are ignored. An errorIndication will be returned to the application that attempts to duplicate a registration.
PDUタイプとcontextEngineIDの組み合わせあたりの登録が同時に受入れられるものだけ。 写し登録証明書は無視されます。 登録をコピーするのを試みるアプリケーションにerrorIndicationを返すでしょう。
All asynchronously received messages containing a registered combination of PDU type and contextEngineID are sent to the application which registered to support that combination.
すべてがPDUタイプの登録された組み合わせを含むメッセージを非同期に受け取りました、そして、その組み合わせをサポートするために登録されたアプリケーションにcontextEngineIDを送ります。
The engine forwards the PDU to the registered application, using the processPdu primitive, as described in section 4.1.2.
セクション4.1.2で説明されるように原始的にprocessPduを使用して、エンジンは登録されたアプリケーションにPDUを送ります。
A.3.4. Applications that Send Responses
A.3.4。 アプリケーションはそのSend Responsesです。
Request operations require responses. An application sends a response via the returnResponsePdu primitive, as described in section 4.1.3.
操作が応答を必要とするよう要求してください。 アプリケーションはセクション4.1.3で説明されるようにreturnResponsePduを通して原始的に応答を送ります。
The contextEngineID, contextName, securityModel, securityName, securityLevel, and stateReference parameters are from the initial processPdu primitive. The PDU and statusInformation are the results of processing.
初期のprocessPduから、contextEngineID、contextName、securityModel、securityName、securityLevel、およびstateReferenceパラメタは原始的です。 PDUとstatusInformationは処理の結果です。
Harrington, et al. Standards Track [Page 62] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[62ページ]。
A.4. Access Control Model Design Requirements
A.4。 アクセス制御モデル設計の品質
An Access Control Model determines whether the specified securityName is allowed to perform the requested operation on a specified managed object. The Access Control Model specifies the rules by which access control is determined.
Access Control Modelは、指定されたsecurityNameが指定された管理オブジェクトに要求された操作を実行できるかどうか決定します。 Access Control Modelはアクセスコントロールが決定している規則を指定します。
The persistent data used for access control should be manageable using SNMP, but the Access Control Model defines whether an instantiation of the MIB is a conformance requirement.
アクセスコントロールに使用される永続的なデータはSNMPを使用することで処理しやすいはずですが、Access Control Modelは、MIBの具体化が順応要件であるかどうかを定義します。
The Access Control Model must provide the primitive isAccessAllowed.
Access Control Modelは原始のisAccessAllowedを提供しなければなりません。
Editors' Addresses
エディタのアドレス
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
バートWijnenルーセントテクノロジーズSchagen33 3461GLリンスホーテン・オランダ
Phone: +31 348-680-485 EMail: bwijnen@lucent.com
以下に電話をしてください。 +31 348-680-485 メールしてください: bwijnen@lucent.com
David Harrington Enterasys Networks Post Office Box 5005 35 Industrial Way Rochester, New Hampshire 03866-5005 USA
デヴィッドハリントンEnterasysがネットワークでつなぐ、私書箱5005 35産業の道のロチェスター、ニューハンプシャー03866-5005米国
Phone: +1 603-337-2614 EMail: dbh@enterasys.com
以下に電話をしてください。 +1 603-337-2614 メールしてください: dbh@enterasys.com
Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, California 95131 USA
ランディPresuhn BMCソフトウェアInc.2141の北の最初に、通りサンノゼ、カリフォルニア95131米国
Phone: +1 408-546-1006 Fax: +1 408-965-0359 EMail: randy_presuhn@bmc.com
以下に電話をしてください。 +1 408-546-1006Fax: +1 408-965-0359 メールしてください: randy_presuhn@bmc.com
Harrington, et al. Standards Track [Page 63] RFC 3411 Architecture for SNMP Management Frameworks December 2002
ハリントン、他 規格は管理フレームワーク2002年12月にSNMPのためにRFC3411アーキテクチャを追跡します[63ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Harrington, et al. Standards Track [Page 64]
ハリントン、他 標準化過程[64ページ]
一覧
スポンサーリンク
