RFC3410 日本語訳
3410 Introduction and Applicability Statements for Internet-StandardManagement Framework. J. Case, R. Mundy, D. Partain, B. Stewart. December 2002. (Format: TXT=61461 bytes) (Obsoletes RFC2570) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Case
Request for Comments: 3410 SNMP Research, Inc.
Obsoletes: 2570 R. Mundy
Category: Informational Network Associates Laboratories
D. Partain
Ericsson
B. Stewart
Retired
December 2002
コメントを求めるワーキンググループJ.ケース要求をネットワークでつないでください: Inc.が時代遅れにする3410年のSNMP研究: 2570年のR.マンディカテゴリ: 2002年12月に退職した情報のネットワーク関連研究所D.パーテインエリクソンのB.スチュワート
Introduction and Applicability Statements for
Internet Standard Management Framework
インターネットの標準の管理フレームワークのための序論と適用性声明
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet-standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).
SNMPバージョン3Framework(SNMPv3)は、このドキュメントの目的がインターネット標準のManagement Frameworkの第3バージョンの概要を提供することであると呼びました。 このFrameworkはオリジナルのインターネット標準のManagement Framework(SNMPv1)と第2インターネット標準のManagement Framework(SNMPv2)の両方を引き出されて、当てにします。
The architecture is designed to be modular to allow the evolution of the Framework over time.
アーキテクチャは、時間がたつにつれてFrameworkの発展を許容するためにはモジュールであるために設計されています。
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.
ドキュメントで、SNMPv1かSNMPv2の代わりにSNMPv3を使用するのがなぜ強く推薦されるかがわかります。 また、ドキュメントは、RFCs1157、1441、1901、1909、および1910が彼らをHistoric状態に動かすことによって回収されることを勧めます。 このドキュメントはRFC2570を時代遅れにします。
Case, et. al. Informational [Page 1] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[1ページ]のRFC3410適用性証明
Table of Contents
目次
1 Introduction ................................................. 2 2 The Internet Standard Management Framework ................... 3 2.1 Basic Structure and Components ............................. 4 2.2 Architecture of the Internet Standard Management Framework . 4 3 The SNMPv1 Management Framework .............................. 5 3.1 The SNMPv1 Data Definition Language ........................ 6 3.2 Management Information ..................................... 6 3.3 Protocol Operations ........................................ 7 3.4 SNMPv1 Security and Administration ......................... 7 4 The SNMPv2 Management Framework .............................. 8 5 The SNMPv3 Working Group ..................................... 8 6 SNMPv3 Framework Module Specifications ....................... 10 6.1 Data Definition Language ................................... 11 6.2 MIB Modules ................................................ 12 6.3 Protocol Operations and Transport Mappings ................. 13 6.4 SNMPv3 Security and Administration ......................... 13 7 Document Summaries ........................................... 14 7.1 Structure of Management Information ........................ 14 7.1.1 Base SMI Specification ................................... 15 7.1.2 Textual Conventions ...................................... 15 7.1.3 Conformance Statements ................................... 16 7.2 Protocol Operations ........................................ 16 7.3 Transport Mappings ......................................... 16 7.4 Protocol Instrumentation ................................... 17 7.5 Architecture / Security and Administration ................. 17 7.6 Message Processing and Dispatch (MPD) ...................... 17 7.7 SNMP Applications .......................................... 18 7.8 User-based Security Model (USM) ............................ 18 7.9 View-based Access Control (VACM) ........................... 19 7.10 SNMPv3 Coexistence and Transition ......................... 19 8 Standardization Status ....................................... 20 8.1 SMIv1 Status ............................................... 20 8.2 SNMPv1 and SNMPv2 Standardization Status ................... 21 8.3 Working Group Recommendation ............................... 22 9 Security Considerations ...................................... 22 10 References .................................................. 22 11 Editor's Addresses .......................................... 26 12 Full Copyright Statement .................................... 27
1つの序論… 2 2、インターネットの標準の管理フレームワーク… 3 2.1の基本構造とコンポーネント… 4 2.2 インターネットの標準の管理フレームワーク. 4 3のアーキテクチャ、SNMPv1管理フレームワーク… 5 3.1 SNMPv1データ定義言語… 6 3.2 管理情報… 6 3.3 操作について議定書の中で述べてください… 7 3.4のSNMPv1セキュリティと政権… 7 4、SNMPv2管理フレームワーク… 8 5SNMPv3作業部会… 8 6のSNMPv3フレームワークモジュール仕様… 10 6.1 データ定義言語… 11 6.2 MIBモジュール… 12 6.3 操作と輸送マッピングについて議定書の中で述べてください… 13 6.4のSNMPv3セキュリティと政権… 13 7 概要を記録してください… 14 7.1 経営情報の構造… 14 7.1 .1 SMI仕様を基礎づけてください… 15 7.1 .2 原文のコンベンション… 15 7.1 .3 順応声明… 16 7.2 操作について議定書の中で述べてください… 16 7.3 マッピングを輸送してください… 16 7.4 計装について議定書の中で述べてください… 17 7.5のアーキテクチャ/セキュリティと政権… 17 7.6 メッセージ処理と発信(MPD)… 17 7.7 SNMPアプリケーション… 18 7.8 ユーザベースのセキュリティは(USM)をモデル化します… 18 7.9 視点ベースのアクセス制御(VACM)… 19 7.10のSNMPv3共存と変遷… 19 8 標準化状態… 20 8.1 SMIv1状態… 20 8.2 SNMPv1とSNMPv2標準化状態… 21 8.3 ワーキンググループ推薦… 22 9 セキュリティ問題… 22 10の参照箇所… 22 11エディタのアドレス… 26 12の完全な著作権宣言文… 27
1. Introduction
1. 序論
This document is an introduction to the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Management Framework (SNMPv3) and has multiple purposes.
このドキュメントは、インターネット標準のManagement Frameworkの第3バージョンへの紹介であり、Management Framework(SNMPv3)とSNMPバージョン3を呼んで、複数の目的を持っています。
Case, et. al. Informational [Page 2] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[2ページ]のRFC3410適用性証明
First, it describes the relationship between the SNMP version 3 (SNMPv3) specifications and the specifications of the SNMP version 1 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Framework, and the Community-based Administrative Framework for SNMPv2.
まず最初に、それはSNMPv2のためにSNMPバージョン3(SNMPv3)仕様とSNMPバージョン1(SNMPv1)管理Framework、SNMPバージョン2(SNMPv2)管理Framework、およびCommunityベースのAdministrative Frameworkの仕様との関係について説明します。
Second, it provides a roadmap to the multiple documents which contain the relevant specifications.
2番目に、それは関連仕様を含む複数のドキュメントに道路地図を供給します。
Third, this document provides a brief easy-to-read summary of the contents of each of the relevant specification documents.
3番目に、このドキュメントは読みやすいそれぞれの関連仕様ドキュメントのコンテンツの簡潔な概要を提供します。
This document is intentionally tutorial in nature and, as such, may occasionally be "guilty" of oversimplification. In the event of a conflict or contradiction between this document and the more detailed documents for which this document is a roadmap, the specifications in the more detailed documents shall prevail.
このドキュメントは故意に現実に個人指導用です、そして、時折そういうものとして簡略化のしすぎに関して「有罪であるかもしれません」。 このドキュメントが道路地図であるこのドキュメントと、より詳細なドキュメントでの闘争か矛盾の場合、より詳細なドキュメントの仕様は広がっているものとします。
Further, the detailed documents attempt to maintain separation between the various component modules in order to specify well- defined interfaces between them. This roadmap document, however, takes a different approach and attempts to provide an integrated view of the various component modules in the interest of readability.
さらに、よく指定するために様々な複合部品の間の分離を維持する詳細なドキュメント試みはそれらの間のインタフェースを定義しました。 この道路地図ドキュメントは、しかしながら、異なるアプローチを取って、様々な複合部品の統合意見を読み易さのために提供するのを試みます。
This document is a work product of the SNMPv3 Working Group of the Internet Engineering Task Force (IETF).
このドキュメントはSNMPv3インターネット・エンジニアリング・タスク・フォース作業部会(IETF)の作業生産物です。
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 BCP 14, RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. The Internet Standard Management Framework
2. インターネットの標準の管理フレームワーク
The third version of the Internet Standard Management Framework (the SNMPv3 Framework) is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).
インターネットStandard Management Framework(SNMPv3 Framework)の第3バージョンは、オリジナルのインターネット標準のManagement Framework(SNMPv1)と第2インターネット標準のManagement Framework(SNMPv2)の両方を引き出されて、当てにします。
All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard Management SNMP Framework share the same basic structure and components. Furthermore, all versions of the specifications of the Internet Standard Management Framework follow the same architecture.
インターネットStandard Management SNMP Frameworkのすべてのバージョン(SNMPv1、SNMPv2、およびSNMPv3)が同じ基本構造とコンポーネントを共有します。 その上、インターネットStandard Management Frameworkの仕様のすべてのバージョンが同じアーキテクチャに従います。
Case, et. al. Informational [Page 3] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[3ページ]のRFC3410適用性証明
2.1. Basic Structure and Components
2.1. 基本構造とコンポーネント
An enterprise deploying the Internet Standard Management Framework contains four basic components:
インターネットStandard Management Frameworkを配布する企業は4つの基本的なコンポーネントを含みます:
* several (typically many) managed nodes, each with an SNMP entity
which provides remote access to management instrumentation
(traditionally called an agent);
* 数個(通常多くの)がノードを管理しました、それぞれ管理計装(伝統的にエージェントと呼ばれる)に遠隔アクセスを提供するSNMP実体で。
* at least one SNMP entity with management applications (typically
called a manager),
* 管理アプリケーション(通常マネージャと呼ばれる)がある少なくとも1つのSNMP実体
* a management protocol used to convey management information
between the SNMP entities, and
* そして管理プロトコルが以前はよくSNMP実体の間に経営情報を伝えていた。
* management information.
* 経営情報。
The management protocol is used to convey management information between SNMP entities such as managers and agents.
管理プロトコルは、マネージャやエージェントなどのSNMP実体の間に経営情報を伝えるのに使用されます。
This basic structure is common to all versions of the Internet Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3.
この基本構造はインターネットStandard Management Frameworkのすべてのバージョンに共通です。 すなわち、SNMPv1、SNMPv2、およびSNMPv3。
2.2. Architecture of the Internet Standard Management Framework
2.2. インターネットの標準の管理フレームワークのアーキテクチャ
The specifications of the Internet Standard Management Framework are based on a modular architecture. This framework is more than just a protocol for moving data. It consists of:
インターネットStandard Management Frameworkの仕様はモジュールのアーキテクチャに基づいています。 このフレームワークは感動的なデータのためのまさしくプロトコル以上です。 それは以下から成ります。
* a data definition language,
* データ定義言語
* definitions of management information (the Management Information
Base, or MIB),
* 経営情報(Management Information基地、またはMIB)の定義
* a protocol definition, and
* そしてプロトコル定義。
* security and administration.
* セキュリティと管理。
Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to SNMPv3, the definitions of each of these architectural components have become richer and more clearly defined, but the fundamental architecture has remained consistent.
時間、FrameworkがSNMPv1からSNMPv2まで発展したSNMPv3に、それぞれのこれらの建築構成の定義は、より豊かで明確により定義されるようになりましたが、基本的なアーキテクチャは一貫していたままで残っています。
One prime motivator for this modularity was to enable the ongoing evolution of the Framework, as is documented in RFC 1052 [2]. When originally envisioned, this capability was to be used to ease the transition from SNMP-based management of internets to management based on OSI protocols. To this end, the framework was architected
このモジュール方式のための1人の主要な動機付け要因がRFC1052[2]に記録されていた状態でそのままなFrameworkの進行中の発展を可能にすることになっていました。 元々思い描かれると、この能力はインターネットのSNMPを拠点とする管理からOSIプロトコルに基づく管理までの変遷を緩和するのに使用されることでした。 このために、フレームワークはarchitectedされました。
Case, et. al. Informational [Page 4] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[4ページ]のRFC3410適用性証明
with a protocol-independent data definition language and Management Information Base along with a MIB-independent protocol. This separation was designed to allow the SNMP-based protocol to be replaced without requiring the management information to be redefined or reinstrumented. History has shown that the selection of this architecture was the right decision for the wrong reason -- it turned out that this architecture has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition away from management based on the Simple Network Management Protocol.
MIB-独立者に伴うプロトコルから独立しているデータ定義言語とManagement Information基地で、議定書を作ってください。 この分離は、経営情報が再定義されるか、または「再-器具を取り付け」られる必要でないSNMPベースのプロトコルが取り替えられるのを許容するように設計されました。 歴史は、このアーキテクチャの選択が間違った理由のための正しい決定であったのを示しました--このアーキテクチャがSimple Network Managementプロトコルに基づく管理から遠くで変遷を緩和するよりむしろSNMPv1からSNMPv2までSNMPv2からSNMPv3までの変遷を緩和したと判明しました。
The SNMPv3 Framework builds and extends these architectural principles by:
SNMPv3 Frameworkは以下でこれらの建築原則を築き上げて、敷衍します。
* building on these four basic architectural components, in some
cases incorporating them from the SNMPv2 Framework by reference,
and
* そしていくつかの場合、SNMPv2 Frameworkから参照でそれらを取り入れて、これらの4つの基本的な建築構成の上に建てる。
* by using these same layering principles in the definition of new
capabilities in the security and administration portion of the
architecture.
* アーキテクチャのセキュリティと管理部分との新しい能力の定義にこれらの同じレイヤリング原則を使用することによって。
Those who are familiar with the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework will find many familiar concepts in the architecture of the SNMPv3 Management Framework. However, in some cases, the terminology may be somewhat different.
SNMPv1 Management FrameworkとSNMPv2 Management Frameworkのアーキテクチャに詳しいものはSNMPv3 Management Frameworkのアーキテクチャの多くの身近な概念を見つけるでしょう。 しかしながら、いくつかの場合、用語はいくらか異なっているかもしれません。
3. The SNMPv1 Management Framework
3. SNMPv1管理フレームワーク
The original Internet-Standard Network Management Framework (SNMPv1) is defined in the following documents:
オリジナルのインターネット標準のNetwork Management Framework(SNMPv1)は以下のドキュメントで定義されます:
* STD 16, RFC 1155 [3] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and naming
objects for the purpose of management.
* STD16、Management情報(SMI)のStructureを定義するRFC1155[3]、メカニズムは説明と命名に管理の目的のためのオブジェクトを使用しました。
* STD 16, RFC 1212 [4] which defines a more concise description
mechanism for describing and naming management information
objects, but which is wholly consistent with the SMI.
* STD16、経営情報をオブジェクトと説明して、命名するために定義していますが、より簡潔な記述メカニズムをSMIと完全に一致させたRFC1212[4]。
* STD 15, RFC 1157 [5] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to managed
objects and event notification. Note this document also defines
an initial set of event notifications.
* STD15、Simple Network Managementプロトコル(SNMP)(管理オブジェクトへのネットワークアクセスとイベント通知に使用されるプロトコル)を定義するRFC1157[5]。 また、このドキュメントが1人の始発に関するイベント通知を定義することに注意してください。
Case, et. al. Informational [Page 5] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[5ページ]のRFC3410適用性証明
Additionally, two documents are generally considered companions to these three:
さらに、一般に、2通のドキュメントがこれらの3への仲間であると考えられます:
* STD 17, RFC 1213 [6] which contains definitions for the base set
of management information
* STD17、経営情報の基底集合のための定義を含むRFC1213[6]
* RFC 1215 [7] defines a concise description mechanism for defining
event notifications, which are called traps in the SNMPv1
protocol. It also specifies the generic traps from RFC 1157 in
the concise notation.
* RFC1215[7]は、イベント通知を定義するために簡潔な説明メカニズムを定義します。(通知はSNMPv1プロトコルの罠と呼ばれます)。 また、それはRFC1157から簡潔な記法でジェネリック罠を指定します。
These documents describe the four parts of the first version of the SNMP Framework.
これらのドキュメントはSNMP Frameworkの最初のバージョンの4箇所について説明します。
3.1. The SNMPv1 Data Definition Language
3.1. SNMPv1データ定義言語
The first two and the last document, i.e., RFCs 1155, 1212, and 1215, describe the SNMPv1 data definition language and are often collectively referred to as "SMIv1". Note that due to the initial requirement that the SMI be protocol-independent, the first two SMI documents do not provide a means for defining event notifications (traps). Instead, the SNMP protocol document defines a few standardized event notifications (generic traps) and provides a means for additional event notifications to be defined. The last document specifies a straight-forward approach towards defining event notifications used with the SNMPv1 protocol. At the time that it was written, use of traps in the Internet-Standard network management framework was controversial. As such, RFC 1215 was put forward with the status of "Informational", which was never updated because it was believed that the second version of the SNMP Framework would replace the first version.
最初の2と最後のドキュメント(すなわち、RFCs1155、1212、および1215)は、SNMPv1データ定義言語について説明して、しばしば"SMIv1""とまとめて呼ばれます。 SMIがプロトコルから独立しているという初期の要件のため、最初の2通のSMIドキュメントがイベント通知(罠)を定義するための手段を提供しないことに注意してください。 代わりに、SNMPプロトコルドキュメントは、いくつかの標準化されたイベント通知(ジェネリック罠)を定義して、追加イベント通知が定義される手段を提供します。 最後のドキュメントはSNMPv1プロトコルと共に使用されるイベント通知を定義することに向かった簡単なアプローチを指定します。 それが書かれた時に、インターネット標準のネットワークマネージメントフレームワークにおける罠の使用は論議を呼んでいました。 そういうものとして、RFC1215は「情報」の状態で進められました。(SNMP Frameworkの第2バージョンが最初のバージョンを置き換えると信じられていたので、それは、決してアップデートされませんでした)。
3.2. Management Information
3.2. 経営情報
The data definition language described in the first two documents was first used to define the now-historic MIB-I as specified in RFC 1066 [8], and was subsequently used to define MIB-II as specified in RFC 1213 [6].
最初の2通のドキュメントで説明されたデータ定義言語は、RFC1066[8]の指定されるとしての現在歴史的なMIB-Iを定義するのに使用される1番目であり、次に、RFC1213[6]の指定されるとしてのMIB-IIを定義するのに使用されました。
Later, after the publication of MIB-II, a different approach to the management information definition was taken from the earlier approach of having a single committee staffed by generalists work on a single document to define the Internet-Standard MIB. Rather, many mini-MIB documents were produced in a parallel and distributed fashion by groups chartered to produce a specification for a focused portion of the Internet-Standard MIB and staffed by personnel with expertise in those particular areas ranging from various aspects of network management, to system management, and application management.
その後、MIB-IIの公表の後に、インターネット標準のMIBを定義するためにただ一つのドキュメントへのジェネラリスト作業で単一委員会を配置させる以前のアプローチから経営情報定義への異なるアプローチを取りました。 むしろ、多くのミニMIBドキュメントが、平行で分配されたファッションでインターネット標準のMIBの集中している部分のための仕様を作り出すためにチャーターされたグループによって製作されて、それらの特定の領域の専門的技術がネットワークマネージメントの種々相から変化している状態で、人員によって配置されました、システム管理、およびアプリケーション管理に。
Case, et. al. Informational [Page 6] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[6ページ]のRFC3410適用性証明
3.3. Protocol Operations
3.3. プロトコル操作
The third document, STD 15 [5], describes the SNMPv1 protocol operations performed by protocol data units (PDUs) on lists of variable bindings and describes the format of SNMPv1 messages. The operators defined by SNMPv1 are: get, get-next, get-response, set- request, and trap. Typical layering of SNMP on a connectionless transport service is also defined.
3番目のドキュメント(STD15[5])は、プロトコルデータ単位(PDUs)によって変項束縛のリストに実行されたSNMPv1プロトコル操作について説明して、SNMPv1メッセージの形式について説明します。 SNMPv1によって定義されたオペレータは以下の通りです。 気付いて、応答を得るのに得てください、そして、要求を設定してください、そして、捕らえてください。 また、コネクションレスな輸送サービスのSNMPの典型的なレイヤリングは定義されます。
3.4. SNMPv1 Security and Administration
3.4. SNMPv1セキュリティと政権
STD 15 [5] also describes an approach to security and administration. Many of these concepts are carried forward and some, particularly security, are extended by the SNMPv3 Framework.
また、STD15[5]はセキュリティと管理にアプローチを説明します。 これらの概念の多くが進展します、そして、或るもの(特にセキュリティ)はSNMPv3 Frameworkによって広げられます。
The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP messages between SNMP entities and distinguishes between application entities and protocol entities. In SNMPv3, these are renamed applications and engines, respectively.
SNMPv1 FrameworkはSNMP実体の間のSNMPメッセージでSNMPv1 PDUsのカプセル化について説明して、アプリケーション実体とプロトコル実体を見分けます。 SNMPv3では、これらはそれぞれアプリケーションとエンジンに改名されます。
The SNMPv1 Framework also introduces the concept of an authentication service supporting one or more authentication schemes. In addition to authentication, SNMPv3 defines the additional security capability referred to as privacy. (Note: some literature from the security community would describe SNMPv3 security capabilities as providing data integrity, source authenticity, and confidentiality.) The modular nature of the SNMPv3 Framework permits both changes and additions to the security capabilities.
また、SNMPv1 Frameworkは1つ以上の認証体系をサポートする認証サービスの概念を紹介します。 認証に加えて、SNMPv3はプライバシーと呼ばれた追加担保能力を定義します。 (注意: 安全保障共同体からの何らかの文学が、SNMPv3セキュリティ能力がデータ保全、ソースの信憑性、および秘密性を提供すると記述するでしょう。) SNMPv3 Frameworkのモジュールの自然は変化と追加の両方をセキュリティ能力に可能にします。
Finally, the SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control. With this capability, SNMPv3 provides the means for controlling access to information on managed devices.
最終的に、SNMPv1 FrameworkはSNMP MIB視点と呼ばれる概念に基づくアクセスコントロールを紹介します。 SNMPv3 Frameworkは視点ベースのアクセスコントロールと呼ばれる基本的に同様の概念を指定します。 この能力に、SNMPv3は管理されたデバイスで情報入手を制御するための手段を提供します。
However, while the SNMPv1 Framework anticipated the definition of multiple authentication schemes, it did not define any such schemes other than a trivial authentication scheme based on community strings. This was a known fundamental weakness in the SNMPv1 Framework but it was thought at that time that the definition of commercial grade security might be contentious in its design and difficult to get approved because "security" means many different things to different people. To that end, and because some users do not require strong authentication, the SNMPv1 architected an authentication service as a separate block to be defined "later" and the SNMPv3 Framework provides an architecture for use within that block as well as a definition for its subsystems.
しかしながら、SNMPv1 Frameworkが複数の認証体系の定義を予期していた間、それは共同体ストリングに基づく些細な認証体系以外のどんなそのような体系も定義しませんでした。 これはSNMPv1 Frameworkの知られている基本的脆弱性でしたが、その時、「セキュリティ」が異なった人々に多くのいろいろなものを意味するので、商用銘柄セキュリティの定義はデザインで議論好きであって、承認させるのが難しいかもしれないと思われました。 それに、終わってください、そして、何人かのユーザは必要でないので、サブシステムのために、強い認証、「後で」定義されるべき別々のブロックとSNMPv3 Frameworkとしての認証サービスがそのブロックの中の使用のためのアーキテクチャを供給するSNMPv1 architectedを定義と同じくらいよく、必要としてください。
Case, et. al. Informational [Page 7] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[7ページ]のRFC3410適用性証明
4. The SNMPv2 Management Framework
4. SNMPv2管理フレームワーク
The SNMPv2 Management Framework is described in [8-13] and coexistence and transition issues relating to SNMPv1 and SNMPv2 are discussed in [15].
SNMPv2 Management Frameworkは[8-13]で説明されます、そして、[15]でSNMPv1とSNMPv2に関連する共存と変遷問題について議論します。
SNMPv2 provides several advantages over SNMPv1, including:
SNMPv2はSNMPv1、包含よりいくつかの利点を提供します:
* expanded data types (e.g., 64 bit counter)
* 拡張データ型(例えば、64ビットのカウンタ)
* improved efficiency and performance (get-bulk operator)
* 改良された効率と性能(嵩を得ているオペレータ)
* confirmed event notification (inform operator)
* 確認されたイベント通知(オペレータに知らせます)
* richer error handling (errors and exceptions)
* より豊かなエラー処理(誤りと例外)
* improved sets, especially row creation and deletion
* 改良されたセット、特に行作成、および削除
* fine tuning of the data definition language
* データ定義言語の微調整
However, the SNMPv2 Framework, as described in these documents, is incomplete in that it does not meet the original design goals of the SNMPv2 project. The unmet goals included provision of security and administration delivering so-called "commercial grade" security with:
しかしながら、SNMPv2プロジェクトの当初の設計目標を達成しないので、これらのドキュメントで説明されるSNMPv2 Frameworkは不完全です。 unmet目標は以下でいわゆる「商用銘柄」セキュリティを提供するセキュリティと管理の支給を含んでいました。
* authentication: origin identification, message integrity, and
some aspects of replay protection;
* 認証: 反復操作による保護の発生源識別、メッセージの保全、およびいくつかの局面。
* privacy: confidentiality;
* プライバシー: 秘密性。
* authorization and access control; and
* 承認とアクセスは制御されます。 そして
* suitable remote configuration and administration capabilities for
these features.
* これらの特徴のための適当なリモート構成と管理能力。
The SNMPv3 Management Framework, as described in this document and the companion documents, addresses these significant deficiencies.
このドキュメントと仲間ドキュメントで説明されるSNMPv3 Management Frameworkは、これらが重要な欠乏であると扱います。
5. The SNMPv3 Working Group
5. SNMPv3作業部会
This document, and its companion documents, were produced by the SNMPv3 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 Working Group was chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group was to produce the necessary set of documents that provide a single standard for the next generation of core SNMP functions. The single, most critical need in the next generation is a definition of security and administration that makes SNMP-based management transactions secure
このドキュメント、およびその仲間ドキュメントはSNMPv3インターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって製作されました。 SNMPv3作業部会は、SNMPの次世代のために推薦を準備するためにチャーターされました。 作業部会の目標はコアSNMP機能の次世代に単本位制を提供する必要なセットのドキュメントを製作することでした。 単一の、そして、最も重要な必要性は次の世代にSNMPベースの管理トランザクションを安全にするセキュリティと管理の定義です。
Case, et. al. Informational [Page 8] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[8ページ]のRFC3410適用性証明
in a way which is useful for users who wish to use SNMPv3 to manage networks, the systems that make up those networks, and the applications which reside on those systems, including manager-to- agent, agent-to-manager, and manager-to-manager transactions.
SNMPv3を使用して、そうしたがっているユーザの役に立つ方法でネットワーク、それらのネットワークを構成しているシステム、およびマネージャからエージェント、エージェントからマネージャ、およびマネージャからマネージャへのトランザクションを含むそれらのシステムの上にあるアプリケーションを経営してください。
In the several years prior to the chartering of the Working Group, there were a number of activities aimed at incorporating security and other improvements to SNMP. These efforts included:
作業部会の特許の数年前には、セキュリティを取り入れるのが目的とされた多くの活動とSNMPへの他の改良がありました。 これらの取り組みは:だった
* "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353),
* 1991-1992(RFC1351--RFC1353)頃の"SNMP Security"
* "SMP" circa 1992-1993, and
* そして1992-1993頃の"SMP"。
* "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa
1993-1995 (RFC 1441 - RFC 1452).
* 「1993-1995(RFC1441--RFC1452)頃のパーティベースのSNMPv2"(時々"SNMPv2p"と呼ばれます)。」
Each of these efforts incorporated commercial grade, industrial strength security including authentication, privacy, authorization, view-based access control, and administration, including remote configuration.
それぞれのこれらの取り組みは商用銘柄、認証、プライバシー、承認、視点ベースのアクセスコントロール、および管理を含む主力産業セキュリティを取り入れました、リモート構成を含んでいて。
These efforts fed the development of the SNMPv2 Management Framework as described in RFCs 1902 - 1908. However, the Framework described in those RFCs had no standards-based security and administrative framework of its own; rather, it was associated with multiple security and administrative frameworks, including:
これらの取り組みはRFCs1908年に1902--説明されるようにSNMPv2 Management Frameworkの開発を食べさせました。 しかしながら、それらのRFCsで説明されたFrameworkはそれ自身の規格ベースのセキュリティとどんな管理フレームワークも持っていませんでした。 むしろ、それは複数のセキュリティと管理フレームワーク、包含に関連していました:
* "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901
[16],
* 「RFC1901[16]で説明されるCommunityベースのSNMPv2"(SNMPv2c)」
* "SNMPv2u" as described in RFCs 1909 and 1910, and
* そしてRFCs1909と1910年に説明される"SNMPv2u"。
* "SNMPv2*."
* 「SNMPv2*。」
SNMPv2c had the most support within the IETF but had no security and administration whereas both SNMPv2u and SNMPv2* had security but lacked a consensus of support within the IETF.
SNMPv2cには、IETFの中に最も多くのサポートを持っていましたが、セキュリティと管理は全くありませんでしたが、SNMPv2uとSNMPv2*の両方が、セキュリティを持っていましたが、IETFの中でサポートのコンセンサスを欠いていました。
The SNMPv3 Working Group was chartered to produce a single set of specifications for the next generation of SNMP, based upon a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as was suggested by an advisory team which was formed to provide a single recommended approach for SNMP evolution.
SNMPv3作業部会は、SNMP発展のためのただ一つのお勧めのアプローチを提供するために形成された顧問チームによって示されたように概念の集合とSNMPv2uとSNMPv2*のテクニカル・エレメンツに基づくSNMPの次世代のための1セットの仕様を作り出すためにチャーターされました。
Case, et. al. Informational [Page 9] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[9ページ]のRFC3410適用性証明
In so doing, the Working Group charter defined the following objectives:
そうする際に、作業部会特許は以下の目的を定義しました:
* accommodate the wide range of operational environments with
differing management demands;
* 異なった管理要求がある広範囲の運用環境を収容してください。
* facilitate the need to transition from previous, multiple
protocols to SNMPv3;
* 前であるのからの変遷、SNMPv3への複数のプロトコルに必要性を容易にしてください。
* facilitate the ease of setup and maintenance activities.
* セットアップとメインテナンス活動の容易さを容易にしてください。
In the initial work of the SNMPv3 Working Group, the group focused on security and administration, including:
SNMPv3作業部会の初期の仕事では、以下を含んでいて、グループはセキュリティと管理に焦点を合わせました。
* authentication and privacy,
* 認証とプライバシー
* authorization and view-based access control, and
* そして承認と視点ベースのアクセスが制御される。
* standards-based remote configuration of the above.
* 上記での規格ベースのリモート構成。
The SNMPv3 Working Group did not "reinvent the wheel", but reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those portions of the design that were outside the focused scope.
SNMPv3作業部会は、「わざわざ一からやり直しませんでした」が、SNMPv2 Draft Standardドキュメント(すなわち、集中している範囲の外にあったデザインのそれらの部分へのRFCs1902年から1908)を再利用しました。
Rather, the primary contributors to the SNMPv3 Working Group, and the Working Group in general, devoted their considerable efforts to addressing the missing link -- security and administration -- and in the process made invaluable contributions to the state-of-the-art of management.
むしろ、SNMPv3作業部会、および一般に、作業部会のプライマリ貢献者は、失われた鎖の環(セキュリティと管理)を扱うのに彼らのかなりの取り組みをささげて、プロセスで管理の最先端への非常に貴重な貢献をしました。
They produced a design based on a modular architecture with evolutionary capabilities with emphasis on layering. As a result, SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities.
彼らはレイヤリングへの強調で進化論の能力があるモジュールのアーキテクチャに基づくデザインを生産しました。 その結果、追加担保と管理能力があるSNMPv2としてSNMPv3を考えることができます。
In doing so, the Working Group achieved the goal of producing a single specification which has not only the endorsement of the IETF but also has security and administration.
そうする際に、作業部会はIETFの裏書きしか持っていませんが、セキュリティと管理をまた持っているただ一つの仕様を作り出すという目標を達成しました。
6. SNMPv3 Framework Module Specifications
6. SNMPv3フレームワークモジュール仕様
The specification of the SNMPv3 Management Framework is partitioned in a modular fashion among several documents. It is the intention of the SNMPv3 Working Group that, with proper care, any or all of the individual documents can be revised, upgraded, or replaced as requirements change, new understandings are obtained, and new technologies become available.
SNMPv3 Management Frameworkの仕様はいくつかのドキュメントの中のモジュール方式で仕切られます。 それは要件が変化して、新しい疎通を得て、新技術が利用可能になるとき、個々の文献のいずれかすべてを適切な注意に改訂するか、アップグレードするか、または取り替えることができるというSNMPv3作業部会の意志です。
Case, et. al. Informational [Page 10] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[10ページ]のRFC3410適用性証明
Whenever feasible, the initial document set which defines the SNMPv3 Management Framework leverages prior investments defining and implementing the SNMPv2 Management Framework by incorporating by reference each of the specifications of the SNMPv2 Management Framework.
可能であるときはいつも、SNMPv3 Management Frameworkを定義する初期の文献集合は参照でそれぞれのSNMPv2 Management Frameworkの仕様を取り入れることによってSNMPv2 Management Frameworkを定義して、実装する先行投資を利用します。
The SNMPv3 Framework augments those specifications with specifications for security and administration for SNMPv3.
SNMPv3 Frameworkはセキュリティのための仕様とSNMPv3のための管理と共にそれらの仕様を増大させます。
The documents which specify the SNMPv3 Management Framework follow the same architecture as those of the prior versions and can be organized for expository purposes into four main categories as follows:
SNMPv3 Management Frameworkを指定するドキュメントは、先のバージョンのものと同じアーキテクチャに従って、解説の目的のために以下の4つの主なカテゴリへまとめることができます:
* the data definition language,
* データ定義言語
* Management Information Base (MIB) modules,
* 管理Information基地(MIB)のモジュール
* protocol operations, and
* そして操作について議定書の中で述べてください。
* security and administration.
* セキュリティと管理。
The first three sets of documents are incorporated from SNMPv2. The documents in the fourth set are new to SNMPv3, but, as described previously, build on significant prior related works.
最初の3セットのドキュメントはSNMPv2から法人組織です。 4番目のセットにおけるドキュメントはSNMPv3に新しいのですが、以前に説明されるように、重要な先の関連する作品の上に建ててください。
6.1. Data Definition Language
6.1. データ定義言語
The specifications of the data definition language include STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [17], and related specifications. These documents are updates of RFCs 1902 - 1904 [9-11] which have evolved independently from the other parts of the framework and were republished with minor editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted from Draft Standard to full Standard.
データ定義言語の仕様はSTD58、RFC2578、「経営情報バージョン2(SMIv2)の構造」[17]、および関連する仕様を含んでいます。 これらのドキュメントはSTD58(RFCs2578--2580[17-19]Draft Standardから完全なStandardに促進されると)としてフレームワークの他の部品から独自に発展して、小さい方の編集の変化で再刊されたRFCs1904年[9-11テロ]の1902--最新版です。
The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules. Related specifications include STD 58, RFCs 2579, 2580.
Management情報(SMIv2)のStructureはMIBモジュールを書いて、改訂するための基本的なデータ型、オブジェクト・モデル、および規則を定義します。 RFCs2579、2580、関連仕様はSTD58を含んでいます。
STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an initial set of shorthand abbreviations which are available for use within all MIB modules for the convenience of human readers and writers.
STD58、RFC2579、「SMIv2"[18]のための原文のコンベンション、1人の始発の人間の読者と作家の都合のためにすべてのMIBモジュールの中で使用に利用可能な速記略語を定義する、」
Case, et. al. Informational [Page 11] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[11ページ]のRFC3410適用性証明
STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines the format for compliance statements which are used for describing requirements for agent implementations and capability statements which can be used to document the characteristics of particular implementations.
STD58、RFC2580、「SMIv2"[19]のための順応声明、エージェント実装のための要件について説明するのに使用される承諾声明と特定の実装の特性を記録するのに使用できる能力声明のためにフォーマットを定義する、」
The term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
「それには用語のユーザが少なくとも2つの異なった意味がいるつもりであるので、SMIv2"はいくらかあいまいである」用語。 時々、用語はRFCs2580年に2578--まとめて定義されたSTD58の全体のデータ定義言語を参照するのに使用されますが、他の時に、それは、RFC2578で定義されたデータ定義言語の部分だけについて言及するのに使用されます。 このあいまいさは、不幸ですが、めったに実際には重大な問題ではありません。
6.2. MIB Modules
6.2. MIBモジュール
MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements specified in terms of appropriate object and event notification groups. As such, MIB modules define the management information maintained by the instrumentation in managed nodes, made remotely accessible by management agents, conveyed by the management protocol, and manipulated by management applications.
MIBモジュールは、通常、オブジェクト定義を含んでいて、イベント通知の定義を含んでいて、時々適切なオブジェクトに関して指定された承諾声明とイベント通知グループを含むかもしれません。 そういうものとして、MIBモジュールは管理アプリケーションで管理されたノードにおける計装で維持されて、管理プロトコルによって運ばれた管理エージェントがほんの少しアクセスしやすく作られていて、操られた経営情報を定義します。
MIB modules are defined according to the rules defined in the documents which specify the data definition language, principally the SMI as supplemented by the related specifications.
データ定義言語を指定するドキュメント、主に関連する仕様で補われるSMIで定義された規則に従って、MIBモジュールは定義されます。
There is a large and growing number of standards-track MIB modules, as defined in the periodically updated "Internet Official Protocol Standards" list [20]. As of this writing, there are more than 100 standards-track MIB modules with a total number of defined objects exceeding 10,000. In addition, there is an even larger and growing number of enterprise-specific MIB modules defined unilaterally by various vendors, research groups, consortia, and the like resulting in an unknown and virtually uncountable number of defined objects.
大きくて増加している数の標準化過程MIBモジュールがあります、定期的にアップデートされた「インターネット公式プロトコル標準」リスト[20]で定義されるように。 この書くこと現在、総数の定義されたオブジェクトが1万を超えている100以上の標準化過程MIBモジュールがあります。 さらに、未知の、そして、実際には数えられない数の定義されたオブジェクトをもたらす様々なベンダー、研究グループ、コンソーシアム、および同様のものによって一方的に定義された偶数の、より大きくて増加している数の企業特有のMIBモジュールがあります。
In general, management information defined in any MIB module, regardless of the version of the data definition language used, can be used with any version of the protocol. For example, MIB modules defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management Framework and can be conveyed by the protocols specified therein. Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be conveyed by it. However, there is one noteworthy exception: the Counter64 datatype which can be defined in a MIB module defined
一般に、プロトコルのどんなバージョンと共にも言語が使用したデータ定義のバージョンにかかわらずどんなMIBモジュールでも定義された経営情報は使用できます。 例えば、SNMPv1 SMI(SMIv1)に関して定義されたMIBモジュールは、SNMPv3 Management Frameworkと互換性があって、そこに指定されたプロトコルで伝えることができます。 その上、SNMPv2 SMI(SMIv2)に関して定義されたMIBモジュールは、SNMPv1プロトコル操作と互換性があって、それで伝えることができます。 しかしながら、1つの注目に値する例外があります: 定義されたMIBモジュールで定義できるCounter64データ型式
Case, et. al. Informational [Page 12] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[12ページ]のRFC3410適用性証明
in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol engine. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but cannot be conveyed by an engine which exclusively supports SNMPv1.
SMIv2形式にもかかわらず、SNMPv1プロトコルエンジンで運ぶことができないもので。 それはSNMPv2かSNMPv3エンジンで運ぶことができますが、排他的にSNMPv1をサポートするエンジンで運ぶことができません。
6.3. Protocol Operations and Transport Mappings
6.3. プロトコル操作と輸送マッピング
The specifications for the protocol operations and transport mappings of the SNMPv3 Framework are incorporated by reference to the two SNMPv2 Framework documents which have subsequently been updated.
プロトコル操作とSNMPv3 Frameworkに関する輸送マッピングのための仕様は次にアップデートされた2通のSNMPv2 Frameworkドキュメントの参照で取り入れられます。
The specification for protocol operations is found in STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21].
プロトコル操作のための仕様はSTD62で見つけられます、RFC3416、「簡単なネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2」[21]。
The SNMPv3 Framework is designed to allow various portions of the architecture to evolve independently. For example, it might be possible for a new specification of protocol operations to be defined within the Framework to allow for additional protocol operations.
SNMPv3 Frameworkは、アーキテクチャの様々な部分が独自に発展するのを許容するように設計されています。 例えば、プロトコル操作の新しい仕様が追加議定書操作を考慮するためにFrameworkの中で定義されるのは、可能であるかもしれません。
The specification of transport mappings is found in STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22].
輸送マッピングの仕様はSTD62で見つけられます、RFC3417、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」[22]。
6.4. SNMPv3 Security and Administration
6.4. SNMPv3セキュリティと政権
The document series pertaining to SNMPv3 Security and Administration defined by the SNMPv3 Working Group consists of seven documents at this time:
このとき、SNMPv3作業部会によって定義されたSNMPv3 Securityと政権に関係するドキュメントシリーズは7通のドキュメントから成ります:
RFC 3410, "Introduction and Applicability Statements for the
Internet-Standard Management Framework", which is this document.
RFC3410、このドキュメントである「インターネット標準の管理フレームワークのための序論と適用性声明。」
STD 62, RFC 3411, "An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks" [23], describes
the overall architecture with special emphasis on the architecture
for security and administration.
STD62、RFC3411(「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」[23])はセキュリティと管理のためにアーキテクチャへの特別な強調で総合的なアーキテクチャについて説明します。
STD 62, RFC 3412, "Message Processing and Dispatching for the
Simple Network Management Protocol (SNMP)" [24], describes the
possibility of multiple message processing models and the
dispatcher portion that can be a part of an SNMP protocol engine.
STD62(RFC3412、「メッセージ処理、簡単なネットワーク管理プロトコル(SNMP)のために急いでいる」[24])はSNMPプロトコルエンジンの一部であるかもしれない複数のメッセージ処理モデルと発送者部分の可能性について説明します。
STD 62, RFC 3413, "Simple Network Management Protocol (SNMP)
Applications" [25], describes the five initial types of
applications that can be associated with an SNMPv3 engine and
their elements of procedure.
STD62、RFC3413(「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」[25])はSNMPv3エンジンとそれらの手順の要素に関連づけることができる5つの初期のタイプのアプリケーションについて説明します。
Case, et. al. Informational [Page 13] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[13ページ]のRFC3410適用性証明
STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3
of the Simple Network Management Protocol (SNMPv3)" [26],
describes the threats against which protection is provided, as
well as the mechanisms, protocols, and supporting data used to
provide SNMP message-level security with the user-based security
model.
STD62、RFC3414(「簡単なネットワーク管理プロトコル(SNMPv3)のバージョン3のためのユーザベースの機密保護モデル(USM)」[26])は保護が提供される脅威について説明します、SNMPメッセージレベルセキュリティにユーザベースの機密保護モデルを提供するのに使用されるメカニズム、プロトコル、および添付資料と同様に。
STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the
Simple Network Management Protocol (SNMP)" [27], describes how
view-based access control can be applied within command responder
and notification originator applications.
STD62、RFC3415(「簡単なネットワーク管理プロトコル(SNMP)のための視点ベースのアクセス制御モデル(VCAM)」[27])はコマンド応答者と通知創始者アプリケーションの中でどう視点ベースのアクセスコントロールを適用できるかを説明します。
RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes
coexistence between the SNMPv3 Management Framework, the SNMPv2
Management Framework, and the original SNMPv1 Management
Framework, and is in the process of being updated by a Work in
Progress.
RFC2576(「SNMPv3共存と変遷」[28])はSNMPv3 Management Frameworkと、SNMPv2 Management Frameworkと、オリジナルのSNMPv1 Management Frameworkの間で共存について説明して、Workによってアップデートされることの途中にProgressにあります。
7. Document Summaries
7. ドキュメント概要
The following sections provide brief summaries of each document with slightly more detail than is provided in the overviews above.
以下のセクションがそれぞれのドキュメントの簡潔な概要にわずかに提供する、その他の詳細、上で概要に提供するより。
7.1. Structure of Management Information
7.1. 経営情報の構造
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. These modules are written in the SNMP data definition language, which evolved from an adapted subset of OSI's Abstract Syntax Notation One (ASN.1) [29] language. STD 58, RFCs 2578, 2579, 2580, collectively define the data definition language, specify the base data types for objects, specify a core set of short-hand specifications for data types called textual conventions, and specify a few administrative assignments of object identifier (OID) values.
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 これらのモジュールはSNMPデータ定義言語で書かれています。(それは、OSIの抽象的なSyntax Notation One(ASN.1)[29]言語の適合している部分集合から発展しました)。 STD58、RFCs2578、2579(2580)はデータ定義言語をまとめて定義して、オブジェクトのためのベースデータ型を指定して、原文のコンベンションと呼ばれるデータ型のための1人の巻き癖の速記仕様を指定して、オブジェクト識別子(OID)値のいくつかの管理課題を指定します。
The SMI is divided into three parts: module definitions, object definitions, and notification definitions.
SMIは3つの部品に分割されます: モジュール定義、オブジェクト定義、および通知定義。
(1) Module definitions are used when describing information modules.
An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the
semantics of an information module.
(1) 情報モジュールを説明するとき、モジュール定義は使用されています。 ASN.1マクロ(MODULE-IDENTITY)は、情報モジュールの意味論を簡潔に伝えるのに使用されます。
(2) Object definitions are used when describing managed objects. An
ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax
and semantics of a managed object.
(2) 管理オブジェクトについて説明するとき、オブジェクト定義は使用されています。 ASN.1マクロ(OBJECT-TYPE)は、管理オブジェクトの構文と意味論を簡潔に伝えるのに使用されます。
Case, et. al. Informational [Page 14] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[14ページ]のRFC3410適用性証明
(3) Notification definitions are used when describing unsolicited
transmissions of management information. An ASN.1 macro,
NOTIFICATION-TYPE, is used to convey concisely the syntax and
semantics of a notification.
(3) 経営情報の求められていない送信について説明するとき、通知定義は使用されています。 ASN.1マクロ(NOTIFICATION-TYPE)は、通知の構文と意味論を簡潔に伝えるのに使用されます。
As noted earlier, the term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer to the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
より早く注意されるように、「それには用語のユーザが少なくとも2つの異なった意味がいるつもりであるので、SMIv2"はいくらかあいまいである」用語です。 時々、用語はRFCs2580年に2578--まとめて定義されたSTD58の全体のデータ定義言語を示すのに使用されますが、他の時に、それは、RFC2578で定義されたデータ定義言語の部分だけについて言及するのに使用されます。 このあいまいさは、不幸ですが、めったに実際には重大な問題ではありません。
7.1.1. Base SMI Specification
7.1.1. 基地のSMI仕様
STD 58, RFC 2578 specifies the base data types for the data definition language, which include: Integer32, enumerated integers, Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to several object identifiers. STD 58, RFC 2578 further defines the following constructs of the data definition language:
STD58、RFC2578はデータ定義言語のためのベースデータ型を指定します。(データ型は以下の通りです)。 Integer32、列挙された整数、Unsigned32、Gauge32、Counter32、Counter64、TimeTicks、INTEGER、OCTET STRING、OBJECT IDENTIFIER、IpAddress、Opaque、およびBITS。 また、それはいくつかのオブジェクト識別子に値を割り当てます。 STD58、RFC2578はさらにデータ定義言語の以下の構造物を定義します:
* IMPORTS to allow the specification of items that are used in a MIB
module, but defined in another MIB module.
* MIBモジュールで使用されますが、別のMIBモジュールで定義される項目の仕様を許容するIMPORTS。
* MODULE-IDENTITY to specify for a MIB module a description and
administrative information such as contact and revision history.
* 接触や改訂履歴などのMIBモジュールに記述を指定するMODULE-IDENTITYと管理情報。
* OBJECT-IDENTITY and OID value assignments to specify an OID value.
* OBJECT-IDENTITYとOIDは、OID値を指定するために課題を評価します。
* OBJECT-TYPE to specify the data type, status, and the semantics of
managed objects.
* 管理オブジェクトのデータ型、状態、および意味論を指定するOBJECT-TYPE。
* SEQUENCE type assignment to list the columnar objects in a table.
* SEQUENCEは、テーブルに円柱状のオブジェクトを記載するために課題をタイプします。
* NOTIFICATION-TYPE construct to specify an event notification.
* イベント通知を指定するNOTIFICATION-TYPE構造物。
7.1.2. Textual Conventions
7.1.2. 原文のコンベンション
When designing a MIB module, it is often useful to specify, in a short-hand way, the semantics for a set of objects with similar behavior. This is done by defining a new data type using a base data type specified in the SMI. Each new type has a different name, and specifies a base type with more restrictive semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading a MIB module and potentially by "intelligent" management applications. It is the purpose of STD 58,
MIBモジュールを設計するとき、指定するのはしばしば役に立ちます、速記方法で、同様の振舞いがある1セットのオブジェクトのための意味論。 SMIで指定されたベースデータ型を使用することで新しいデータ型を定義することによって、これをします。 それぞれの新しいタイプは、異なった名前を持って、より制限している意味論でベースタイプを指定します。 これらの新たに定義されたタイプは、「知的な」管理アプリケーションで潜在的に原文のコンベンションと呼ばれて、MIBモジュールを読んでいる人間の都合のために使用されます。 それはSTD58の目的です。
Case, et. al. Informational [Page 15] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[15ページ]のRFC3410適用性証明
RFC 2579, Textual Conventions for SMIv2 [18], to define the construct, TEXTUAL-CONVENTION, of the data definition language used to define such new types and to specify an initial set of textual conventions available to all MIB modules.
RFC2579、SMIv2[18]のためのTextual Conventions、構造物、データ定義言語のTEXTUAL-CONVENTIONを定義するのはそのような新しいタイプを定義して、以前はよくすべてのMIBモジュールに利用可能な原文のコンベンションの始発を指定していました。
7.1.3. Conformance Statements
7.1.3. 順応声明
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 STD 58, RFC 2580, Conformance Statements for SMIv2 [19], to define the constructs of the data definition language used for these purposes. There are two kinds of constructs:
実装の許容できる下界を定義するのは達成された実装の実際のレベルと共に役に立つかもしれません。 それは、これらの目的に使用されるデータ定義言語の構造物を定義するためにはSTD58、RFC2580、SMIv2[19]のためのConformance Statementsの目的です。 2種類の構造物があります:
(1) Compliance statements are used when describing requirements for
agents with respect to object and event notification definitions.
The MODULE-COMPLIANCE construct is used to convey concisely such
requirements.
(1) オブジェクトとイベント通知定義に関してエージェントのための要件について説明するとき、承諾声明は使用されています。 MODULE-COMPLIANCE構造物は、そのような要件を簡潔に伝えるのに使用されます。
(2) Capability statements are used when describing capabilities of
agents with respect to object and event notification definitions.
The AGENT-CAPABILITIES construct is used to convey concisely such
capabilities.
(2) オブジェクトとイベント通知定義に関してエージェントの能力について説明するとき、能力声明は使用されています。 エージェント-CAPABILITIES構造物は、そのような能力を簡潔に伝えるのに使用されます。
Finally, collections of related objects and collections of related event notifications are grouped together to form a unit of conformance. The OBJECT-GROUP construct is used to convey concisely the objects in and the semantics of an object group. The NOTIFICATION-GROUP construct is used to convey concisely the event notifications in and the semantics of an event notification group.
最終的に、関連するオブジェクトの収集と関連するイベント通知の収集は、順応のユニットを形成するために一緒に分類されます。 OBJECT-GROUP構造物は、オブジェクトを簡潔に運ぶのにおいて使用されていてオブジェクトグループの意味論です。 NOTIFICATION-GROUP構造物は、イベント通知を簡潔に伝えるのにおいて使用されていてイベント通知グループの意味論です。
7.2. Protocol Operations
7.2. プロトコル操作
The management protocol provides for the exchange of messages which convey management information between the agents and the management stations. The form of these messages is a message "wrapper" which encapsulates a Protocol Data Unit (PDU).
管理プロトコルはエージェントと管理局の間に経営情報を伝えるメッセージの交換に備えます。 これらのメッセージのフォームはプロトコルData Unit(PDU)をカプセル化する「ラッパー」というメッセージです。
It is the purpose of STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21], to define the operations of the protocol with respect to the sending and receiving of the PDUs.
それは、PDUsの送受信に関してプロトコルの操作を定義するためにはSTD62、RFC3416、「簡単なネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2」[21]の目的です。
7.3. Transport Mappings
7.3. 輸送マッピング
SNMP messages may be used over a variety of protocol suites. It is the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22], to define how SNMP messages
SNMPメッセージはさまざまなプロトコル群にわたって使用されるかもしれません。 それは、SNMPがどう通信するかを定義するためにはSTD62、RFC3417、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」[22]の目的です。
Case, et. al. Informational [Page 16] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[16ページ]のRFC3410適用性証明
map onto an initial set of transport domains. Other mappings may be defined in the future.
1人の始発の輸送にドメインを写像してください。 他のマッピングは将来、定義されるかもしれません。
Although several mappings are defined, the mapping onto UDP is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for proxy service to the UDP mapping.
いくつかのマッピングが定義されますが、UDPへのマッピングは都合のよいマッピングです。 また、そういうものとして、最も大きいレベルの相互運用性に備えるために、他のマッピングを配布するのを選ぶシステムはUDPマッピングへの代理業務に備えるはずです。
7.4. Protocol Instrumentation
7.4. プロトコル計装
It is the purpose of STD 62, RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)" [30], to define managed objects which describe the behavior of portions of an SNMP entity.
それは、SNMP実体の部分の振舞いについて説明する管理オブジェクトを定義するためにはSTD62、RFC3418、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」[30]の目的です。
7.5. Architecture / Security and Administration
7.5. アーキテクチャ/セキュリティと政権
It is the purpose of STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], to define an architecture for specifying Management Frameworks. While addressing general architectural issues, it focuses on aspects related to security and administration. It defines a number of terms used throughout the SNMPv3 Management Framework and, in so doing, clarifies and extends the naming of:
それは、Management Frameworksを指定するためにアーキテクチャを定義するためにはSTD62、RFC3411、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」[23]の目的です。 一般的な構造的な問題を扱っている間、それはセキュリティと管理に関連する局面に焦点を合わせます。 そうする際に、それは、以下の命名をSNMPv3 Management Framework中で使用される項数を定義して、はっきりさせて、広げています。
* engines and applications,
* エンジンとアプリケーション
* entities (service providers such as the engines in agents and
managers),
* 実体(エージェントとマネージャのエンジンなどのサービスプロバイダー)
* identities (service users), and
* そしてアイデンティティ(サービス利用者)。
* management information, including support for multiple logical
contexts.
* 複数の論理的な関係のサポートを含む経営情報。
The document contains a small MIB module which is implemented by all authoritative SNMPv3 protocol engines.
ドキュメントはすべての正式のSNMPv3プロトコルエンジンによって実装される小さいMIBモジュールを含んでいます。
7.6. Message Processing and Dispatch (MPD)
7.6. メッセージ処理と発信(MPD)
STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
STD62(RFC3412、「メッセージ処理、簡単なネットワーク管理プロトコル(SNMP)のために急いでいる」[24])はSNMPメッセージのためにSNMPアーキテクチャの中でMessage ProcessingとDispatchingについて説明します。 それはSNMPメッセージの潜在的に複数のバージョンを適切なSNMP Message Processing Modelsに派遣して、SNMPアプリケーションにPDUsを派遣するための手順を定義します。 また、このドキュメントは1Message Processing Modelについて説明します--SNMPv3 Message Processing Model。
Case, et. al. Informational [Page 17] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[17ページ]のRFC3410適用性証明
An SNMPv3 protocol engine MUST support at least one Message Processing Model. An SNMPv3 protocol engine MAY support more than one, for example in a multi-lingual system which provides simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. For example, such a tri-lingual system which provides simultaneous support for SNMPv1, SNMPv2c, and SNMPv3 supports three message processing models.
SNMPv3プロトコルエンジンは少なくとも1Message Processing Modelをサポートしなければなりません。 SNMPv3プロトコルエンジンは1つ以上をサポートするかもしれません、例えば、SNMPv3とSNMPv1、そして/または、SNMPv2cの同時のサポートを提供する多言語システムで。 例えば、SNMPv1、SNMPv2c、およびSNMPv3の同時のサポートを提供するそのような3舌のシステムは、3メッセージが処理モデルであるとサポートします。
7.7. SNMP Applications
7.7. SNMPアプリケーション
It is the purpose of STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25] to describe the five types of applications which can be associated with an SNMP engine. They are: Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.
それはSTD62の目的です、RFC3413、SNMPエンジンに関連づけることができる5つのタイプのアプリケーションについて説明する「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」[25]。 それらは以下の通りです。 コマンドジェネレータ、コマンド応答者、通知創始者、通知受信機、およびプロキシ混載業者。
The document also defines MIB modules for specifying targets of management operations (including notifications), for notification filtering, and for proxy forwarding.
また、ドキュメントは管理操作の目標を指定するためのMIBモジュールを定義します(通知を含んでいて)、推進をフィルターにかけてプロキシ推進のための通知のために。
7.8. User-based Security Model (USM)
7.8. ユーザベースの機密保護モデル(USM)
STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" [26] describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security.
STD62、RFC3414、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」[26]はSNMPv3のためにUserベースのSecurity Modelについて説明します。 それは、メッセージレベルセキュリティをSNMPに供給するためにProcedureのElementsを定義します。
The document describes the two primary and two secondary threats which are defended against by the User-based Security Model. They are: modification of information, masquerade, message stream modification, and disclosure.
ドキュメントはUserベースのSecurity Modelによって防御される2予備選挙と2つのセカンダリ脅威について説明します。 それらは以下の通りです。 情報、仮面舞踏会、メッセージストリーム変更、および公開の変更。
The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data integrity:
USMはダイジェスト計算がデータ保全を提供するアルゴリズム[33]を論じ尽くしながら、合わせられるとしてMD5[31]とSecure Hash Algorithm[32]を利用します:
* to directly protect against data modification attacks,
* 直接データ変更から守るのは攻撃されます。
* to indirectly provide data origin authentication, and
* そして間接的にデータ発生源認証を提供するために。
* to defend against masquerade attacks.
* 仮面舞踏会に対して防御するのは攻撃されます。
The USM uses loosely synchronized monotonically increasing time indicators to defend against certain message stream modification attacks. Automatic clock synchronization mechanisms based on the protocol are specified without dependence on third-party time sources and concomitant security considerations.
USMは、あるメッセージストリーム変更攻撃に対して防御するのに緩く連動している単調に増加する期間表示を使用します。 プロトコルに基づく自動時計同期メカニズムは第三者時間ソースと並立しているセキュリティ問題への依存なしで指定されます。
Case, et. al. Informational [Page 18] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[18ページ]のRFC3410適用性証明
The USM uses the Data Encryption Standard (DES) [34] in the cipher block chaining mode (CBC) if disclosure protection is desired. Support for DES in the USM is optional, primarily because export and usage restrictions in many countries make it difficult to export and use products which include cryptographic technology.
公開保護が望まれているなら、暗号ブロック連鎖モード(CBC)でUSMはデータ暗号化規格(DES)[34]を使用します。 USMのDESのサポートは任意です、主として暗号の技術を含んでいる製品をエクスポートして、使用するのが多くの国での輸出と使用制限で難しくなるので。
The document also includes a MIB suitable for remotely monitoring and managing the configuration parameters for the USM, including key distribution and key management.
また、ドキュメントはUSMのための設定パラメータを離れてモニターして、管理するのに適当なMIBを含んでいます、主要な分配とかぎ管理を含んでいて。
An entity may provide simultaneous support for multiple security models as well as multiple authentication and privacy protocols. All of the protocols used by the USM are based on pre-placed keys, i.e., private key mechanisms. The SNMPv3 architecture permits the use of symmetric and asymmetric mechanisms and protocols (asymmetric mechanisms are commonly called public key cryptography) but, as of this writing, there are no SNMPv3 security models on the IETF standards track that use public key cryptography.
実体は複数の認証とプライバシープロトコルと同様に複数の機密保護モデルの同時のサポートを提供するかもしれません。 USMによって使用されたプロトコルのすべてがあらかじめ置かれたキーに基づいています、すなわち、秘密鍵メカニズム。SNMPv3アーキテクチャは左右対称の、そして、非対称のメカニズムとプロトコルの使用を可能にしますが(非対称のメカニズムは一般的に公開鍵暗号と呼ばれます)、この書くこと現在、IETF標準化過程の上の公開鍵暗号を使用するSNMPv3機密保護モデルが全くいません。
Work is underway to specify how AES is to be used within the User- based Security Model (USM). This will be a separate document.
仕事は、AESがUserのベースのSecurity Model(USM)の中で使用されることになっている方法を指定するために進行中です。 これは別々のドキュメントになるでしょう。
7.9. View-based Access Control (VACM)
7.9. 視点ベースのアクセスコントロール(VACM)
The purpose of STD 62, RFC 3415, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to describe the View-based Access Control Model for use in the SNMP architecture. The VACM can simultaneously be associated in a single engine implementation with multiple Message Processing Models and multiple Security Models.
STD62の目的、RFC3415(「簡単なネットワーク管理プロトコル(SNMP)のための視点ベースのアクセス制御モデル(VACM)」[27])はSNMPアーキテクチャにおける使用のためにViewベースのAccess Control Modelについて説明することになっています。 同時に、VACMはただ一つのエンジン実装で複数のMessage Processing Modelsに関連し複数のSecurity Modelsであるかもしれません。
It is architecturally possible to have multiple, different, Access Control Models active and present simultaneously in a single engine implementation, but this is expected to be *_very_* rare in practice and *_far_* less common than simultaneous support for multiple Message Processing Models and/or multiple Security Models.
It is architecturally possible to have multiple, different, Access Control Models active and present simultaneously in a single engine implementation, but this is expected to be *_very_* rare in practice and *_far_* less common than simultaneous support for multiple Message Processing Models and/or multiple Security Models.
7.10. SNMPv3 Coexistence and Transition
7.10. SNMPv3共存と変遷
The purpose of RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework" [28], is to describe coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework. In particular, this document describes four aspects of coexistence:
RFC2576の目的(「インターネット標準のネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」[28])はSNMPv3 Management Frameworkと、SNMPv2 Management Frameworkと、オリジナルのSNMPv1 Management Frameworkの間の共存について説明することです。 特に、このドキュメントは共存の4つの局面について説明します:
* Conversion of MIB documents from SMIv1 to SMIv2 format
* MIBドキュメントのSMIv1からSMIv2形式までの変換
Case, et. al. Informational [Page 19] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[19ページ]のRFC3410適用性証明
* Mapping of notification parameters
* 通知パラメタに関するマッピング
* Approaches to coexistence between entities which support the
various versions of SNMP in a multi-lingual network, in particular
the processing of protocol operations in multi-lingual
implementations, as well as behavior of proxy implementations
* 多言語ネットワークにおける、SNMPの様々なバージョン、特に多言語実装における、プロトコル操作の処理、およびプロキシ実装の振舞いをサポートする実体の間の共存へのアプローチ
* The SNMPv1 Message Processing Model and Community-Based Security
Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c
into the View-Based Access Control Model (VACM) [27]
* SNMPv1 Message Processing ModelとベースのCommunity Security Model。(そのSecurity ModelはベースのView Access Control Model(VACM)にSNMPv1とSNMPv2cを適合させるのにメカニズムを提供します)。[27]
8. Standardization Status
8. 標準化状態
Readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to determine the standardization status of any document.
読者は、どんなドキュメントの標準化状態も決定するために「インターネット公式プロトコル標準」リスト[20]の最新版に相談するべきです。
However, the SNMPv3 Working Group explicitly requested that text be included in this document to amplify on the status of SMIv1, SNMPv1, and SNMPv2c.
しかしながら、SNMPv3作業部会は、テキストがSMIv1、SNMPv1、およびSNMPv2cの状態で増幅するために本書では含まれているよう明らかに要求しました。
8.1. SMIv1 Status
8.1. SMIv1状態
SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to full Standard status in 1990 and has remained a Standard even after SMIv2 reached full Standard (see RFC 2026 [35] for more information about the Internet Standards Process). In many cases, a Standard is declared "Historic" when its replacement reaches full Standard. For example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached full Standard. Similarly, when SMIv2 reached full Standard, it might have been reasonable at that time to retire SMIv1 and declare it to be "Historic" but as the result of a conscious decision, STD 16, RFCs 1155 and 1212 continue to have the standardization status of full "Standard" but are not recommended. These documents were not declared "Historic" and remain on the standards track because they provide normative references for other documents on the standards track and cannot be declared "Historic" without rendering the documents which rely on them to also become "Historic". Consequently, STD 16 retains its standardization status but is not recommended because it has been superseded by the newer SMIv2 specifications which are identified somewhat later in this document.
SMIv2が完全なStandard(インターネットStandards Processに関する詳しい情報のためのRFC2026[35]を見る)に達した後にさえ、STD16、RFCs1155、および1212年に説明されるSMIv1は1990年に完全なStandard状態に促進されて、Standardのままで残っていました。 交換が完全なStandardに達するとき、多くの場合、Standardは「歴史的である」と申告されます。 MIB-2[6]が完全なStandardに達したとき、例えば、MIB-1[8]は「歴史的である」と申告されました。 SMIv2がその時完全なStandardに達したとき、同様に、SMIv1を引退させて、それが「歴史的である」と申告するのが妥当であったかもしれませんが、意識的な決断の結果として、STD16、RFCs1155、および1212は、完全な「規格」の標準化状態を持ち続けていますが、推薦されません。 また、それらを当てにするドキュメントが「歴史的に」なるのをレンダリングしない、これらのドキュメントを、「歴史的である」と申告しないで、標準化過程の上の他のドキュメントに関する引用規格を提供するので標準化過程の上に残っていて、「歴史的である」と申告できません。 その結果、後で本書ではいくらか特定されるより新しいSMIv2仕様でそれが取って代わられたので、STD16は標準化状態を保有しますが、推薦されません。
On a pragmatic level, since about 1993 it has been wise for users of the data definition language to use SMIv2 for all new work because the realities of the marketplace have occasionally required the support of data definitions in both the SMIv1 and SMIv2 formats. While there are tools widely available at low cost or no cost to translate SMIv2 definitions to SMIv1 definitions, it is impractical
実践的なレベルでは、市場の現実が時折SMIv1とSMIv2形式の両方でのデータ定義のサポートを必要としたので、1993年頃以来データ定義言語のユーザがすべての新しい仕事にSMIv2を使用するのは、賢明です。 SMIv2定義をSMIv1定義に翻訳するために、低価格にもかかわらず、費用なしで広く利用可能なツールがありますが、それは非実用的です。
Case, et. al. Informational [Page 20] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[20ページ]のRFC3410適用性証明
to build automatic tools that automatically translate SMIv1 definitions to SMIv2 definitions. Consequently, if one works in primarily SMIv2, the cost of providing data definitions in both SMIv1 and SMIv2 formats is trivial. In contrast, if one works primarily in SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is significantly more expensive. The market requirements today for providing data definitions in SMIv1 format are greatly diminished when compared to those of 1993, and SMIv2 continues to be the strongly preferred format even though SMIv1 has not been declared "Historic". Indeed, the IETF currently requires that new MIB modules be written using SMIv2.
そんなに自動的に自動ツールを築き上げるには、SMIv1定義をSMIv2定義に翻訳してください。 その結果、1つが主としてSMIv2で働いているなら、SMIv1とSMIv2形式の両方へのデータ定義を提供する費用は些細です。 対照的に、1つが主としてSMIv1形式で働いているなら、SMIv1とSMIv2の両方へのデータ定義を提供するのはかなり高価です。 1993年のものと比べると、SMIv1形式へのデータ定義を提供するための今日の市場の必要性は大いに減少します、そして、SMIv1は「歴史的である」と申告されていませんが、SMIv2はずっと強く好まれた形式です。 本当に、IETFは現在、新しいMIBモジュールがSMIv2を使用することで書かれているのを必要とします。
8.2. SNMPv1 and SNMPv2 Standardization Status
8.2. SNMPv1とSNMPv2標準化状態
Protocol operations via SNMPv1 and SNMPv2c message wrappers support only trivial authentication based on plain-text community strings and, as a result, are fundamentally insecure. When the SNMPv3 specifications for security and administration, which include strong security, reached full Standard status, the full Standard SNMPv1, formerly STD 15 [5], and the experimental SNMPv2c specifications described in RFC 1901 [16] were declared Historic due to their weaknesses with respect to security and to send a clear message that the third version of the Internet Standard Management Framework is the framework of choice. The Party-based SNMPv2 (SNMPv2p), SNMPv2u, and SNMPv2* were either declared Historic circa 1995 or were never on the standards track.
SNMPv1を通したプロトコル操作とSNMPv2cメッセージラッパーは、プレーンテキスト共同体ストリングに基づく些細な認証だけをサポートして、その結果基本的に不安定です。 セキュリティと管理のためのSNMPv3仕様が完全なStandard状態に達したとき、仕様がRFC1901[16]で説明した完全なStandard SNMPv1、以前STD15[5]、および実験的なSNMPv2cはセキュリティに関する彼らの弱点によるHistoricであると申告されました、そして、インターネットStandard Management Frameworkの第3バージョンは、明確なメッセージにそれを送るためには、選択のフレームワークです。管理は強いセキュリティを含んでいます。 パーティベースのSNMPv2(SNMPv2p)、SNMPv2u、およびSNMPv2*は1995年頃のHistoricであると宣言されたか、または標準化過程の上に決してありませんでした。
On a pragmatic level, it is expected that a number of vendors will continue to produce and users will continue to deploy and use multi- lingual implementations that support SNMPv1 and/or SNMPv2c as well as SNMPv3. It should be noted that the IETF standards process does not control actions of vendors or users who may choose to promote or deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of known short-comings. However, it is not expected that vendors will produce nor that users will deploy multi-lingual implementations that support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*.
実践的なレベルでは、多くのベンダーが、生産し続けて、ユーザがSNMPv3と同様にSNMPv1、そして/または、SNMPv2cをサポートするマルチ舌の実装を配布して、使用し続けると予想されます。 IETF標準化過程が歴史的なプロトコルを促進するか、または配布するのを選ぶかもしれないベンダーかユーザの動作を制御しないことに注意されるべきです、SNMPv1やSNMPv2cのように、知られている短所にもかかわらず。 しかしながら、ベンダーが生産されて、ユーザが、多言語実装がそのサポートのパーティベースのSNMPv2p(SNMPv2p)、SNMPv2u、またはSNMPv2*であると配布しないと予想されます。
Indeed, as described above, one of the SNMPv3 specifications for security and administration, RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Management Framework [28], addresses these issues.
本当に、上で説明されるように、セキュリティと管理のためのSNMPv3仕様の1つ(RFC2576、インターネット標準のManagement Framework[28]のバージョン1と、バージョン2と、バージョン3の間のCoexistence)はこれらの問題を扱います。
Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to insure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization's security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly
不安定なプロトコルで多言語システムを配布するユーザがその構成限界がSNMPv1とSNMPv2cを通して適切にアクセスするのを保障できるくらいの適切な注意を運動させるのは、重要です、組織の安全保障政策で保つ際に、もちろん、ちょうど慎重に認証がなくてまたプライバシーがないセキュリティー・レベルがあるおよそそうであるSNMPv3を通して承諾されたアクセスを制限するべきであるように
Case, et. al. Informational [Page 21] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[21ページ]のRFC3410適用性証明
equivalent from a security point of view. For example, it is probably unwise to allow SNMPv1 or SNMPv2c a greater level of access than is provided to unauthenticated SNMPv3 users, e.g., it does not make sense to guard the front door with armed guards, trained attack dogs, moats and drawbridges while providing unfettered access through an open back door.
セキュリティ観点から、同等です。 例えば、屋根のない荷台部分ドアを通して束縛のないアクセスを提供している間、武装したガード、訓練された攻撃犬、堀、および跳ね橋がある正面玄関を警備するためにunauthenticated SNMPv3ユーザに、理解できないかどうかということであるより大きいアクセスのレベルをSNMPv1かSNMPv2cに許容するのはたぶん賢明ではありません。
The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited capabilities for administering the SNMPv1 and SNMPv2c protocols. For example, there are no objects defined to view and configure communities or destinations for notifications (traps and informs). The result has been vendor defined mechanisms for administration that range from proprietary format configuration files that cannot be viewed or configured via SNMP to enterprise specific object definitions. The SNMPv3 framework provides a rich standards-based approach to administration which, by design, can be used for the SNMPv1 and SNMPv2c protocols. Thus, to foster interoperability of administration of SNMPv1 and SNMPv2c protocols in multi-lingual systems, the mechanisms and objects specified in [25], [27], and [28] should be used to supplement or replace the equivalent proprietary mechanisms.
SNMPv1フレームワーク、SNMPv2フレームワーク、およびSNMPv2cは、SNMPv1とSNMPv2cプロトコルを管理するために能力を制限しました。 例えば、通知(捕らえて、知らせる)のために共同体か目的地を見て、構成するために定義されたオブジェクトが全くありません。 結果は管理のためのSNMPを通して見ることができないか、構成できない独占形式構成ファイルから特定の企業オブジェクト定義まで及ぶベンダーの定義されたメカニズムです。 SNMPv3フレームワークはSNMPv1とSNMPv2cプロトコルに故意に使用できる管理への豊かな規格ベースのアプローチを提供します。 したがって、SNMPv1の管理と[25]、[27]、および[28]で指定された多言語システム、メカニズム、およびオブジェクトのSNMPv2cプロトコルの相互運用性を伸ばすのは同等な独占メカニズムを補うか、または置き換えるのにおいて使用されているべきです。
8.3. Working Group Recommendation
8.3. ワーキンググループ推薦
Based on the explanations above, the SNMPv3 Working Group recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as Historical documents.
説明に基づいて、上では、SNMPv3作業部会が、Historicalが記録するようにRFCs1157、1441、1901、1909、および1910が分類し直されることを勧めます。
9. Security Considerations
9. セキュリティ問題
As this document is primarily a roadmap document, it introduces no new security considerations. The reader is referred to the relevant sections of each of the referenced documents for information about security considerations.
このドキュメントが主として道路地図ドキュメントであるので、それはどんな新しいセキュリティ問題も紹介しません。 読者はセキュリティ問題の情報のためのそれぞれの参照をつけられたドキュメントの関連セクションを参照されます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[2] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, April 1988.
[2] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、1988年4月。
Case, et. al. Informational [Page 22] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[22ページ]のRFC3410適用性証明
[3] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[3]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[5] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびデーヴィン(J.、「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[6] McCloghrie, K. and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, March 1991.
[6]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[7] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[7] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[8] McCloghrie, K. and M. Rose, "Management Information Base for
Network Management of TCP/IP-based Internets", RFC 1156, March
1990.
[8]McCloghrieとK.とM.ローズ、「TCP/IPベースのインターネットのネットワークマネージメントのための管理情報ベース」、RFC1156、1990年3月。
[9] 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.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
Conventions for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1903, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1904, January 1996.
[11]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための順応声明は(SNMPv2)について議定書の中で述べます」、RFC1904、1996年1月。
[12] 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.
[12] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[13] 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.
[13]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[14] 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.
[14]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。
[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
Standard Network Management Framework", RFC 2576, January 1996.
[15]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネットの標準のネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」、RFC2576(1996年1月)。
Case, et. al. Informational [Page 23] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[23ページ]のRFC3410適用性証明
[16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[16]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[17] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[17]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[18]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[19]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[20] "Official Internet Protocol Standards", http://www.rfc-
editor.org/rfcxx00.html also STD0001.
[20] 「公式のインターネットプロトコル標準」、 http://www.rfc- editor.org/rfcxx00.html、もSTD0001。
[21] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Version 2 of the Protocol Operations for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3416, December
2002.
[21]Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[22]Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための輸送マッピングは(SNMP)について議定書の中で述べます」、STD62、RFC3417、2002年12月。
[23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[23] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、2002年12月。
[24] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[24]ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
[25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management
Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[25] レビとD.とマイヤーとP.とB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3413、2002年12月。
[26] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM)
for Version 3 of the Simple Network Management Protocol
(SNMPv3)", STD 62, RFC 3414, December 2002.
[26] ブルーメンソル、U.、およびB.Wijnen、「簡単なネットワークマネージメントのバージョン3のためのユーザベースのセキュリティモデル(USM)は(SNMPv3)について議定書の中で述べます」、STD62、RFC3414、2002年12月。
[27] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3415, December 2002.
[27] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
Case, et. al. Informational [Page 24] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[24ページ]のRFC3410適用性証明
[28] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence
between Version 1, Version 2, and Version 3 of the Internet-
Standard Network Management Framework", RFC 2576, March 2000.
[28] フライとR.とレビとD.、RouthierとS.とB.Wijnen、「インターネットの標準のネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」RFC2576(2000年3月)。
[29] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[29] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
[30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base (MIB) for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3418, December
2002.
[30]Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April
1992.
[31] 最もRivest、R.、「メッセージダイジェストアルゴリズムMD5"、RFC1321、1992年4月。」
[32] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[32] ハッシュアルゴリズムを保証してください。 NIST FIPS180-1、(1995年4月) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (追伸)
[33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[33]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[34] Data Encryption Standard, National Institute of Standards and
Technology. Federal Information Processing Standard (FIPS)
Publication 46-1. Supersedes FIPS Publication 46, (January,
1977; reaffirmed January, 1988).
[34] データ暗号化規格、米国商務省標準技術局。 連邦情報処理基準(FIPS)公表46-1。 FIPS Publication46、(再び断言された1月、1977年1月;1988)に取って代わります。
[35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October, 1996.
[35] ブラドナー、S.、「インターネット規格は処理されます--改正3インチ、BCP9、RFC2026、1996年10月。」
Case, et. al. Informational [Page 25] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[25ページ]のRFC3410適用性証明
11. Editors' Addresses
11. エディタのアドレス
Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA
ジェフリーケースSNMP研究Inc.3001Kimberlin高さのRoadテネシー37920-9716ノクスビル(米国)
Phone: +1 865 573 1434 EMail: case@snmp.com
以下に電話をしてください。 +1 1434年の865 573メール: case@snmp.com
Russ Mundy Network Associates Laboratories 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA
研究所15204のオメガが運転するラスマンディネットワーク関連、Suite300MD20850-4601ロックビル(米国)
Phone: +1 301 947 7107 EMail: mundy@tislabs.com
以下に電話をしてください。 +1 7107年の301 947メール: mundy@tislabs.com
David Partain Ericsson P.O. Box 1248 SE-581 12 Linkoping Sweden
デヴィッドパーテインエリクソンP.O. Box1248SE-581 12リンチェピングスウェーデン
Phone: +46 13 28 41 44 EMail: David.Partain@ericsson.com
以下に電話をしてください。 +46 13 28 41 44はメールされます: David.Partain@ericsson.com
Bob Stewart Retired
ボブ・スチュワートは退職しました。
Case, et. al. Informational [Page 26] RFC 3410 Applicability Statements for SNMP December 2002
etケース、アル。 SNMP2002年12月のための情報[26ページ]のRFC3410適用性証明
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Case, et. al. Informational [Page 27]
etケース、アル。 情報[27ページ]
一覧
スポンサーリンク
