RFC2271 日本語訳
2271 An Architecture for Describing SNMP Management Frameworks. D.Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT=128227 bytes) (Obsoletes RFC2261) (Obsoleted by RFC2571) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Harrington
Request for Comments: 2271 Cabletron Systems, Inc.
Obsoletes: 2261 R. Presuhn
Category: Standards Track BMC Software, Inc.
B. Wijnen
IBM T. J. Watson Research
January 1998
コメントを求めるワーキンググループD.ハリントンの要求をネットワークでつないでください: Inc.が時代遅れにする2271台のCabletronシステム: 2261年のR.Presuhnカテゴリ: 標準化過程BMCソフトウェアInc.B.Wijnen IBM T.J.ワトソン研究1998年1月
An Architecture for Describing
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
IANA Note
IANA注意
Due to a clerical error in the assignment of the snmpModules in this memo, this RFC provides the corrected number assignment for this protocol. This memo obsoletes RFC 2261.
このメモにおける、snmpModulesの課題における事務員の誤りのため、このRFCはこのプロトコルのための直っている数の課題を提供します。 このメモはRFC2261を時代遅れにします。
Abstract
要約
This document describes an architecture for describing 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.
このドキュメントは、SNMP Management Frameworksについて説明するためにアーキテクチャについて説明します。 アーキテクチャは、時間がたつにつれてSNMPプロトコル標準の発展を許容するためにはモジュールであるために設計されています。 アーキテクチャの主要部は、Message Processing Subsystem、Security Subsystem、およびAccess Control Subsystemを含むSNMPエンジンと、管理データの特定の機能的な処理を提供することによると複数のSNMPアプリケーションです。
Table of Contents
目次
1. Introduction ................................................ 3 1.1. Overview .................................................. 3 1.2. SNMP ...................................................... 4 1.3. Goals of this Architecture ................................ 5 1.4. Security Requirements of this Architecture ................ 6 1.5. Design Decisions .......................................... 7 2. Documentation Overview ...................................... 8
1. 序論… 3 1.1. 概要… 3 1.2. SNMP… 4 1.3. このArchitectureの目標… 5 1.4. このArchitectureのセキュリティRequirements… 6 1.5. 決定を設計してください… 7 2. ドキュメンテーション概要… 8
Harrington, et. al. Standards Track [Page 1] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[1ページ]。
2.1. Document Roadmap .......................................... 10 2.2. Applicability Statement ................................... 10 2.3. Coexistence and Transition ................................ 10 2.4. Transport Mappings ........................................ 11 2.5. Message Processing ........................................ 11 2.6. Security .................................................. 11 2.7. Access Control ............................................ 11 2.8. Protocol Operations ....................................... 12 2.9. Applications .............................................. 12 2.10. Structure of Management Information ...................... 12 2.11. Textual Conventions ...................................... 13 2.12. Conformance Statements ................................... 13 2.13. Management Information Base Modules ...................... 13 2.13.1. SNMP Instrumentation MIBs .............................. 13 2.14. SNMP Framework Documents ................................. 13 3. Elements of the Architecture ................................ 14 3.1. The Naming of Entities .................................... 14 3.1.1. SNMP engine ............................................. 15 3.1.1.1. snmpEngineID .......................................... 16 3.1.1.2. Dispatcher ............................................ 16 3.1.1.3. Message Processing Subsystem .......................... 16 3.1.1.3.1. Message Processing Model ............................ 17 3.1.1.4. Security Subsystem .................................... 17 3.1.1.4.1. Security Model ...................................... 17 3.1.1.4.2. Security Protocol ................................... 18 3.1.2. Access Control Subsystem ................................ 18 3.1.2.1. Access Control Model .................................. 18 3.1.3. Applications ............................................ 18 3.1.3.1. SNMP Manager .......................................... 19 3.1.3.2. SNMP Agent ............................................ 20 3.2. The Naming of Identities .................................. 21 3.2.1. Principal ............................................... 21 3.2.2. securityName ............................................ 21 3.2.3. Model-dependent security ID ............................. 22 3.3. The Naming of Management Information ...................... 22 3.3.1. An SNMP Context ......................................... 23 3.3.2. contextEngineID ......................................... 24 3.3.3. contextName ............................................. 24 3.3.4. scopedPDU ............................................... 25 3.4. Other Constructs .......................................... 25 3.4.1. maxSizeResponseScopedPDU ................................ 25 3.4.2. Local Configuration Datastore ........................... 25 3.4.3. securityLevel ........................................... 25 4. Abstract Service Interfaces ................................. 26 4.1. Dispatcher Primitives ..................................... 26 4.1.1. Generate Outgoing Request or Notification ............... 26 4.1.2. Process Incoming Request or Notification PDU ............ 26 4.1.3. Generate Outgoing Response .............................. 27
2.1. 道路地図を記録してください… 10 2.2. 適用性声明… 10 2.3. 共存と変遷… 10 2.4. マッピングを輸送してください… 11 2.5. メッセージ処理… 11 2.6. セキュリティ… 11 2.7. コントロールにアクセスしてください… 11 2.8. 操作について議定書の中で述べてください… 12 2.9. アプリケーション… 12 2.10. 経営情報の構造… 12 2.11. 原文のコンベンション… 13 2.12. 順応声明… 13 2.13. 管理情報ベースモジュール… 13 2.13.1. SNMP計装MIBs… 13 2.14. SNMPフレームワークドキュメント… 13 3. アーキテクチャのElements… 14 3.1. 実体の命名… 14 3.1.1. SNMPエンジン… 15 3.1.1.1snmpEngineID… 16 3.1.1.2. 発送者… 16 3.1.1.3. メッセージ処理サブシステム… 16 3.1.1.3.1. メッセージ処理モデル… 17 3.1.1.4. セキュリティサブシステム… 17 3.1.1.4.1. セキュリティはモデル化されます… 17 3.1.1.4.2. セキュリティは議定書を作ります… 18 3.1.2. コントロールサブシステムにアクセスしてください… 18 3.1.2.1. 規制モデルにアクセスしてください… 18 3.1.3. アプリケーション… 18 3.1.3.1. SNMPマネージャ… 19 3.1.3.2. SNMPエージェント… 20 3.2. アイデンティティの命名… 21 3.2.1. 主体… 21 3.2.2securityName… 21 3.2.3. モデル依存するセキュリティID… 22 3.3. 経営情報の命名… 22 3.3.1. SNMP文脈… 23 3.3.2contextEngineID… 24 3.3.3contextName… 24 3.3.4scopedPDU… 25 3.4. 他の構造物… 25 3.4.1maxSizeResponseScopedPDU… 25 3.4.2. 地方の構成Datastore… 25 3.4.3securityLevel… 25 4. 抽象的なサービスは連結します… 26 4.1. 発送者基関数… 26 4.1.1. 送信する要求か通知を生成してください… 26 4.1.2. 入って来る要求か通知PDUを処理してください… 26 4.1.3. 外向的な応答を生成してください… 27
Harrington, et. al. Standards Track [Page 2] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[2ページ]。
4.1.4. Process Incoming Response PDU ........................... 27 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 28 4.2. Message Processing Subsystem Primitives ................... 28 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 28 4.2.2. Prepare an Outgoing SNMP Response Message ............... 29 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 29 4.3. Access Control Subsystem Primitives ....................... 30 4.4. Security Subsystem Primitives ............................. 30 4.4.1. Generate a Request or Notification Message .............. 30 4.4.2. Process Incoming Message ................................ 31 4.4.3. Generate a Response Message ............................. 31 4.5. Common Primitives ......................................... 32 4.5.1. Release State Reference Information ..................... 32 4.6. Scenario Diagrams ......................................... 32 4.6.1. Command Generator or Notification Originator ............ 32 4.6.2. Scenario Diagram for a Command Responder Application .... 33 5. Managed Object Definitions for SNMP Management Frameworks ... 35 6. Intellectual Property ....................................... 44 7. Acknowledgements ............................................ 45 8. Security Considerations ..................................... 46 9. References .................................................. 46 10. Editors' Addresses ......................................... 48 A. Guidelines for Model Designers .............................. 49 A.1. Security Model Design Requirements ........................ 49 A.1.1. Threats ................................................. 49 A.1.2. Security Processing ..................................... 50 A.1.3. Validate the security-stamp in a received message ....... 51 A.1.4. Security MIBs ........................................... 51 A.1.5. Cached Security Data .................................... 51 A.2. Message Processing Model Design Requirements .............. 52 A.2.1. Receiving an SNMP Message from the Network .............. 52 A.2.2. Sending an SNMP Message to the Network .................. 52 A.3. Application Design Requirements ........................... 53 A.3.1. Applications that Initiate Messages ..................... 53 A.3.2. Applications that Receive Responses ..................... 54 A.3.3. Applications that Receive Asynchronous Messages ......... 54 A.3.4. Applications that Send Responses ........................ 54 A.4. Access Control Model Design Requirements .................. 55 B. Full Copyright Statement .................................... 56
4.1.4. 入って来る応答PDUを処理してください… 27 4.1.5. 取り扱いSNMP PDUsへの責任を登録します… 28 4.2. メッセージ処理サブシステム基関数… 28 4.2.1. 送信するSNMP要求か通知メッセージを用意してください… 28 4.2.2. 外向的なSNMP応答メッセージを用意してください… 29 4.2.3. 入って来るSNMPメッセージからデータ要素を用意してください… 29 4.3. コントロールサブシステム基関数にアクセスしてください… 30 4.4. セキュリティサブシステム基関数… 30 4.4.1. 要求か通知メッセージを生成してください… 30 4.4.2. 入力メッセージを処理してください… 31 4.4.3. 応答メッセージを生成してください… 31 4.5. 一般的な基関数… 32 4.5.1. 州の参考情報を発表してください… 32 4.6. シナリオダイヤグラム… 32 4.6.1. ジェネレータか通知創始者を命令してください… 32 4.6.2. コマンド応答者アプリケーションのためのシナリオダイヤグラム… 33 5. SNMP管理フレームワークのための管理オブジェクト定義… 35 6. 知的所有権… 44 7. 承認… 45 8. セキュリティ問題… 46 9. 参照… 46 10. エディタのアドレス… 48 モデルデザイナーへのA.ガイドライン… 49 A.1。 セキュリティは設計の品質をモデル化します… 49 A.1.1。 脅威… 49 A.1.2。 セキュリティ処理… 50 A.1.3。 受信されたメッセージでセキュリティスタンプを有効にしてください… 51 A.1.4。 セキュリティMIBs… 51 A.1.5。 セキュリティー・データをキャッシュします… 51 A.2。 メッセージ処理モデル設計の品質… 52 A.2.1。 ネットワークからSNMPメッセージを受け取ります… 52 A.2.2。 SNMPメッセージをネットワークに送ります… 52 A.3。 アプリケーション設計要件… 53 A.3.1。 アプリケーション、そのInitiate Messages… 53 A.3.2。 アプリケーション、そのReceive Responses… 54 A.3.3。 アプリケーション、そのReceive Asynchronous Messages… 54 A.3.4。 アプリケーション、そのSend Responses… 54 A.4。 コントロールモデル設計の品質にアクセスしてください… 55 B.の完全な著作権宣言文… 56
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の主要部について説明するためにアーキテクチャを定義します。
Harrington, et. al. Standards Track [Page 3] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[3ページ]。
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 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, and 9 are administrative in nature.
セクション6、7、8、および9は現実に管理です。
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]で説明されるように本書では解釈されることであるべきですか?
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実体。
Harrington, et. al. Standards Track [Page 4] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[4ページ]。
- 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実体とアプリケーションのことによると他のタイプ。
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*.
- 既存の材料をできるだけ使用してください。 それは、大いに前の仕事に基づいていて、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.
- 標準化過程でアーキテクチャの部分を前方へ動かせるのを可能にしてください、コンセンサスにすべての断片で達しないでも。
Harrington, et. al. Standards Track [Page 5] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[5ページ]。
- 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 SNMP
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実体がトランジットにおけるそのような方法で認可された元本を代表して権限のない管理操作に作用するほど生成されたSNMPメッセージを変更するかもしれないという危険です、オブジェクトの値を改竄するのを含んでいて。
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.
仮装してください。仮面舞踏会の脅威は何らかの主体のために認可されなかった管理操作が適切な承認を持っている別の校長のアイデンティティを仮定することによって試みられるかもしれないという危険です。
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
SNMPが議定書の中で述べるメッセージStream Modificationはどんなサブネットワークサービスの上でも作動するかもしれないコネクションレスな輸送サービスに通常基づいています。 メッセージの再注文、遅れまたは再生が、起こって、そのような多くのサブネットワークサービスの自然な操作で起こることができます。 メッセージストリーム変更の脅威は通信する危険です。
Harrington, et. al. Standards Track [Page 6] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[6ページ]。
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.
自然なサブネットワークサービスの操作で起こることができるより大きい程度まで、陰湿に再命令されるか、遅らせられるか、または再演されるかもしれません、権限のない管理操作に作用するように。
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.
このアーキテクチャの中の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は、トラヒック分析が攻撃であると扱うのを試みません。 多くのトラフィック・パターンが予測できます、そして、(実体は定期的に比較的少ない数の管理局によって管理されるかもしれません)したがって、トラヒック分析から守ることによって提供されたどんな重要な利点もありません。
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
- 同じドキュメントでSNMPフレームワークの特定部位のための処理に必要である手順の自己充足的なDocuments ElementsとMIBオブジェクトを定義するべきです、そして、できるだけ、他のドキュメントで参照をつけるべきではありません。 これは、断片が独立していて自己充足的であるとして設計されていて、記録されるのを許容します。
Harrington, et. al. Standards Track [Page 7] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[7ページ]。
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 MIBモジュールアプローチと一致しています)。 SNMPの一部が時間がたつにつれて変化するとき、SNMPの他の一部について説明するドキュメントは直接影響を与えられません。 このモジュール方式は、例えばSecurity Models、認証、プライバシーメカニズム、およびメッセージ・フォーマットが必要に応じてアップグレードして、補われるのを許容します。 自己の含まれたドキュメントは異なったタイムラインで標準化過程に沿って移行できます。
- Threats
The Security Models in the Security Subsystem SHOULD protect
against the principal 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 able to be remotely
configured.
- リモートConfigurationのSecurityとAccess Control Subsystemsは真新しいSNMP設定パラメータを加えます。 また、Security Subsystemは様々なSNMP実体で秘密の頻繁な変化を必要とします。 大きい運用環境でこの配布可能を作るために、これらのSNMPパラメタは離れて構成できなければなりません。
- 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つの環境の競争している要件を保とうとして、より複雑な環境が簡単な環境を論理的に広げるのを許容します。
2. Documentation Overview
2. ドキュメンテーション概要
The following figure shows the set of documents that fit within the SNMP Architecture.
以下の図はSNMP Architectureの中で合うドキュメントのセットを示しています。
Harrington, et. al. Standards Track [Page 8] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[8ページ]。
+------------------------- 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 | | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | MIBs | | | | +-------------+ +-------------+ +----------+ +----------+ | | | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | | | | RFC1157 | | RFC1212 | | RFC14XX | | RFC19XX | | | | | | format | | format | | format | | format | | | | | +-------------+ +-------------+ +----------+ +----------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
+------------------------- 文献集合----------------------------+ | | | +------------+ +-----------------+ +----------------+ | | | ドキュメント*| | 適用性*| | 共存*| | | | 道路地図| | 声明| | 変遷| | | +------------+ +-----------------+ +----------------+ | | | | +---------------------------------------------------------------+ | | | メッセージハンドリング| | | | +----------------+ +-----------------+ +-----------------+ | | | | | 輸送| | メッセージ| | セキュリティ| | | | | | マッピング| | そして処理。| | | | | | | | | | 発送者| | | | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | PDU取り扱い| | | | +----------------+ +-----------------+ +-----------------+ | | | | | プロトコル| | アプリケーション| | アクセス| | | | | | 操作| | | | コントロール| | | | | +----------------+ +-----------------+ +-----------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | 情報モデル| | | | +--------------+ +--------------+ +---------------+ | | | | | 構造| | 原文| | 順応| | | | | | 管理| | コンベンション| | 声明| | | | | | 情報| | | | | | | | | +--------------+ +--------------+ +---------------+ | | | +---------------------------------------------------------------+ | | | | +---------------------------------------------------------------+ | | | MIBs| | | | +-------------+ +-------------+ +----------+ +----------+ | | | | | 標準のv1| | 標準のv1| | 歴史的| | 草稿v2| | | | | | RFC1157| | RFC1212| | RFC14XX| | RFC19XX| | | | | | 形式| | 形式| | 形式| | 形式| | | | | +-------------+ +-------------+ +----------+ +----------+ | | | +---------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
Note: RFC14XX means RFCs 1442, 1443, and 1444. RFC19XX means RFCs 1902, 1903, and 1904.
以下に注意してください。 RFC14XXはRFCs1442、1443、および1444を意味します。 RFC19XXはRFCs1902、1903、および1904を意味します。
Harrington, et. al. Standards Track [Page 9] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[9ページ]。
Those marked with an asterisk (*) are expected to be written in the future. 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を形成するかを説明するために書かれているかもしれません。 文献集合の構成が時間がたつにつれて変化するかもしれないので、「ロードマップ」は規格文書自体から別々のドキュメントで維持されるべきです。
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 10] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[10ページ]。
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 passwords.
セキュリティドキュメントはSecurity Modelについて説明します、モデルが保護する脅威、Security Modelの目標、それらの目標を達成するのに使用するプロトコル、そして、処理の間に使用されるデータについて説明して、メッセージレベルセキュリティパラメタのリモート構成を許すためにMIBモジュールを定義するかもしれません、パスワードなどのように。
An SNMP engine may support multiple Security Models concurrently.
SNMPエンジンは同時に複数のSecurity Modelsをサポートするかもしれません。
2.7. Access Control
2.7. アクセス制御
During processing, it may be required to control access to managed objects for operations.
処理の間、それが、操作のために管理オブジェクトへのアクセスを制御するのに必要であるかもしれません。
Harrington, et. al. Standards Track [Page 11] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[11ページ]。
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). It is the purpose of a Protocol Operations document to define the operations of the protocol with respect to the processing of the PDUs.
SNMPメッセージはSNMPプロトコルData Unit(PDU)をカプセル化します。 PDUsの処理に関してプロトコルの操作を定義するのは、プロトコルOperationsドキュメントの目的です。
An application document defines which Protocol Operations documents 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メッセージを使用するかもしれません。
Applications documents describe 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.
アプリケーションドキュメントは、どのセットのドキュメントが明確にアプリケーションでサポートされた経営情報、原文のコンベンション、順応要件、および操作の構造を定義するのに使用されるかを定義します。
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 syntax for defining objects, modules, and other elements of managed information.
管理された情報のオブジェクトを定義する、モジュール、および他の要素のために構文を確立するのは、Management情報ドキュメントのStructureの目的です。
Harrington, et. al. Standards Track [Page 12] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[12ページ]。
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 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 Conformance Statements 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 remote configuration of the Model.
SNMP MIBドキュメント自体はSNMPがそれの器具について議定書の中で述べる管理オブジェクトの収集を定義するかもしれません。 さらに、MIBモジュールはSNMPアーキテクチャの部分について説明するドキュメントの中に定義されるかもしれません、Message処理Modelsのためのドキュメント、それらのModelsに器具を取り付ける目的、およびModelのリモート構成を許す目的のための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の一部の抽象的で不完全な仕様を示して、それはモデル仕様でさらに精製されます。
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です。
Harrington, et. al. Standards Track [Page 13] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[13ページ]。
SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no message definition.
SNMPバージョン2(SNMPv2)はSNMPv1 Frameworkから派生するようにSNMPv2 Frameworkです。 それはRFCs1902-1907で説明されます。 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
CommunityベースのSNMPバージョン2(SNMPv2c)は実験的なSNMP Frameworkです。RFC1901で説明されるようにSNMPv2 Frameworkを補います。 それはSNMPv2cメッセージ・フォーマットを加えます。(それは、同様です)。
SNMPv1 message format.
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, and
- そしてメッセージのためのセキュリティ。
- Access Control.
- コントロールにアクセスしてください。
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) 経営情報の命名。
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実体とコンポーネントに関する詳細を示しています。
Harrington, et. al. Standards Track [Page 14] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[14ページ]。
+-------------------------------------------------------------------+ | 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によって特定されます)| | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | 発送者| | メッセージ| | セキュリティ| | アクセス| | | | | | | | 処理| | サブシステム| | コントロール| | | | | | | | サブシステム| | | | サブシステム| | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | アプリケーション| | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | コマンド| | 通知| | プロキシ| | | | | | ジェネレータ| | 受信機| | 混載業者| | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | コマンド| | 通知| | 他| | | | | | 応答者| | 創始者| | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
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) メッセージ処理サブシステム
Harrington, et. al. Standards Track [Page 15] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[15ページ]。
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.
管理ドメインの中では、snmpEngineIDはSNMPエンジンのユニークで明白な識別子です。 SNMPエンジンとSNMP実体との1〜1つの協会があるので、それは唯一も、明白にSNMP実体を特定します。
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を送ることができます。
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が存在しているかもしれません。
Harrington, et. al. Standards Track [Page 16] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[16ページ]。
+------------------------------------------------------------------+ | | | 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メッセージの特定のバージョンの書式を定義して、そのようなそれぞれのバージョン特有のメッセージ・フォーマットの準備と抽出を調整します。
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 defines 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はそれが保護される脅威、サービスの目標、および認証やプライバシーなどのセキュリティー・サービスを提供するのに使用されるセキュリティプロトコルを定義します。
Harrington, et. al. Standards Track [Page 17] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[17ページ]。
3.1.1.4.2. Security Protocol
3.1.1.4.2. セキュリティプロトコル
A Security Protocol defines the mechanisms, procedures, and MIB data used to provide a security service such as authentication or privacy.
Securityプロトコルは認証かプライバシーなどのセキュリティー・サービスを提供するのに用いられたメカニズム、手順、およびMIBデータを定義します。
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は1Access 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 18] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[18ページ]。
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. * One or more models may be present.
1つ以上のコマンドジェネレータ、そして/または、通知受信側アプリケーション(それらの関連SNMPエンジンに伴う)を含むSNMP実体は伝統的にSNMPマネージャと呼ばれました。 * 1つ以上のモデルが出席しているかもしれません。
(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 RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
(伝統的なSNMPマネージャ) +-------------------------------------------------------------------+ | +--------------+ +--------------+ +--------------+ SNMP実体| | | 通知| | 通知| | コマンド| | | | 創始者| | 受信機| | ジェネレータ| | | | アプリケーション| | アプリケーション| | アプリケーション| | | +--------------+ +--------------+ +--------------+ | | ^ ^ ^ | | | | | | | v vに対して| | +-------+--------+-----------------+ | | ^ | | | +---------------------+ +----------------+ | | | | メッセージ処理| | セキュリティ| | | 発送者v| サブシステム| | サブシステム| | | +-------------------+ | +------------+ | | | | | | PDU発送者| | +->| v1MP*| <、-、--、>| +------------+ | | | | | | | +------------+ | | | 他| | | | | | | | +------------+ | | | セキュリティ| | | | | | | +->| v2cMP*| <、-、--、>|、| モデル| | | | | メッセージ| | | +------------+ | | +------------+ | | | | 発送者<。--------->+| | | | | | | | | +------------+ | | +------------+ | | | | | | +->| v3MP*| <、-、--、>|、| ユーザベースです。| | | | | 輸送| | | +------------+ | | | セキュリティ| | | | | マッピング| | | +------------+ | | | モデル| | | | | (e.g RFC1906) | | +->| otherMP*| <、-、--、>| +------------+ | | | +-------------------+ | +------------+ | | | | | ^ +---------------------+ +----------------+ | | | | | v| +-------------------------------------------------------------------+ +-----+ +-----+ +-------+ | UDP| | IPX| . . . | 他| +-----+ +-----+ +-------+ ^ ^ ^ | | | v対+に------------------------------+ | ネットワーク| +------------------------------+
Harrington, et. al. Standards Track [Page 19] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[19ページ]。
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.
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | 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 |
+-------------------------------------------------------------------+
1人以上のコマンド応答者、そして/または、通知創始者アプリケーション(それらの関連SNMPエンジンに伴う)を含むSNMP実体は伝統的にSNMPエージェントと呼ばれました。 +------------------------------+ | ネットワーク| +------------------------------+ ^ ^ ^ | | | v対+に-----+ +-----+ +-------+ | UDP| | IPX| . . . | 他| +-----+ +-----+ +-------+ (伝統的なSNMPエージェント)+-------------------------------------------------------------------+ | ^ | | | +---------------------+ +----------------+ | | | | メッセージ処理| | セキュリティ| | | 発送者v| サブシステム| | サブシステム| | | +-------------------+ | +------------+ | | | | | | 輸送| | +->| v1MP*| <、-、--、>| +------------+ | | | | マッピング| | | +------------+ | | | 他| | | | | (例えば、RFC1906) | | | +------------+ | | | セキュリティ| | | | | | | +->| v2cMP*| <、-、--、>|、| モデル| | | | | メッセージ| | | +------------+ | | +------------+ | | | | 発送者<。--------->| +------------+ | | +------------+ | | | | | | +->| v3MP*| <、-、--、>|、| ユーザベースです。| | | | | | | | +------------+ | | | セキュリティ| | | | | PDU発送者| | | +------------+ | | | モデル| | | | +-------------------+ | +->| otherMP*| <、-、--、>| +------------+ | | | ^ | +------------+ | | | | | | +---------------------+ +----------------+ | | v| | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v vに対して| | +-------------+ +---------+ +--------------+ +-------------+ | | | コマンド| | アクセス| | 通知| | プロキシ*| | | | 応答者| <->| コントロール| <->| 創始者| | 混載業者| | | | アプリケーション| | | | アプリケーション| | アプリケーション| | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | vに対して| | +----------------------------------------------+ | | | MIB計装| SNMP実体| +-------------------------------------------------------------------+
Harrington, et. al. Standards Track [Page 20] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[20ページ]。
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 21] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[21ページ]。
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, user names, and parties.
モデル依存するセキュリティ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 22] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[22ページ]。
+-----------------------------------------------------------------+ | SNMP entity (identified by snmpEngineID, example: abcd) | | | | +------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | Command Responder Application | | | | (contextEngineID, example: abcd) | | | | | | | | example contextNames: | | | | | | | | "bridge1" "bridge2" "" (default) | | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB | instrumentation | | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | context | | context | | context | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | some MIB | | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | SNMP実体(例: snmpEngineID、abcdによって特定されます)| | | | +------------------------------------------------------------+ | | | SNMPエンジン(snmpEngineIDによって特定されます)| | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | 発送者| | メッセージ| | セキュリティ| | アクセス| | | | | | | | 処理| | サブシステム| | コントロール| | | | | | | | サブシステム| | | | サブシステム| | | | | | | | | | | | | | | | | +-------------+ +------------+ +-----------+ +-----------+ | | | | | | | +------------------------------------------------------------+ | | | | +------------------------------------------------------------+ | | | コマンド応答者アプリケーション| | | | (例: contextEngineID、abcd) | | | | | | | | 例のcontextNames: | | | | | | | | "bridge1""bridge2"、「「(デフォルト)」| | | | --------- --------- ------------ | | | | | | | | | | +------|------------------|-------------------|--------------+ | | | | | | | +------|------------------|-------------------|--------------+ | | | MIB| 計装| | | | | | +---v------------+ +---v------------+ +----v-----------+ | | | | | 文脈| | 文脈| | 文脈| | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | ブリッジMIB| | | | ブリッジMIB| | | | 他のMIB| | | | | | | +------------+ | | +------------+ | | +------------+ | | | | | | | | | | | | | | | | | | | | +------------+ | | | | | | | | | | | いくらかのMIB| | | | | | | | | | | +------------+ | | | | | | | | | | | | | +-----------------------------------------------------------------+
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実体は潜在的に多くの文脈に近づく手段を持っています。
Harrington, et. al. Standards Track [Page 23] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[23ページ]。
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 [RFC1573], 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[RFC1573]をタイプして、ネットワーク・インターフェースの記述と定義されます。 デバイス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実体を特定します。
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実体の中でユニークであるに違いありません。
Harrington, et. al. Standards Track [Page 24] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[24ページ]。
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, RFC1905 for more information about SNMP PDUs.
PDUは管理ドメインの中でcontextEngineIDとcontextNameの組み合わせで明白に特定される文脈で指定された情報を含むSNMPプロトコルData Unitです。 SNMP PDUsに関する詳しい情報に関して例えばRFC1905を見てください。
3.4. Other Constructs
3.4. 他の構造物
3.4.1. maxSizeResponseScopedPDU
3.4.1. maxSizeResponseScopedPDU
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be included in a response message. Note that the size of a scopedPDU does not include the size of the SNMP message header.
maxSizeResponseScopedPDUは応答メッセージに含まれるべき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)
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の供給値を守るのに必要です。
Harrington, et. al. Standards Track [Page 25] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[25ページ]。
4. Abstract Service Interfaces
4. 抽象的なサービスインタフェース
Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity.
抽象的なサービスインタフェースは、SNMP実体の中で様々なサブシステムの間の概念的なインタフェースについて説明するために定義されました。
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によって提供された基関数について説明します。
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
processPdu、(--プロセスRequest/通知PDU IN messageProcessingModel--通常SNMPバージョンIN securityModel--セキュリティModelが中でこの主体を代表してIN securityNameを使用する
Harrington, et. al. Standards Track [Page 26] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[26ページ]。
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
IN securityLevel--Security IN contextEngineIDのレベル--このSNMP実体IN contextNameの/からのデータ--このような関係においては/IN pduVersionからのデータ--PDU IN PDUのバージョン--SNMPプロトコルData Unit IN maxSizeResponseScopedPDU--Response PDU IN stateReferenceの最大サイズ--状態に情報に参照をつけてください、) -- 応答を送るとき、必要です。
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に返すためには原始の以下を提供します:
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 of the Response PDU
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の/からのデータ--データを要求します; PDU IN PDU--SNMPプロトコルData Unit IN maxSizeResponseScopedPDU--要求IN statusInformationがある提示されるとしてのResponse PDU IN stateReference(情報を述べる参照)の最大サイズのバージョン--成功か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を処理してください)
Harrington, et. al. Standards Track [Page 27] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[27ページ]。
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)によって決定されます。
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 responsiblity for all possible values of the contextEngineID or pduType parameters.
registerContextEngineIDとunregisterContextEngineIDの抽象的なサービスインタフェースの実現がcontextEngineIDかpduTypeパラメタのすべての可能な値のためにアプリケーションのための実装特有の方法をレジスタ/deregister responsiblityに供給するかもしれないことに注意してください。
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
statusInformation=--、成功かerrorIndication prepareOutgoingMessage、(IN transportDomain--通常、SNMPバージョンIN securityModel(この主要なIN securityLevelを代表してIN securityNameを使用するセキュリティModel)が平らにするSecurityの中古のIN transportAddress(中古のIN messageProcessingModelである輸送アドレス)がこのような関係においては/IN pduVersionからIN contextEngineID--この実体IN contextNameの/からのデータ--データを要求したということである輸送ドメイン--PDUのバージョン
Harrington, et. al. Standards Track [Page 28] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[28ページ]。
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
)
IN PDU、入って来る応答OUT destTransportDomain--目的地輸送ドメインOUT destTransportAddress--目的地輸送アドレスOUT outgoingMessage--OUT outgoingMessageLengthを送るメッセージ--長さの--SNMPプロトコルData Unit IN expectResponse--TRUEかFALSE IN sendPduHandle(マッチングのためのハンドル))
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 of the Response PDU
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の/からのデータ--データを要求します; Response PDU IN stateReferenceの最大サイズ--情報を述べる参照--誤りOUT destTransportDomain--目的地輸送ドメインOUT destTransportAddress--目的地輸送であるなら要求IN statusInformation--成功かerrorIndication--誤りカウンタOID/価値を与えるように、OUT outgoingMessage(OUT outgoingMessageLengthを送るメッセージ)が長さであると扱ってください; )
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
結果=--、SUCCESSかerrorIndication prepareDataElements、(IN transportDomain--ネットワークOUT messageProcessingModelから受け取るようにネットワークIN wholeMsgLengthから受け取られる発生源輸送ドメインIN transportAddress(発生源輸送アドレスIN wholeMsg)--通常SNMPバージョン
Harrington, et. al. Standards Track [Page 29] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[29ページ]。
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 of the Response PDU
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)
OUT securityModel--この主要なOUT securityLevelを代表してOUT securityNameを使用するセキュリティModel--Securityのレベルはこのような関係においては/OUT pduVersion--PDU OUT PDUのバージョン--SNMPプロトコルData Unit OUT pduTypeからOUT contextEngineID--この実体OUT contextNameの/からのデータ--データを要求しました; 取り組んでいる要求OUT maxSizeResponseScopedPDU(Response PDU OUT statusInformationの最大サイズ)のために成功を扱ってください。さもないと、誤りが誤りOUT stateReferenceであるならOID/値を打ち返すというerrorIndicationが状態に情報に参照をつけるという可能なResponseに使用されるべきSNMP PDUタイプOUT sendPduHandle)
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に読むか、書くか、または通知します)
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
statusInformationがgenerateRequestMsgと等しい、(IN messageProcessingModel--通常SNMPバージョンIN globalData--メッセージヘッダー、アドミンデータ
Harrington, et. al. Standards Track [Page 30] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[30ページ]。
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
)
IN securityEngineID--この主要なIN securityLevelを代表した正式のSNMP実体IN securityName--SecurityのレベルがIN scopedPDUを要求したという送信するメッセージのための送付SNMP実体IN securityModelのIN maxMessageSize--メッセージ(平文) 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 -- identification of the principal
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT securityStateReference -- reference to security state
) -- information, needed for response
statusInformation=--errorIndicationか成功; 誤りは誤りであるならOID/値を打ち返します; processIncomingMsg、(受信されたメッセージIN securityModel、ワイヤIN wholeMsgLength--ワイヤOUT securityEngineIDに受け取られる長さ--主要なOUT securityName--主要なOUT scopedPDUの識別--メッセージの識別のときに受け取られる受信されたメッセージIN securityLevel(Security IN wholeMsgのレベル)のためのIN messageProcessingModel(送付SNMP実体IN securityParametersの通常SNMPバージョンIN maxMessageSize)、(平文; )、OUT maxSizeResponseScopedPDU(Response PDU OUT securityStateReferenceの最大サイズ)がセキュリティ状態に参照をつけるペイロード); -- 情報; 応答に必要です。
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
statusInformationがgenerateResponseMsgと等しい、(IN messageProcessingModel--この主要なIN securityLevelを代表した送信されるメッセージIN securityEngineID(正式のSNMP実体IN securityName)、送信されるメッセージIN scopedPDUのための送付SNMP実体IN securityModelの通常SNMPバージョンIN globalData(メッセージヘッダー、アドミンデータIN maxMessageSize)--メッセージ(平文)ペイロード
Harrington, et. al. Standards Track [Page 31] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[31ページ]。
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
)
IN securityStateReference--セキュリティ状態の参照--オリジナルの要求OUT securityParametersからの情報--Security Module OUT wholeMsgによって記入されます--完全な発生しているメッセージOUT wholeMsgLength--長さの発生しているメッセージ)
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--リリースされるべき参照のハンドル)
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が送られるようどのように要求するか、そして、応答がどのようにそのアプリケーションに返されるかを(非同期に)示します。
Harrington, et. al. Standards Track [Page 32] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[32ページ]。
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| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|
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 a SNMP message is received, and how the Response is (asynchronously) send back to the network.
このダイヤグラムはpduTypeを扱うためのCommand ResponderかNotification Receiverアプリケーションレジスタと、ResponseがSNMPメッセージが受信されていた後にPDUがどうアプリケーションに派遣されるか、そして、どうあるかが(非同期に)どうネットワークを送り返すかを示しています。
Harrington, et. al. Standards Track [Page 33] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[33ページ]。
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 34] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[34ページ]。
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 "9711200000Z" -- 20 November 1997
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
snmpFrameworkMIBモジュールアイデンティティ最終更新日の"9711200000Z"--「以下をWGメールする」という1997年11月20日の組織「SNMPv3ワーキンググループ」コンタクトインフォメーション snmpv3@tis.com は申し込まれます: メッセージ本体の majordomo@tis.com : snmpv3を申し込んでください。
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
USA
email: mundy@tis.com
phone: +1 301-854-6889
議長: ラスマンディTrusted情報Systems郵便: 3060 ワシントンRdグレンウッドMD21738米国メール: mundy@tis.com 電話: +1 301-854-6889
Co-editor Dave Harrington
Cabletron Systems, Inc.
postal: Post Office Box 5005
Mail Stop: Durham
35 Industrial Way
Rochester, NH 03867-5005
USA
email: dbh@ctron.com
phone: +1 603-337-7357
共同エディタデーヴハリントンCabletron Systems Inc.郵便: 私書箱5005は停止を郵送します: ダラム35Industrial Wayニューハンプシャー03867-5005ロチェスター(米国)はメールされます: dbh@ctron.com 電話: +1 603-337-7357
Co-editor Randy Presuhn
BMC Software, Inc.
postal: 1190 Saratoga Avenue
Suite 130
San Jose, CA 95129
USA
email: rpresuhn@bmc.com
phone: +1 408-556-0720
共同エディタランディPresuhn BMC Software Inc.郵便: 1190サラトガアベニューSuite130カリフォルニア95129サンノゼ(米国)はメールされます: rpresuhn@bmc.com 電話: +1 408-556-0720
Co-editor: Bert Wijnen
IBM T.J. Watson Research
postal: Schagen 33
共同エディタ: バートWijnen IBM T.J.ワトソンResearch郵便: Schagen33
Harrington, et. al. Standards Track [Page 35] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[35ページ]。
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31 348-432-794
"
DESCRIPTION "The SNMP Management Architecture MIB"
::= { snmpModules 10 }
3461年のGLリンスホーテンオランダメール: wijnen@vnet.ibm.com 電話: +31 348-432-794、「記述、「SNMP管理体系MIB」:、:、」= 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.
SnmpEngineID:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「SNMPエンジンの行政上ユニークな識別子。」
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
インターネットAssigned民数記Authority(IANA)によって割り当てられるように最初の4つの八重奏がエージェントのSNMP管理私企業番号の2進の同等物に設定されます。 例えば、Acme Networksが企業696に配属されたなら、最初の4つの八重奏は配属されたでしょう。
Harrington, et. al. Standards Track [Page 36] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[36ページ]。
be assigned '000002b8'H.
'000002b8'H'は割り当てられてください。
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アドレスであるかもしれません、各アドレスが無作為の八重奏で適当に水増しされている状態で。 複数のメソッドが定義されるなら、最初の八重奏が、使用されるメソッドと残っている八重奏がメソッドの機能であることを示すのは、お勧めです。
3) The length of the octet strings 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
Harrington, et. al. Standards Track [Page 37] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[37ページ]。
5 - Octets, administratively assigned
Maximum remaining length 27
5--八重奏は行政上長さ27のままで残っているMaximumを割り当てました。
6-127 - reserved, unused
予約されて、未使用の6-127
127-255 - as defined by the enterprise
Maximum remaining length 27
"
SYNTAX OCTET STRING (SIZE(1..32))
127-255、長さ27の「構文八重奏ストリング」のままで残っている企業Maximumによって定義されます。(サイズ(1 .32))
SnmpSecurityModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a
securityModel of the Security Subsystem within the
SNMP Management Architecture.
SnmpSecurityModel:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「SNMP Management Architectureの中で唯一Security SubsystemのsecurityModelを特定する識別子。」
The values for securityModel are allocated as
follows:
以下の通りsecurityModelのための値を割り当てます:
- The zero value is reserved.
- 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
260.
例えば、enterpriseIDが1である企業によって定義された第4Security Modelは260歳でしょう。
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
255 Security Models per enterprise.
securityModel値の配分が最大255の規格を考慮するので、この体系は、Security Modelsを基礎づけて、1企業あたり最大255Security 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
同時に利用されたSecurity Modelsの数が大きければ大きいほど、その相互運用性が受ける機会が、より大きいので、新しいsecurityModel値の課題が実際にはまれになると信じられています。 その結果、そのような範囲が十分であると信じられています。 ありそうもないイベント、それ
Harrington, et. al. Standards Track [Page 38] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[38ページ]。
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 255
possible values.
規格委員会は、時間(255の追加可能な値を得るために数を割り当てることができる企業)、この数が不十分であることがわかります。
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
securityModels. This limits the ability to
define new proprietary implementations of Security
Models to the first 8,388,608 enterprises.
最も重要なビットがゼロであるに違いないというメモ。 したがって、様々な組織が標準的でないsecurityModelsを設計して、定義するように割り当てられた23ビットがあります。 これは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 a 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).
- Values greater than 255 are allocated to
enterprise-specific Message Processing Models.
An enterprise messageProcessingModel value is
defined to be:
- 0と255の間の包括的な値は、標準化過程Message Processing Modelsのために予約されて、インターネットAssigned民数記Authority(IANA)によって管理されます。 - 企業特有のMessage Processing Modelsに値より多くの255を割り当てます。 企業messageProcessingModel価値は、である:なるように定義されます。
Harrington, et. al. Standards Track [Page 39] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[39ページ]。
enterpriseID * 256 +
messageProcessingModel within enterprise
企業の中のenterpriseID*256+messageProcessingModel
For example, the fourth Message Processing Model
defined by the enterprise whose enterpriseID
is 1 would be 260.
例えば、enterpriseIDが1である企業によって定義された第4Message Processing Modelは260歳でしょう。
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Message Processing Models, and for a
maximum of 255 Message Processing Models per
enterprise.
securityModel値の配分が最大255の規格を考慮するので、この体系は、Message Processing Modelsを基礎づけて、1企業あたり最大255Message 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 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
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 40] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[40ページ]。
"
SYNTAX INTEGER(0..2147483647)
「構文整数」(0..2147483647)
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 "255a"
STATUS current
DESCRIPTION "An octet string containing administrative
information, preferably in human-readable form.
SnmpAdminString:、:= 「望ましくは人間読み込み可能なフォームに管理情報を含んでいて、八重奏は結ぶ」TEXTUAL-CONVENTION DISPLAY-ヒントの"255a"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 [RFC2044].
国際化を容易にするために、この情報は表された使用ISO/IECが八重奏ストリングとして[RFC2044]で説明された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.
追加コード・ポイントが10646規格の修正で時々加えられるので、0×00000000から0x7fffffffまであらゆるコード・ポイントに遭遇するように実装を準備しなければなりません。
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 41] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[41ページ]。
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コード化と同じです。
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
[RFC1905].
"
SYNTAX OCTET STRING (SIZE (0..255))
このTCが使用されるために使用されるか、または思い描かれるオブジェクトに使用されたらどんなオブジェクトインスタンスのためのサブ識別子の数もインデックス、次に、SIZE制限を指定しなければならないので128の限界を超えないように、それに注意してください、[RFC1905]によって定義されるように。 「構文八重奏ストリング」(サイズ(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
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
"
::= { snmpEngine 1 }
snmpEngineID OBJECT-TYPE SYNTAX SnmpEngineIDのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「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
snmpEngineBoots OBJECT-TYPE SYNTAX INTEGER(1 .2147483647)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「SNMPエンジンが持っている回数」です。
Harrington, et. al. Standards Track [Page 42] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[42ページ]。
(re-)initialized itself since its initial
configuration.
"
::= { snmpEngine 2 }
(再、)、初期の構成以来それ自体を初期化しました。 " ::= snmpEngine2
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the SNMP engine last
incremented the snmpEngineBoots object.
"
::= { snmpEngine 3 }
snmpEngineTime OBJECT-TYPE SYNTAX INTEGER(0 .2147483647)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「SNMPエンジン以来の秒数は最後に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
-- 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}
snmpFrameworkMIBCompliancesオブジェクト識別子:、:= snmpFrameworkMIBConformance1
Harrington, et. al. Standards Track [Page 43] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[43ページ]。
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
snmpFrameworkMIBGroupsオブジェクト識別子:、:= 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
values of an SNMP engine.
"
::= { snmpFrameworkMIBGroups 1 }
snmpEngineGroup OBJECT-GROUP OBJECTS、snmpEngineID、snmpEngineBoots、snmpEngineTime、snmpEngineMaxMessageSize、「構成を特定して、決定するためのオブジェクトの収集とSNMPの現在のタイムリー値は蒸気機関を備えている」STATUSの現在の記述。 " ::= snmpFrameworkMIBGroups1
END
終わり
6. Intellectual Property
6. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Harrington, et. al. Standards Track [Page 44] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[44ページ]。
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専務に情報を扱ってください。
7. Acknowledgements
7. 承認
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メンバー:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
デーヴBattle(SNMP研究Inc.) ユリ・ブルーメンソル(IBM T.J.ワトソン研究所) ジェフCase(SNMP研究Inc.) ジョン・カラン(BBN)・T.マックス・デブリン(高科学技術のコネクションズ)・ジョン・軽打(ヒューレットパッカード)デヴィッド・ハリントン(CabletronシステムInc.) ノースカロライナ州Hien(IBM T.J.ワトソン研究所) デーヴ・レビ(SNMP研究Inc.) ルイスはMamakos(UUNET技術Inc.)です。 ポール・マイヤー(安全なコンピューティング社)キースMcCloghrie(シスコシステムズ)ラス・マンディ(情報システムInc.を信じます) ボブNatale(ACE*COMM社)マイク・オデル(UUNET技術Inc.) デーヴ・パーキンス(DeskTalk)・ピーター・ポーキングホーン(Brunel大学)ランディPresuhn(BMCソフトウェアInc.) デヴィッド・リード(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.ワトソン研究所)
Harrington, et. al. Standards Track [Page 45] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[45ページ]。
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)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
ジェフCase(SNMP研究Inc.) デヴィッド・ハリントン(CabletronシステムInc.) デヴィッド・レビ(SNMP研究Inc.) キースMcCloghrie(シスコシステムズ)ブライアン・オキーフ(ヒューレットパッカード)・マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング)ジョンSaperia(BGSシステムInc.) スティーブWaldbusser(国際ネットワークサービス)グレンW.水域(ベル-北研究株式会社)
8. Security Considerations
8. セキュリティ問題
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.
アプリケーションは保証されないデータに近づく手段を持っています。 アプリケーションは、公開からデータを保護するために合理的な方法を採るべきです。
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)と実装は不注意な公開から構成秘密を保護します。
9. References
9. 参照
[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月)
Harrington, et. al. Standards Track [Page 46] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[46ページ]。
[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月。」
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Structure of Management Information for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[RFC1902]ケースとJ.とMcCloghrieとK.とローズ、M.とS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」RFC1902(1996年1月)。
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Management Information Base for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1907 January 1996.
[RFC1907]ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための管理情報ベース」、RFC1907 1996年1月。
[RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", RFC 1908, January 1996.
[RFC1908]ケースとJ.とMcCloghrieとK.とローズ、M.とS.Waldbusser、「インターネットの標準のNetwork Management Frameworkのバージョン1とバージョン2の間の共存」RFC1908(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月。
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and
ISO 10646", RFC 2044, October 1996.
[RFC2044]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[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月。
[RFC2272] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC 2272, January 1998.
[RFC2272] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2272、1998年1月。
Harrington, et. al. Standards Track [Page 47] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[47ページ]。
[RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based
Security Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2274, January 1998.
[RFC2274] ブルーメンソル、U.、およびB.Wijnen、「ユーザベースのセキュリティは簡単なネットワーク管理プロトコル(SNMPv3)のバージョン3のためにモデル化します」、RFC2274、1998年1月。
[RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie,
"View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC 2275, January 1998.
[RFC2275] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワーク管理プロトコルのための視点ベースのアクセス制御モデル(SNMP)」、RFC2275(1998年1月)。
[RFC2273] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2273, January 1998.
[RFC2273] レビとD.とマイヤー、P.とB.スチュワート、「SNMPv3アプリケーション」、RFC2273、1998年1月。
10. Editors' Addresses
10. エディタのアドレス
Bert Wijnen IBM T.J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
バートWijnen IBM T.J.ワトソン研究Schagen33 3461GLリンスホーテン・オランダ
Phone: +31 348-432-794 EMail: wijnen@vnet.ibm.com
以下に電話をしてください。 +31 348-432-794 メールしてください: wijnen@vnet.ibm.com
Dave Harrington Cabletron Systems, Inc Post Office Box 5005 Mail Stop: Durham 35 Industrial Way Rochester, NH 03867-5005 USA
デーヴハリントンCabletron Systems、Inc私書箱5005メール停止: ダラムの35の産業道のロチェスター、ニューハンプシャー03867-5005米国
Phone: +1 603-337-7357 EMail: dbh@ctron.com
以下に電話をしてください。 +1 603-337-7357 メールしてください: dbh@ctron.com
Randy Presuhn BMC Software, Inc. 1190 Saratoga Avenue Suite 130 San Jose, CA 95129 USA
ランディPresuhn BMCソフトウェアInc.1190サラトガアベニューSuite130カリフォルニア95129サンノゼ(米国)
Phone: +1 408-556-0720 EMail: rpresuhn@bmc.com
以下に電話をしてください。 +1 408-556-0720 メールしてください: rpresuhn@bmc.com
Harrington, et. al. Standards Track [Page 48] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[48ページ]。
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 49] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[49ページ]。
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 50] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[50ページ]。
A.1.3. Validate the security-stamp in a received message
A.1.3。 受信されたメッセージでセキュリティスタンプを有効にしてください。
A Message Processing Model requests that 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.
Message Processing Modelはそのa Security Modelを要求します: - メッセージは変更されていません--メッセージが生成された主体の識別を認証することを確かめます。 - それが暗号化されたなら、メッセージを解読します。
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 processMsg primitive as described in section 4.5.
Message Processing Modelはセクション4.5で説明されるように原始的にprocessMsgを使用します。
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.1.
キャッシュされたセキュリティー・データは、応答の世代を通してそれとなく発表されるか、または原始的にstateReleaseを使用することによって、明らかに発表されるかもしれません、セクション4.1で説明されるように。
Harrington, et. al. Standards Track [Page 51] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[51ページ]。
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 processMsg primitive, as
described in section 4.5.
Message Processing ModelはそれがサポートするSNMP Message形式を指定して、抽象的なデータ要素の値を決定する方法を説明します(msgID、msgMaxSize、msgFlags、msgSecurityParameters、securityLevel securityModelなどのように)。 Message Processing Modelは原始的にprocessMsgを使用することでメッセージのためのセキュリティ処理を提供するためにSecurity Modelと対話します、セクション4.5で説明されるように。
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.4
- 要求と通知のために: prepareOutgoingMessageセクション4.4で説明されて、
- for response messages: prepareResponseMessage, as described in
section 4.4
- 応答メッセージのために: prepareResponseMessageセクション4.4で説明されて、
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.5.
- 要求と通知のために: セクション4.5で説明されるようなgenerateRequestMsg。
- for response messages: generateResponseMsg as described in
section 4.5.
- 応答メッセージのために: セクション4.5で説明されるgenerateResponseMsg。
Harrington, et. al. Standards Track [Page 52] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[52ページ]。
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.2.
アプリケーションは、SNMPエンジンがセクション4.2で説明されるように原始的に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 53] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[53ページ]。
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.2.
SNMPエンジンは、このSNMPエンジンによって送られた傑出しているメッセージに入って来る応答メッセージを合わせて、原始的にprocessResponsePduを使用することで関連するアプリケーションへの応答を送ります、セクション4.2で説明されるように。
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.2.
非同期なメッセージを受け取りたがっているApplicationはセクション4.2で説明されるように原始の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.2.
非同期なメッセージを受け取るのを止めたいApplicationはSNMPエンジンがセクション4.2で説明されるように原始の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.2.
セクション4.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.2.
操作が応答を必要とするよう要求してください。 アプリケーションはセクション4.2で説明されるように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 54] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[54ページ]。
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を提供しなければなりません。
Harrington, et. al. Standards Track [Page 55] RFC 2271 SNMPv3 Architecture January 1998
etハリントン、アル。 規格はSNMPv3アーキテクチャ1998年1月にRFC2271を追跡します[55ページ]。
B. Full Copyright Statement
B。 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Harrington, et. al. Standards Track [Page 56]
etハリントン、アル。 標準化過程[56ページ]
一覧
スポンサーリンク
