RFC3535 日本語訳
3535 Overview of the 2002 IAB Network Management Workshop. J.Schoenwaelder. May 2003. (Format: TXT=42566 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Schoenwaelder Request for Comments: 3535 International University Bremen Category: Informational May 2003
Schoenwaelderがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3535年の国際大学ブレーメンカテゴリ: 情報の2003年5月
Overview of the 2002 IAB Network Management Workshop
2002IABネットワークマネージメントワークショップの概要
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
このドキュメントはNetwork Managementでインターネット・アーキテクチャ委員会(IAB)によって開かれたワークショップの概要を提供します。 そのワークショップは6月4日から2002年6月6日を通したレストン(ヴァージニア)(米国)でCNRIによって主催されました。 ワークショップの目標は、ネットワーク・オペレータとプロトコル開発者の間で始められた重要な対話を続けて、今後の活動のときにネットワークマネージメントに関してIETFs焦点を誘導することでした。 このレポートは、インターネット・エンジニアリング・タスク・フォース(IETF)共同体に議論をまとめて、結論と推薦を記載します。
Schoenwaelder Informational [Page 1] RFC 3535 IAB Network Management Workshop May 2003
[1ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Network Management Technologies . . . . . . . . . . . . . . . 3
2.1 SNMP / SMI / MIBs . . . . . . . . . . . . . . . . . . . 4
2.2 COPS-PR / SPPI / PIBs . . . . . . . . . . . . . . . . . 5
2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . . 6
2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . . 7
2.5 HTTP / HTML . . . . . . . . . . . . . . . . . . . . . . 8
2.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Operator Requirements . . . . . . . . . . . . . . . . . . . . 10
4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12
5. Consolidated Observations . . . . . . . . . . . . . . . . . . 14
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix - Participants . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 20
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ネットワークマネージメント技術. . . . . . . . . . . . . . . 3 2.1MIBs. . . . . . . . . . . . . . . . . . . 4 2.2巡査SNMP/SMI/PR/SPPI/PIBs.52.3CIM/ MOF / UML / PCIM. . . . . . . . . . . . . . . . . 6 2.4CLI/telnet/セキュアシェル (SSH). . . . . . . . . . . . . . . . . . . 7 2.5HTTP/HTML. . . . . . . . . . . . . . . . . . . . . . 8 2.6XML. . . . . . . . . . . . . . . . . . . . . . . . . . 9 3。 オペレータ要件. . . . . . . . . . . . . . . . . . . . 10 4。 SNMPフレームワーク議論. . . . . . . . . . . . . . . . . . 12 5。 観測. . . . . . . . . . . . . . . . . . 14 6を統合しました。 推薦. . . . . . . . . . . . . . . . . . . . . . . 16 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 17引用規格. . . . . . . . . . . . . . . . . . . . . . 18有益な参照. . . . . . . . . . . . . . . . . . . . . 18付録--関係者. . . . . . . . . . . . . . . . . . . . . 19作者のアドレスの.19の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 20
1. Introduction
1. 序論
The IETF has started several activities in the operations and management area to develop technologies and standards that aim to help network operators manage their networks. The main network management technologies currently being developed within the IETF are:
IETFは、ネットワーク・オペレータが彼らのネットワークを経営するのを助けることを目指す技術と規格を開発するために操作と管理領域でのいくつかの活動を始めました。 現在IETFの中で開発される主なネットワークマネージメント技術は以下の通りです。
o The Simple Network Management Protocol (SNMP) [RFC3410] was
created in the late 1980s. The initial version (SNMPv1) is widely
deployed, while the latest version (SNMPv3), which addresses
security requirements, is just beginning to gain significant
deployment.
o Simple Network Managementプロトコル(SNMP)[RFC3410]は1980年代後半に作成されました。 初期のバージョン(SNMPv1)は広く配布されます、最新版(SNMPv3)(セキュリティが要件であると扱う)がただ重要な展開を獲得し始めている間。
o The Common Information Model (CIM) [CIM], developed by the
Distributed Management Task Force (DMTF), has been extended in
cooperation with the DMTF to describe high-level policies as rule
sets (PCIM) [RFC3060]. Mappings of the CIM policy extensions to
LDAP schemas have been defined and work continues to define
specific schema extension for QoS and security policies.
o 規則セット(PCIM)[RFC3060]としてハイレベルの方針を記述するためにDMTFと提携してDistributed Management Task Force(DMTF)によって開発されたCommon情報Model(CIM)[CIM]を広げてあります。 LDAP schemasへのCIM方針拡大に関するマッピングは定義されました、そして、仕事はQoSと安全保障政策のための特定の図式拡大を定義し続けています。
o The Common Open Policy Service (COPS) [RFC2748] protocol has been
extended to provision configuration information on devices (COPS-
PR) [RFC3084]. Work is underway to define data definitions for
specific services such as Differentiated Services (DiffServ).
o CommonオープンPolicy Service(COPS)[RFC2748]プロトコルをデバイス(COPS PR)[RFC3084]に関する支給設定情報に広げてあります。 仕事は、Differentiated Services(DiffServ)などの特定のサービスのためのデータ定義を定義するために進行中です。
Schoenwaelder Informational [Page 2] RFC 3535 IAB Network Management Workshop May 2003
[2ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
During 2001, several meetings have been organized at various events (NANOG-22 May 2001, RIPE-40 October 2001, LISA-XV December 2001, IETF-52 December 2001) to start a direct dialog between network operators and protocol developers. During these meetings, several operators have expressed their opinion that the developments in the IETF do not really address their requirements, especially for configuration management. This naturally leads to the question of whether the IETF should refocus resources, and which strategic future activities in the operations and management area should be started.
2001の間、いくつかのミーティングがネットワーク・オペレータとプロトコル開発者の間のダイレクト対話を始める様々なイベント(RIPE-40 2001年10月、リサ-XV2001年12月、IETF-52 2001年12月のNANOG-2001年5月22日)で計画されています。 これらのミーティングの間、数人のオペレータがIETFでの開発が本当にそれらの要件を扱わないという彼らの意見を述べています、特に構成管理のために。 これは自然にIETFがリソースの焦点を再び合わせるはずであるかどうかと、操作と管理領域での活動がどの戦略の未来に始められるべきであるかに関する質問に通じます。
The Internet Architecture Board (IAB), on June 4 thru June 6, 2002, held an invitational workshop on network management. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management.
6月4日から2002年6月6日を通して、インターネット・アーキテクチャ委員会(IAB)はネットワークマネージメントに関する招待者に限る催しワークショップを開きました。 ワークショップの目標は、ネットワーク・オペレータとプロトコル開発者の間で始められた重要な対話を続けて、今後の活動のときにネットワークマネージメントに関してIETFs焦点を誘導することでした。
The workshop started with two breakout session to (a) identify a list of technologies relevant for network management together with their strengths and weaknesses, and to (b) identify the most important operator needs. The results of these discussions are documented in Section 2 and Section 3. During the following discussions, many more specific characteristics of the current SNMP framework were identified. These discussions are documented in Section 4. Section 5 defines a combined feature list that was developed during the discussions following the breakout sessions. Section 6 gives concrete recommendations to the IETF.
2脱走セッションから(a)に始められたワークショップは、ネットワークマネージメントにおいて、彼らの長所と短所と共に関連している技術のリストを特定して、最も重要なオペレータの必要性を(b)に特定します。 これらの議論の結果はセクション2とセクション3に記録されます。 以下の議論の間、現在のSNMPフレームワークのずっと多くの特定の特性が特定されました。 これらの議論はセクション4に記録されます。 セクション5は脱走セッションに続いて、議論の間に開発された結合した特徴リストを定義します。 セクション6は具体的勧告をIETFに与えます。
The following text makes no explicit distinction between different versions of SNMP. For the majority of the SNMP related statements, the protocol version is irrelevant. Nevertheless, some statements are more applicable to SNMPv1/SNMPv2c environments, while other statements (especially those concerned with security) are more applicable to SNMPv3 environments.
以下のテキストはSNMPの異なった見解の間でどんな明白な区別もしません。 SNMPの関連する声明の大部分において、プロトコルバージョンは無関係です。 それにもかかわらず、いくつかの声明がSNMPv1/SNMPv2c環境により適切です、他の声明(特にセキュリティに関するもの)はSNMPv3環境により適切ですが。
2. Network Management Technologies
2. ネットワークマネージメント技術
During the breakout sessions, the protocol developers assembled a list of the various network management technologies that are available or under active development. For each technology, a list of strong (+) and weak (-) points were identified. There are also some characteristics which appear to be neutral (o).
脱走セッションの間、プロトコル開発者は、利用可能な様々なネットワークマネージメント技術のリストを組み立てたか、または活発な開発でそうしました。 各技術において、強さであっ(+)て弱い(-)ポイントのリストは特定されました。 また、中立(o)であるように見えるいくつかの特性があります。
The list does not attempt to be complete. Focus was given to IETF specific technologies (SNMP, COPS-PR, PCIM) and widely used proprietary technologies (CLI, HTTP/HTML, XML). The existence of other generic management technologies (such as TL1, CORBA, CMIP/GDMO,
リストは、完全であることを試みません。 焦点はIETF独自技術(SNMP、COPS-PR、PCIM)に与えられた、広く使用された専有技術(CLI、HTTP/HTML、XML)でした。 他のジェネリック管理技術の存在、(TL1、CORBA、CMIP/GDMOなどのように
Schoenwaelder Informational [Page 3] RFC 3535 IAB Network Management Workshop May 2003
[3ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
TMN) or specific management technologies for specific problem domains (such as RADIUS, DHCP, BGP, OSPF) were acknowledged, but were not the focus of discussion.
TMN) または、ドメイン(RADIUS、DHCP、BGP、OSPFなどの)が承認されたのにもかかわらずの、議論の焦点でなかったのにおける特定の問題のための特定の管理技術。
2.1 SNMP / SMI / MIBs
2.1 SNMP/SMI/MIBs
The SNMP management technology was created in the late 1980s and has since been widely implemented and deployed in the Internet. There is lots of implementational and operational experience, and the characteristics of the technology are thus well understood.
SNMP管理技術は、以来、1980年代後半に作成されて、広く実装されて、インターネットで配布されています。 多くのimplementationalと運用経験があります、そして、技術の特性はこのようにしてよく理解されています。
+ SNMP works reasonably well for device monitoring. The stateless
nature of SNMP is useful for statistical and status polling.
+ SNMPはデバイスモニターに合理的にうまくいきます。 SNMPの状態がない本質は統計的、そして、状態世論調査の役に立ちます。
+ SNMP is widely deployed for basic monitoring. Some core MIB
modules, such as the IF-MIB [RFC2863], are implemented on most
networking devices.
+ SNMPは基本的なモニターのために広く配布されます。 いくつかのコアMIBモジュールと、そのようなもの、-、MIB、[RFC2863]、ほとんどのネットワークデバイスでは、実装されます。
+ There are many well defined proprietary MIB modules developed by
network device vendors to support their management products.
そこの+は彼らの管理が製品であるとサポートするためにネットワークデバイスベンダーによって開発された多くのよく定義された独占MIBモジュールです。
+ SNMP is an important data source for systems that do event
correlation, alarm detection, and root cause analysis.
+ SNMPはイベント相関関係、アラーム検出、および原因解析をするシステムのための重要なデータ送信端末です。
o SNMP requires applications to be useful. SNMP was, from its early
days, designed as a programmatic interface between management
applications and devices. As such, using SNMP without management
applications or smart tools appears to be more complicated.
o SNMPは、アプリケーションが役に立つのを必要とします。 初期から、SNMPは管理アプリケーションとデバイスとのプログラムに従ったインタフェースとして設計されました。 そういうものとして、管理アプリケーションも賢いツールなしでSNMPを使用するのは、より複雑であるように見えます。
o Standardized MIB modules often lack writable MIB objects which can
be used for configuration, and this leads to a situation where the
interesting writable objects exist in proprietary MIB modules.
o 標準化されたMIBモジュールはしばしば構成に使用できる書き込み可能なMIBオブジェクトを欠いています、そして、これはおもしろい書き込み可能なオブジェクトが独占MIBモジュールで存在する状況に通じます。
- There are scaling problems with regard to the number of objects in
a device. While SNMP provides reasonable performance for the
retrieval of a small amount of data from many devices, it becomes
rather slow when retrieving large amounts of data (such as routing
tables) from a few devices.
- デバイスのオブジェクトの数に関してスケーリング問題があります。 SNMPは多くのデバイスから少量のデータの検索のための妥当な性能を提供しますが、いくつかのデバイスからの多量のデータ(経路指定テーブルなどの)を検索するとき、それはかなり遅くなります。
- There is too little deployment of writable MIB modules. While
there are some notable exceptions in areas, such as cable modems
where writable MIB modules are essential, it appears that router
equipment is usually not fully configurable via SNMP.
- 書き込み可能なMIBモジュールのあまりに少ない展開があります。 いくつかの注目に値する例外が書き込み可能なMIBモジュールが不可欠であるケーブルモデムなどの領域にある間、通常、ルータ設備がSNMPを通して完全に構成可能であるというわけではないように見えます。
- The SNMP transactional model and the protocol constraints make it
more complex to implement MIBs, as compared to the implementation
of commands of a command line interface interpreter. A logical
operation on a MIB can turn into a sequence of SNMP interactions
- SNMPの取引のモデルとプロトコル規制でMIBsを実装するのは、より複雑になります、コマンドラインインタフェースインタプリタのコマンドの実装と比べて。 MIBの上の論理演算はSNMP相互作用の系列に変わることができます。
Schoenwaelder Informational [Page 4] RFC 3535 IAB Network Management Workshop May 2003
[4ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
where the implementation has to maintain state until the operation
is complete, or until a failure has been determined. In case of a
failure, a robust implementation must be smart enough to roll the
device back into a consistent state.
実装がどこで操作まで状態を維持しなければならないかは、完全であるか、または失敗まで決定しています。 失敗の場合には、強健な実装は一貫した状態にデバイスを転がしてのけることができるくらい賢くなければなりません。
- SNMP does not support easy retrieval and playback of
configurations. One part of the problem is that it is not easy to
identify configuration objects. Another part of the problem is
that the naming system is very specific and physical device
reconfigurations can thus break the capability to play back a
previous configuration.
- SNMPは構成の簡単な検索と再生をサポートしません。 問題の一部による構成オブジェクトを特定するのが簡単でないということです。 問題の別の部分は命名システムが非常に特定であり、その結果、フィジカル・デバイス再構成が前の構成を再生する能力を壊すことができるということです。
- There is often a semantic mismatch between the task-oriented view
of the world usually preferred by operators and the data-centric
view of the world provided by SNMP. Mapping from a task-oriented
view to the data-centric view often requires some non-trivial code
on the management application side.
- 通常、オペレータによって好まれた世界のタスク指向の視点とSNMPによって提供されたデータ中心の世界観の間には、意味ミスマッチがしばしばあります。 タスク指向の視点からデータ中心の視点までのマッピングはしばしば管理アプリケーション側の何らかの重要なコードを必要とします。
- Several standardized MIB modules lack a description of high-level
procedures. It is often not obvious from reading the MIB modules
how certain high-level tasks are accomplished, which leads to
several different ways to achieve the same goal, which increases
costs and hinders interoperability.
- いくつかの標準化されたMIBモジュールがハイレベルの手順の記述を欠いています。 それは、あるハイレベルのタスクがどう優れているかをMIBモジュールに読み込むので、しばしば明白であるというわけではありません(コストを増強して、相互運用性を妨げるのと同じ目標を達成するいくつかの異なった方法に通じます)。
A more detailed discussion about the SNMP management technology can be found in Section 4.
セクション4でSNMP管理技術についての、より詳細な議論を見つけることができます。
2.2 COPS-PR / SPPI / PIBs
2.2 巡査PR/SPPI/PIBs
The COPS protocol [RFC2748] was defined in the late 1990s to support policy control over QoS signaling protocols. The COPS-PR extension allows provision policy information on devises.
COPSプロトコル[RFC2748]は、1990年代後半にQoSシグナリングプロトコルの方針コントロールをサポートするために定義されました。 COPS-PR拡大は捻出の支給方針情報を許容します。
+ COPS-PR allows high-level transactions for single devices,
including deleting one configuration and replacing it with
another.
1つの構成を削除するのを含めて、それを別のものに取り替えて、+ COPS-PRは単一のデバイスのためのハイレベルのトランザクションを許容します。
+ COPS-PRs non-overlapping instance namespace normally ensures that
no other manager can corrupt a specific configuration. All
transactions for a given instance namespace are required to be
executed in-order.
+ 通常、非重なっているインスタンス名前空間がどんなその他のものも確実にしないCOPS-PRマネージャは特定の構成を崩壊させることができます。 与えられたインスタンス名前空間のためのすべてのトランザクションが、整然とした状態で実行されるのに必要です。
+ Both manager and device states are completely synchronized with
one another at all times. If there is a failure in communication,
the state is resynchronized when the network is operating properly
again and the device's network configuration is valid.
+ マネージャとデバイス州の両方がお互いに完全にいつも連動します。 ネットワークが再び適切に作動しているとき、コミュニケーションに失敗があれば、状態は再連動します、そして、デバイスのネットワーク・コンフィギュレーションは有効です。
Schoenwaelder Informational [Page 5] RFC 3535 IAB Network Management Workshop May 2003
[5ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
+ The atomicity of transactions is well-defined. If there is any
failure in a transaction, that specific failure is reported to the
manager, and the local configuration is supposed to be
automatically rolled-back to the state of the last "good"
transaction.
+ トランザクションの最小単位は明確です。 トランザクションに何か失敗があれば、その特定の失敗はマネージャに報告されます、そして、地方の構成によって自動的に最後の「良い」トランザクションの状態にロールバックされるべきです。
+ Capability reporting is part of the framework PIB which must be
supported by COPS-PR implementations. This allows management
applications to adapt to the capabilities present on a device.
+ 能力報告はCOPS-PR実装でサポートしなければならないフレームワークPIBの一部です。 これで、管理アプリケーションはデバイスの現在の能力に順応できます。
+ The focus of COPS-PR is configuration, and the protocol has been
optimized for this purpose (by using for example TCP as a
transport mechanism).
+ COPS-PRの焦点は構成です、そして、プロトコルはこのために(移送機構として例えばTCPを使用することによって)最適化されました。
o Only a single manager is allowed to have control, at any point in
time, for a given subject category on a device. (The subject
category maps to a COPS Client-Type.) This single manager
assumption simplifies the protocol as it makes it easier to
maintain shared state.
o 独身のマネージャだけがコントロールを持つことができます、時間内にの任意な点で、デバイスの上の与えられた対象のカテゴリのために。 (COPS Client-タイプへの対象のカテゴリ地図。) 共有された状態を維持するのをより簡単にするとき、このただ一つのマネージャ仮定はプロトコルを簡素化します。
o Similar to SNMP, COPS-PR requires applications to be useful since
it is also designed as a programmatic interface between management
applications and devices.
o SNMPと同様です、また、それが管理アプリケーションとデバイスとのプログラムに従ったインタフェースとして設計されているので、COPS-PRはアプリケーションが役に立つのを必要とします。
- As of the time of the meeting, there are no standardized PIB
modules.
- ミーティングの時現在、PIBモジュールは標準化されません。
- Compared to SNMP, there is not yet enough experience to understand
the strong and weak aspects of the protocol in operational
environments.
- SNMPと比べて、プロトコルの強弱局面を理解できるくらいの経験がまだ運用環境にありません。
- COPS-PR does not support easy retrieval and playback of
configurations. The reasons are similar as for SNMP.
- COPS-PRは構成の簡単な検索と再生をサポートしません。 理由はSNMPのように同様です。
- The COPS-PR view of the world is data-centric, similar to SNMP's
view of the world. A mapping from the data-centric view to a
task-oriented view and vice versa, has similar complexities as
with SNMP.
- COPS-PR世界観は、データ中心であって、SNMPの世界観と同様です。 データ中心からのマッピングは、逆もまた同様にタスク指向の視点として見て、SNMPと共に同様の複雑さを持っています。
2.3 CIM / MOF / UML / PCIM
2.3 CIM/ MOF / UML / PCIM
The development of the Common Information Model (CIM) [CIM] started in the DMTF in the mid 1990s. The development follows a top-down approach where core classes are defined first and later extended to model specific services. The DMTF and the IETF jointly developed policy extensions of the CIM, known as PCIM [RFC3060].
Common情報Model(CIM)[CIM]の開発は1990年代の半ばDMTFで始まりました。 開発はコアのクラスが最初に、定義されて、後で特定のサービスをモデル化するために広げられるところにトップダウンのアプローチに続きます。 DMTFとIETFは共同でPCIM[RFC3060]として知られているCIMの方針拡大を発生しました。
Schoenwaelder Informational [Page 6] RFC 3535 IAB Network Management Workshop May 2003
[6ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
+ The CIM technology generally follows principles of object-
orientation with full support of methods on data objects, which is
not available in SNMP or COPS-PR.
一般に、データ・オブジェクトにおけるメソッドの全面的な支援がSNMPかCOPS-PRで利用可能でなく+ CIM技術はオブジェクトオリエンテーションの原則に従います。
+ The MOF format allows representation of instances in a common
format. No such common format exists for SNMP or COPS-PR. It is
of course possible to store instances in the form of BER encoded
ASN.1 sequences, but this is generally not suitable for human
readability.
+ MOF形式は一般的な形式における、インスタンスの表現を許容します。 そのようなどんな一般的な形式もSNMPかCOPS-PRのために存在していません。 インスタンスを蓄えるために、BERのフォームがASN.1系列をコード化したのが、もちろん可能ですが、一般に、これは人間の読み易さに適していません。
+ There is support for a query facility which allows the locating of
CIM objects. However, the query language itself is not yet
specified as part of the CIM standards. Implementations currently
use proprietary query languages, such as the Windows Management
Instrumentation Query Language (WQL).
そこの+はCIMオブジェクトの場所を見つけることを許容する質問施設のサポートです。 しかしながら、照会言語自体はCIM規格の一部としてまだ指定されていません。 実装は現在、Windows Management Instrumentation Query Languageなどの独占照会言語(WQL)を使用します。
+ The information modeling work in CIM is done by using Unified
Modeling Language (UML) as a graphical notation. This attracts
people with a computer science background who have learned to use
UML as part of their education.
グラフィカルな記法として統一モデリング言語(UML)を使用することによって、+ CIMにおける情報モデル仕事をします。 これはコンピュータサイエンスバックグラウンドがある彼らの教育の一部としてUMLを使用することを学んだ人々を引き付けます。
o The main practical use of CIM schemas today seems to be the
definition of data structures used internally by management
systems.
o CIM schemasの主な実用は今日、マネージメントシステムによって内部的に使用されるデータ構造の定義であるように思えます。
- The CIM schemas have rather complex interrelationships that must
be understood before one can reasonably extend the set of existing
schemas.
- CIM schemasには、1つが合理的に既存のschemasのセットを広げることができる前に理解しなければならないかなり複雑な相互関係があります。
- Interoperability between CIM implementations seems to be
problematic compared to the number of interoperable SNMP
implementations available today.
- CIM実装の間の相互運用性は今日利用可能な共同利用できるSNMP実装の数と比べて、問題が多いように思えます。
- So far, CIM schemas have seen limited implementation and usage as
an interface between management systems and network devices.
- 今までのところ、CIM schemasはマネージメントシステムとネットワークデバイスとのインタフェースであると限られた実装と用法をみなしました。
2.4 CLI / TELNET / SSH
2.4 CLI/telnet/セキュアシェル (SSH)
Most devices have a builtin command line interface (CLI) for configuration and troubleshooting purposes. Network access to the CLI has traditionally been through the TELNET protocol, while the SSH protocol is gaining momentum to address security issues associated with TELNET. In the following, only CLIs that actually parse and execute commands are considered. (Menu-oriented interfaces are difficult for automation and thus not relevant here.)
ほとんどのデバイスには、構成とトラブルシューティング目的のための作り付けのコマンドラインインタフェース(CLI)があります。 TELNETプロトコルを通してCLIへのネットワークアクセスが伝統的にありました、SSHプロトコルがセキュリティがTELNETに関連している問題であると扱うためにはずみがついている間。 以下では、実際にコマンドを分析して、実行するCLIsだけが考えられます。 (メニュー指向のインタフェースは、オートメーションに難しくて、その結果、ここで関連していません。)
+ Command line interfaces are generally task-oriented, which make
them easier to use for human operators.
一般に、+ コマンドラインインタフェースはタスク指向です(人間のオペレータにそれらを使用するのをより簡単にします)。
Schoenwaelder Informational [Page 7] RFC 3535 IAB Network Management Workshop May 2003
[7ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
+ A saved sequence of textual commands can easily be replayed.
Simple substitutions can be made with arbitrary text processing
tools.
容易に+ 原文のコマンドの保存している系列を再演できます。 任意のテキスト処理ツールで簡単な代替をすることができます。
+ It is usually necessary to learn at least parts of the command
line interface of new devices in order to create the initial
configuration. Once people have learned (parts of) the command
line interface, it is natural for them to use the same interface
and abstractions for automating configuration changes.
通常、+ それが、初期の構成を作成するために少なくとも新しいデバイスのコマンドラインインタフェースの部品を学ぶのに必要です。 一度、人々が学んだことがある、(離れている、)、コマンドラインインタフェース、彼らが構成変更を自動化するのに同じインタフェースと抽象化を使用するのは、当然です。
+ A command line interface does not require any special purpose
applications (telnet and ssh are readily available on most systems
today).
+ コマンドラインインタフェースは少しの専用アプリケーションも必要としません(telnetとセキュアシェル (SSH)は今日、ほとんどのシステムの上で容易に利用可能です)。
+ Most command line interfaces provide context sensitive help that
reduces the learning curve.
+ ほとんどのコマンドラインインタフェースがラーニングカーブを減少させるコンテキストセンシティブヘルプを提供します。
- Some command line interfaces lack a common data model. It is very
well possible that the same command on different devices, even
from the same vendor, behaves differently.
- いくつかのコマンドラインインタフェースが一般的なデータモデルを欠いています。 異なったデバイスと、同じベンダーさえからの同じコマンドが異なって振る舞うのは、非常によく可能です。
- The command line interface is primarily targeted to humans which
can adapt to minor syntax and format changes easily. Using
command line interfaces as a programmatic interface is troublesome
because of parsing complexities.
- コマンドラインインタフェースは主としてどれが小さい方の構文に順応できるか、そして、形式が容易に変える人間に狙います。 プログラムに従ったインタフェースとしてコマンドラインインタフェースを使用するのは構文解析の複雑さのために厄介です。
- Command line interfaces often lack proper version control for the
syntax and the semantics. It is therefore time consuming and
error prone to maintain programs or scripts that interface with
different versions of a command line interface.
- コマンドラインインタフェースはしばしば構文と意味論のための適切なバージョンコントロールを欠いています。 それは、したがって、時間がかかって誤りプログラムかスクリプトがコマンドラインインタフェースの異なった見解とのそのインタフェースであると主張する傾向があります。
- Since command line interfaces are proprietary, they can not be
used efficiently to automate processes in an environment with a
heterogenous set of devices.
- コマンドラインインタフェースが独占であるので、デバイスのheterogenousセットで環境でプロセスを自動化するのに効率的にそれらを使用できません。
- The access control facilities, if present at all, are often ad-hoc
and sometimes insufficient.
- 少しでも存在しているなら、アクセス制御機能はしばしば臨時で時々不十分です。
2.5 HTTP / HTML
2.5 HTTP/HTML
Many devices have an embedded web server which can be used to configure the device and to obtain status information. The commonly used protocol is HTTP, and information is rendered in HTML. Some devices also expect that clients have facilities such as Java or Java Script.
多くのデバイスには、デバイスを構成して、状態情報を得るのに使用できる埋め込まれたウェブサーバーがあります。 一般的に使用されたプロトコルはHTTPです、そして、情報はHTMLに表されます。 また、いくつかのデバイスが、クライアントがJavaかJavaScriptなどの施設を持っていると予想します。
+ Embedded web servers for configuration are end-user friendly and
solution oriented.
+ 構成のための埋め込まれたウェブサーバーはエンドユーザ好意的であって、ソリューション指向しています。
Schoenwaelder Informational [Page 8] RFC 3535 IAB Network Management Workshop May 2003
[8ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
+ Embedded web servers are suitable for configuring consumer devices
by inexperienced users.
+ 埋め込まれたウェブサーバーは未経験のユーザで民生品を構成するのに適当です。
+ Web server configuration is widely deployed, especially in boxes
targeted to the consumer market.
+ ウェブサーバー構成は消費市場に狙う箱の特に中に広く配布されます。
+ There is no need for specialized applications to use embedded web
servers since web browsers are commonly available today.
そこの+はウェブブラウザが今日一般的に利用可能であるので専門化しているアプリケーションが埋め込まれたウェブサーバーを使用する必要性ではありません。
- Embedded web servers are management application hostile. Parsing
HTML pages to extract useful information is extremely painful.
- 埋め込まれたウェブサーバーは管理アプリケーション敵対的です。 役に立つ情報を抜粋するためにHTML形式のページを分析するのは非常に苦痛です。
- Replay of configuration is often problematic, either because the
web pages rely on some active content or because different
versions of the same device use different ways to interact with
the user.
- 構成の再生はしばしば問題が多いです、ウェブページが何らかのアクティブな内容を当てにするか、または同じデバイスの異なった見解がユーザと対話する異なった方法を使用するので。
- The access control facilities, if present at all, are often ad-hoc
and sometimes insufficient.
- 少しでも存在しているなら、アクセス制御機能はしばしば臨時で時々不十分です。
2.6 XML
2.6 XML
In the late 1990's, some vendors started to use the Extensible Markup Language (XML) [XML] for describing device configurations and for protocols that can be used to retrieve and manipulate XML formatted configurations.
1990年代後半に、いくつかのベンダーが、デバイス構成について説明するのに、拡張マークアップ言語(XML)[XML]を使用し始めて、XMLを検索して、操作するのに使用できるプロトコルのために構成をフォーマットしました。
+ XML is a machine readable format which is easy to process and
there are many good off the shelf tools available.
+ XMLは読み込み可能な処理しやすいマシン形式です、そして、利用可能な多くの良いすぐ入手できるツールがあります。
+ XML allows the description of structured data of almost arbitrary
complexity.
+ XMLはほとんど任意の複雑さの構造化されたデータの記述を許容します。
+ The basic syntax rules behind XML are relatively easy to learn.
+ XMLの後ろの基本的なシンタックス・ルールは比較的学びやすいです。
+ XML provides a document-oriented view of configuration data
(similar to many proprietary configuration file formats).
+ XMLはコンフィギュレーション・データ(多くの独占構成ファイル形式と同様の)のドキュメント指向の意見を提供します。
+ XML has a robust schema language XSD [XSD] for which many good off
the shelf tools exist.
+ XMLには、多くの良いすぐ入手できるツールが存在する強健なスキーマ言語XSD[XSD]があります。
o XML alone is just syntax. XML schemas must be carefully designed
to make XML truly useful as a data exchange format.
o 唯一のXMLはただ構文です。 XMLを本当に、データ交換形式として役に立つようにするように入念にXML schemasを設計しなければなりません。
Schoenwaelder Informational [Page 9] RFC 3535 IAB Network Management Workshop May 2003
[9ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
- XML is rather verbose. This either increases the bandwidth
required to move management information around (which is an issue
in e.g., wireless or asymmetric cable networks) or it requires
that the systems involved have the processing power to do on the
fly compression/decompression.
- XMLはかなり冗長です。 これが周囲で経営情報を動かすのに必要である帯域幅(例えば、ワイヤレスの、または、非対称のケーブルネットワークで問題である)を増強するか、または飛行中の圧縮/減圧をするのが、かかわったシステムには処理能力があるのを必要とします。
- There is a lack of commonly accepted standardized management
specific XML schemas.
- 一般的に受け入れられた標準化された管理の特定のXML schemasの不足があります。
3. Operator Requirements
3. オペレータ要件
During the breakout session, the operators were asked to identify needs that have not been sufficiently addressed. The results produced during the breakout session were later discussed and resulted in the following list of operator requirements.
脱走セッションの間、オペレータが十分扱われていない必要性を特定するように頼まれました。 脱走セッションの間に生まれた結果は、後で議論して、オペレータ要件の以下のリストをもたらしました。
1. Ease of use is a key requirement for any network management
technology from the operators point of view.
1. 使いやすさはオペレータ観点からのどんなネットワークマネージメント技術のための主要な要件です。
2. It is necessary to make a clear distinction between configuration
data, data that describes operational state and statistics. Some
devices make it very hard to determine which parameters were
administratively configured and which were obtained via other
mechanisms such as routing protocols.
2. コンフィギュレーション・データと、操作上の状態について説明するデータと統計の間に一線を画するのが必要です。 いくつかのデバイスで、どのパラメタが行政上構成されたか、そして、どれがルーティング・プロトコルなどの他のメカニズムで得られたかを決定するのが非常に困難になります。
3. It is required to be able to fetch separately configuration data,
operational state data, and statistics from devices, and to be
able to compare these between devices.
3. それが、別々にデバイスからコンフィギュレーション・データ、操作上の州のデータ、および統計をとって来て、デバイスの間でこれらを比較できるように必要です。
4. It is necessary to enable operators to concentrate on the
configuration of the network as a whole rather than individual
devices.
4. オペレータが個々のデバイスよりむしろ全体でネットワークの構成に集中するのを可能にするのが必要です。
5. Support for configuration transactions across a number of devices
would significantly simplify network configuration management.
5. 多くのデバイスの向こう側の構成トランザクションのサポートはネットワーク構成管理をかなり簡素化するでしょう。
6. Given configuration A and configuration B, it should be possible
to generate the operations necessary to get from A to B with
minimal state changes and effects on network and systems. It is
important to minimize the impact caused by configuration changes.
6. 構成Aと構成Bを考えて、ネットワークへの最小量の州の変化と効果とシステムでAからBまで得るのに必要な操作を生成するのは可能であるべきです。構成変更によって引き起こされた影響を最小にするのは重要です。
7. A mechanism to dump and restore configurations is a primitive
operation needed by operators. Standards for pulling and pushing
configurations from/to devices are desirable.
7. 構成をどさっと落として、回復するメカニズムはオペレータによって必要とされた原始の操作です。 /からデバイスまで構成を引いて、押す規格は望ましいです。
Schoenwaelder Informational [Page 10] RFC 3535 IAB Network Management Workshop May 2003
[10ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
8. It must be easy to do consistency checks of configurations over
time and between the ends of a link in order to determine the
changes between two configurations and whether those
configurations are consistent.
8. 2つの構成の間の変化を決定して、それらの構成が一貫しているか否かに関係なく、時間の上と、そして、リンクの端の間で構成の一貫性チェックをするのは簡単であるに違いありません。
9. Network wide configurations are typically stored in central
master databases and transformed into formats that can be pushed
to devices, either by generating sequences of CLI commands or
complete configuration files that are pushed to devices. There
is no common database schema for network configuration, although
the models used by various operators are probably very similar.
It is desirable to extract, document, and standardize the common
parts of these network wide configuration database schemas.
9. デバイスに押されるCLIコマンドか完全な構成ファイルの系列を生成どちらかによって主要なマスターデータベースに通常保存されていて、デバイスに押すことができる形式に変えられた広い構成をネットワークでつないでください。 様々なオペレータによって使用されたモデルはたぶん非常に同様ですが、ネットワーク・コンフィギュレーションのためのどんな一般的なデータベース・スキーマもありません。 これらのネットワーク広い構成データベースschemasの一般的な部分を抽出して、記録して、標準化するのは望ましいです。
10. It is highly desirable that text processing tools such as diff,
and version management tools such as RCS or CVS, can be used to
process configurations, which implies that devices should not
arbitrarily reorder data such as access control lists.
10. 構成を処理するのにデフなどのテキスト処理ツール、およびRCSかCVSなどのバージョン管理ツールを使用できるのは非常に望ましいです、デバイスが任意にそうするべきでないのを含意するもの。アクセスコントロールリストなどの追加注文データ。
11. The granularity of access control needed on management interfaces
needs to match operational needs. Typical requirements are a
role-based access control model and the principle of least
privilege, where a user can be given only the minimum access
necessary to perform a required task.
11. 管理インタフェースで必要であるアクセスコントロールの粒状は、操作上の必要性を合わせる必要があります。 典型的な要件は、役割のベースのアクセス制御モデルと最少の特権の原則です。(そこでは、必要なタスクを実行するのに必要な最低輸入義務しかユーザに与えることができません)。
12. It must be possible to do consistency checks of access control
lists across devices.
12. デバイスの向こう側にアクセスコントロールリストの一貫性チェックをするのは可能であるに違いありません。
13. It is important to distinguish between the distribution of
configurations and the activation of a certain configuration.
Devices should be able to hold multiple configurations.
13. 構成の分配とある構成の起動を見分けるのは重要です。 デバイスは複数の構成を保持するはずであることができます。
14. SNMP access control is data-oriented, while CLI access control is
usually command (task) oriented. Depending on the management
function, sometimes data-oriented or task-oriented access control
makes more sense. As such, it is a requirement to support both
data-oriented and task-oriented access control.
14. SNMPアクセスコントロールはデータ指向ですが、通常、CLIアクセスコントロールは(タスク)が適応させたコマンドです。 管理機能によって、時々データ指向の、または、タスク指向のアクセスコントロールは、より多く理解できます。 そういうものとして、それはデータ指向のものと同様にタスク指向のアクセスがコントロールであるとサポートするという要件です。
So far, there is no published document that clearly defines the requirements of the operators.
今までのところ、明確にオペレータの要件を定義する発行されたドキュメントが全くありません。
Schoenwaelder Informational [Page 11] RFC 3535 IAB Network Management Workshop May 2003
[11ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
4. SNMP Framework Discussions
4. SNMPフレームワーク議論
During the discussions, many properties of the SNMP framework were identified.
議論の間、SNMPフレームワークの多くの特性が特定されました。
1. It is usually not possible to retrieve complete device
configurations via SNMP so that they can be compared with
previous configurations or checked for consistency across
devices. There is usually only incomplete coverage of device
features via the SNMP interface, and there is a lack of
differentiation between configuration data and operational state
data for many features.
1. 通常、SNMPを通して完全なデバイス構成を検索するのは、それらを前の構成と比較するか、または一貫性がないかどうかデバイスの向こう側にチェックできるくらい可能ではありません。 SNMPインタフェースを通して通常、デバイスの特徴の不完全な適用範囲しかありません、そして、多くの特徴のためのコンフィギュレーション・データと操作上の州のデータの間には、分化の不足があります。
2. The quality of SNMP instrumentations is sometimes disappointing.
SNMP access sometimes crashes systems or returns wrong data.
2. SNMP計装の品質は時々期待はずれです。 SNMPアクセスは、システムを時々墜落させるか、または間違ったデータを返します。
3. MIB modules and their implementations are not available in a
timely manner (sometimes MIB modules lag years behind) which
forces users to use the CLI.
3. MIBモジュールとそれらの実装はユーザがやむを得ずCLIを使用するタイムリーな方法(時々立ち遅れ数年遅れるところのMIBモジュール)で利用可能ではありません。
4. Operators view current SNMP programming/scripting interfaces as
being too low-level and thus too time consuming and inconvenient
for practical use.
4. オペレータは実用に低レベル過ぎてその結果、時間がかかり過ぎて不便であると現在のSNMPプログラミング/スクリプティングインタフェースをみなします。
5. Lexicographic ordering is sometimes artificial with regard to
internal data structures and causes either significant runtime
overhead, or increases implementation costs or implementation
delay or both.
5. 辞書編集の注文は、時々内部のデータ構造に関して人工であり、重要なランタイムオーバーヘッドか増加のどちらかに実装コスト、実装遅れまたは両方を引き起こします。
6. Poor performance for bulk data transfers. The typical examples
are routing tables.
6. バルク・データ転送のための不十分な性能。 典型的な例は経路指定テーブルです。
7. Poor performance on query operations that were not anticipated
during the MIB design. A typical example is the following query:
Which outgoing interface is being used for a specific destination
address?
7. MIBデザインの間に予期されなかった質問操作に関する不十分な性能。 典型的な例は以下の質問です: どの外向的なインタフェースが特定の送付先アドレスに使用されていますか?
8. The SNMP credentials and key management are considered complex,
especially since they do not integrate well with other existing
credential and key management systems.
8. SNMP資格証明書とかぎ管理は複雑であると考えられます、特に他の既存の資格証明の、そして、主要なマネージメントシステムとよく統合しないので。
9. The SMI language is hard to deal with and not very practical.
9. SMI言語は、対処しにくくてそれほど実用的ではありません。
10. MIB modules are often over-engineered in the sense that they
contain lots of variables that operators do not look at.
10. MIBモジュールはオペレータが見ない多くの変数を含んでいるという意味でしばしば過剰設計されます。
Schoenwaelder Informational [Page 12] RFC 3535 IAB Network Management Workshop May 2003
[12ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
11. SNMP traps are used to track state changes but often syslog
messages are considered more useful since they usually contain
more information to describe the problem. SNMP traps usually
require subsequent get operations to figure out what the trap
really means.
11. SNMP罠は州の変化を追うのに使用されますが、通常問題について説明する詳しい情報を含んでいるので、しばしば、syslogメッセージは、より役に立つと考えられます。 通常、SNMP罠が必要である、その後、操作に罠が本当に何を意味するか理解させてください。
12. Device manufacturers find SNMP instrumentations inherently
difficult to implement, especially with complex table indexing
schemes and table interrelationships.
12. デバイスメーカーは、SNMP計装が特に複雑なテーブルが体系とテーブル相互関係に索引をつけていて実装するのが本来難しいのがわかります。
13. MIB modules often lack a description of how the various objects
can be used to achieve certain management functions. (MIB
modules can often be characterized as a list of ingredients
without a recipe.)
13. MIBモジュールはしばしばある管理機能を獲得するのにどう様々なオブジェクトを使用できるかに関する記述を欠いています。 (成分のリストとしてレシピなしでMIBモジュールをしばしば特徴付けることができます。)
14. The lack of structured types and various RPC interactions
(methods) make MIB modules much more complex to design and
implement.
14. (メソッド)が設計するためにはるかに複雑なMIBモジュールと道具をする構造化されたタイプと様々なRPC相互作用の不足。
15. The lack of query and aggregation capabilities (reduction of
data) causes efficiency and scalability problems.
15. 質問と集合能力(データの整理)の不足は効率とスケーラビリティ問題を引き起こします。
16. The SNMP protocol was simplified in terms of the number of
protocol operations and resource requirements on managed devices.
It was not simplified in terms of usability by network operators
or instrumentation implementors.
16. SNMPプロトコルは管理されたデバイスでプロトコル操作とリソース要件の数で簡素化されました。 それはユーザビリティでネットワーク・オペレータか計装作成者によって簡素化されませんでした。
17. There is a semantic mismatch between the low-level data-oriented
abstraction level of MIB modules and the task-oriented
abstraction level desired by network operators. Bridging the gap
with tools is in principle possible, but in general it is
expensive as it requires some serious development and programming
efforts.
17. MIBモジュールの低レベルであるデータ指向の抽象度とネットワーク・オペレータによって望まれていたタスク指向の抽象度の間には、意味ミスマッチがあります。 ツールで間隙を塞ぐのは原則として可能ですが、いくつかの重大な進展とプログラミング努力を必要とするとき、一般に、それは高価です。
18. SNMP seems to work reasonably well for small devices which have a
limited number of managed objects and where end-user management
applications are shipped by the vendor. For more complex
devices, SNMP becomes too expensive and too hard to use.
18. SNMPは、限られた数の管理オブジェクトを持って、エンドユーザ管理アプリケーションがベンダーによって出荷される小さいデバイスに合理的にうまくいくように思えます。 より複雑なデバイスに関しては、SNMPは高価過ぎて使用できないくらい困難になります。
19. There is a disincentive for vendors to implement SNMP equivalent
MIB modules for all their CLI commands because they do not see a
valued proposition. This undermines the value of third party
standard SNMP solutions.
19. 評価された提案を見ないのでベンダーが彼らのすべてのCLIコマンドのための同等なMIBモジュールをSNMPに実装するように、行動を妨げるものがあります。 これは第三者の標準のSNMPソリューションの値を弱体化させます。
20. Rapid feature development is in general not compatible with the
standardization of the configuration interface.
20. 一般に、急速な特徴開発はそうです。構成インタフェースの標準化と互換性がありません。
Schoenwaelder Informational [Page 13] RFC 3535 IAB Network Management Workshop May 2003
[13ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
5. Consolidated Observations
5. 統合観測
1. Programmatic interfaces have to provide full coverage otherwise
they will not be used by network operators since they have to
revert to CLIs anyway.
1. プログラムに従ったインタフェースは完全適用範囲を提供しなければなりません。そうでなければ、彼らがとにかくCLIsに戻らなければならないので、それらはネットワーク・オペレータによって使用されないでしょう。
2. Operators perceive that equipment vendors do not implement MIB
modules in a timely manner. Neither read-only nor read-write MIB
modules are available on time today.
2. オペレータは、設備ベンダーが直ちにMIBにモジュールを実装しないと知覚します。 書き込み禁止も読書して書いていないMIBモジュールも今日、定刻に利用可能です。
3. The attendees perceive that right now it is too hard to implement
useful MIB modules within network equipment.
3. 出席者は、たった今ネットワーク装置の中で役に立つMIBモジュールを実装するのが困難過ぎると知覚します。
4. Because of the previous items, SNMP is not widely used today for
network device configuration, although there are notable
exceptions.
4. 前の項目のために、注目に値する例外がありますが、SNMPは今日、ネットワークデバイス構成に広く使用されません。
5. It is necessary to clearly distinguish between configuration data
and operational data.
5. 明確にコンフィギュレーション・データと操作上のデータを見分けるのが必要です。
6. It would be nice to have a single data definition language for
all programmatic interfaces (in case there happen to be multiple
programmatic interfaces).
6. すべてのプログラムに従ったインタフェースへのただ一つのデータ定義言語を持ってうれしいでしょう(複数のプログラムに従ったインタフェースがたまたまあるといけないので)。
7. In general, there is a lack of input from the enterprise network
space. Those enterprises who provided input tend to operate
their networks like network operators.
7. 一般に、企業網スペースからの入力の不足があります。 入力されるならそれらのネットワークを経営する傾向がある企業がネットワーク・オペレータが好きです。
8. It is required to be able to dump and reload a device
configuration in a textual format in a standard manner across
multiple vendors and device types.
8. それが、複数のベンダーと装置タイプの向こう側に原文の形式で標準の方法でデバイス構成をどさっと落として、再び積むことができるように必要です。
9. It is desirable to have a mechanism to distribute configurations
to devices under transactional constraints.
9. デバイスに取引の規制で構成を分配するメカニズムを持っているのは望ましいです。
10. Eliminating SNMP altogether is not an option.
10. 全体でSNMPを排除するのは、オプションではありません。
11. Robust access control is needed. In addition, it is desirable to
be able to enable/disable individual MIB modules actually
implemented on a device.
11. 体力を要しているアクセスコントロールが必要です。 さらに、実際にデバイスで実装された独特のMIBモジュールは可能にするか、または無効にすることができるのが望ましいです。
12. Textual configuration files should be able to contain
international characters. Human-readable strings should utilize
the least-bad internationalized character set and encoding, which
this year almost certainly means UTF-8. Protocol elements should
be in case insensitive ASCII.
12. 原文の構成ファイルは国際的な人物を含むことができるべきです。 人間読み込み可能なストリングは最も最少に悪い国際化している文字集合とコード化を利用するはずです。(それは、今年、ほぼ確実にUTF-8を意味します)。 大文字と小文字を区別しないASCIIにはプロトコル要素があるはずです。
Schoenwaelder Informational [Page 14] RFC 3535 IAB Network Management Workshop May 2003
[14ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
13. The deployed tools for event/alarm correlation, root cause
analysis and logging are not sufficient.
13. イベント/アラーム相関関係、原因解析、および伐採のための配布しているツールは十分ではありません。
14. There is a need to support a human interface and a programmatic
interface.
14. ヒューマンインターフェースをサポートする必要性とプログラムに従ったインタフェースがあります。
15. The internal method routines for both interfaces should be the
same to ensure that data exchanged between these two interfaces
is always consistent.
15. 両方のインタフェースのための内部のメソッドルーチンは、これらの2つのインタフェースの間で交換されたデータがいつも一貫しているのを保証するために同じであるべきです。
16. The implementation costs have to be low on devices.
16. 実装コストはデバイスで低くなければなりません。
17. The implementation costs have to be low on managers.
17. 実装コストはマネージャに低くなければなりません。
18. The specification costs for data models have to be low.
18. データモデルのための仕様コストは低くなければなりません。
19. Standardization costs for data models have to be low.
19. データモデルのための標準化コストは低くなければなりません。
20. There should be a single data modeling language with a human
friendly syntax.
20. 人間の好意的な構文があるただ一つのデータのモデル化言語があるべきです。
21. The data modeling language must support compound data types.
21. データのモデル化言語は合成データ型をサポートしなければなりません。
22. There is a need for data aggregation capabilities on the devices.
22. デバイスの上のデータ集合能力の必要があります。
23. There should be a common data interchange format for instance
data that allows easy post-processing and analysis.
23. 一般的なデータ置き換えが例えば簡単な後工程と分析を許すデータをフォーマットするというそこでは、ことであるべきです。
24. There is a need for a common data exchange format with single and
multi-system transactions (which implies rollback across devices
in error situations).
24. 一般的なデータ交換形式の必要が単一の、そして、マルチシステムのトランザクションと共にあります(デバイスの向こう側にエラー状態でロールバックを含意します)。
25. There is a need to reduce the semantic mismatch between current
data models and the primitives used by operators.
25. 現在のデータモデルとオペレータによって使用された基関数の間には、意味ミスマッチを減少させる必要があります。
26. It should be possible to perform operations on selected subsets
of management data.
26. 管理データの選択された部分集合に操作を実行するのは可能であるべきです。
27. It is necessary to discover the capabilities of devices.
27. デバイスの能力を発見するのが必要です。
28. There is a need for a secure transport, authentication, identity,
and access control which integrates well with existing key and
credential management infrastructure.
28. 既存の主要で資格証明の管理インフラストラクチャとよく統合される安全な輸送、認証、アイデンティティ、およびアクセスコントロールの必要があります。
29. It must be possible to define task oriented views and access
control rules.
29. タスクを定義するのが視点とアクセス制御規則を適応させたのは、可能であるに違いありません。
Schoenwaelder Informational [Page 15] RFC 3535 IAB Network Management Workshop May 2003
[15ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
30. The complete configuration of a device should be doable with a
single protocol.
30. デバイスの完全な構成はただ一つのプロトコルにできるべきです。
31. A configuration protocol must be efficient and reliable and it
must scale in the number of transactions and devices.
31. 構成プロトコルは、効率的であって、信頼できるに違いありません、そして、それはトランザクションとデバイスの数を計量しなければなりません。
32. Devices must be able to support minimally interruptive
configuration deltas.
32. デバイスはinterruptive構成デルタを最少量でサポートすることができなければなりません。
33. A solution must support function call semantics (methods) to
implement functions, such as a longest prefix match on a routing
table.
33. ソリューションは、ファンクションコール意味論が機能を実装する(メソッド)であるとサポートしなければなりません、経路指定テーブルで最も長い接頭語マッチのように。
6. Recommendations
6. 推薦
1. The workshop recommends that the IETF stop forcing working groups
to provide writable MIB modules. It should be the decision of
the working group whether they want to provide writable objects
or not.
1. ワークショップは、IETFが、ワーキンググループに書き込み可能なMIBモジュールを提供させるのを止めることを勧めます。 彼らが書き込み可能なオブジェクトを提供したがっているか否かに関係なく、それはワーキンググループの決定であるべきです。
2. The workshop recommends that a group be formed to investigate why
current MIB modules do not contain all the objects needed by
operators to monitor their networks.
2. ワークショップは、グループが現在のMIBモジュールがなぜ彼らのネットワークをモニターするためにオペレータによって必要とされたすべてのオブジェクトを含まないかを調査するために結成されることを勧めます。
3. The workshop recommends that a group be formed to investigate why
the current SNMP protocol does not satisfy all the monitoring
requirements of operators.
3. ワークショップは、グループが現在のSNMPプロトコルがなぜオペレータのすべての監視要件を満たすというわけではないかを調査するために結成されることを勧めます。
4. The workshop recommends, with strong consensus from both protocol
developers and operators, that the IETF focus resources on the
standardization of configuration management mechanisms.
4. ワークショップは、プロトコル開発者とオペレータの両方からの強いコンセンサスをもってIETFが構成管理メカニズムの標準化にリソースの焦点を合わせることを勧めます。
5. The workshop recommends, with strong consensus from the operators
and rough consensus from the protocol developers, that the
IETF/IRTF should spend resources on the development and
standardization of XML-based device configuration and management
technologies (such as common XML configuration schemas, exchange
protocols and so on).
5. ワークショップは、プロトコル開発者からのオペレータと荒いコンセンサスからの強いコンセンサスをもってIETF/IRTFがXMLベースのデバイス構成と管理技術(一般的なXML構成schemas、交換プロトコルなどなどの)の開発と標準化にリソースを費やすはずであることを勧めます。
6. The workshop recommends, with strong consensus from the operators
and rough consensus from the protocol developers, that the
IETF/IRTF should not spend resources on developing HTML-based or
HTTP-based methods for configuration management.
6. ワークショップは、プロトコル開発者からのオペレータと荒いコンセンサスからの強いコンセンサスをもってIETF/IRTFが構成管理のために展開しているHTMLベースの、または、HTTPベースのメソッドにリソースを費やすはずがないことを勧めます。
Schoenwaelder Informational [Page 16] RFC 3535 IAB Network Management Workshop May 2003
[16ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
7. The workshop recommends, with rough consensus from the operators
and strong consensus from the protocol developers, that the IETF
should continue to spend resources on the evolution of the
SMI/SPPI data definition languages as being done in the SMIng
working group.
7. ワークショップは、プロトコル開発者からのオペレータと強いコンセンサスからの荒いコンセンサスをもってIETFが、SMIngワーキンググループでするとしてSMI/SPPIデータ定義言語の発展にリソースを費やし続けるはずであることを勧めます。
8. The workshop recommends, with split consensus from the operators
and rough consensus from the protocol developers, that the IETF
should spend resources on fixing the MIB development and
standardization process.
8. ワークショップは、プロトコル開発者からのオペレータと荒いコンセンサスからの分裂コンセンサスをもってIETFがMIB開発と標準化過程を修理するのにリソースを費やすはずであることを勧めます。
The workshop also discussed the following items and achieved rough consensus, but did not make a recommendation.
ワークショップも、以下の項目について議論して、荒いコンセンサスを達成しましたが、勧告しませんでした。
1. The workshop had split consensus from the operators and rough
consensus from the protocol developers, that the IETF should not
focus resources on CIM extensions.
1. ワークショップはプロトコル開発者からのIETFがCIM拡大にリソースの焦点を合わせるはずがないというオペレータと荒いコンセンサスからコンセンサスを分けました。
2. The workshop had rough consensus from the protocol developers
that the IETF should not spend resources on COPS-PR development.
So far, the operators have only very limited experience with
COPS-PR. In general, however, they felt that further development
of COPS-PR might be a waste of resources as they assume that
COPS-PR does not really address their requirements.
2. ワークショップには、プロトコル開発者からのIETFがCOPS-PR開発にリソースを費やすはずがないという荒いコンセンサスがありました。 今までのところ、オペレータには、COPS-PRの非常に限られた経験しかありません。 一般に、しかしながら、彼らは、COPS-PRが本当に彼らの要件を扱わないと仮定するときCOPS-PRのさらなる開発がリソースの浪費であるかもしれないと感じました。
3. The workshop had rough consensus from the protocol developers
that the IETF should not spend resources on SPPI PIB definitions.
The operators had rough consensus that they do not care about
SPPI PIBs.
3. ワークショップには、プロトコル開発者からのIETFがSPPI PIB定義にリソースを費やすはずがないという荒いコンセンサスがありました。 オペレータには、彼らがSPPI PIBsを心配しないという荒いコンセンサスがありました。
7. Security Considerations
7. セキュリティ問題
This document is a report of an IAB Network Management workshop. As such, it does not have any direct security implications for the Internet.
このドキュメントはIAB Network Managementワークショップのレポートです。 そういうものとして、それには、インターネットへの少しのダイレクトセキュリティ意味もありません。
8. Acknowledgments
8. 承認
The editor would like to thank Dave Durham, Simon Leinen and John Schnizlein for taking detailed minutes during the workshop.
エディタは、ワークショップの間の詳細な分かかって頂いて、デーヴ・ダラム、サイモンLeinen、およびジョンSchnizleinに感謝したがっています。
Schoenwaelder Informational [Page 17] RFC 3535 IAB Network Management Workshop May 2003
[17ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
Normative References
引用規格
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」RFC3410(2002年12月)。
[CIM] Distributed Management Task Force, "Common Information
Model (CIM) Specification Version 2.2", DSP 0004, June
1999.
[CIM]分散管理特別委員会、「一般的な情報モデル(CIM)仕様バージョン2.2インチ、DSP0004、1999年6月。」
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3060] ムーア、B.、Ellesson、E.、Strassner、J.、およびA.Westerinen、「方針コア情報はモデル化されます--バージョン1仕様」、RFC3060、2001年2月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC2748] ダラム、D.、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith,
"COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084,
March 2001.
[RFC3084]チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年3月。
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0", W3C Recommendation, February
1998.
[XML]は、T.とパオリとJ.とC.Sperberg-マックィーン、「拡張マークアップ言語(XML)1インチ、W3C推薦、1998年2月」をいななかせます。
Informative References
有益な参照
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[XSD] David, D., "XML Schema Part 0: Primer", W3C
Recommendation, May 2001.
[XSD]デヴィッド、D.、「XML図式は0を分けます」。 「入門書」(W3C推薦)は2001がそうするかもしれません。
Schoenwaelder Informational [Page 18] RFC 3535 IAB Network Management Workshop May 2003
[18ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
Appendix - Participants
付録--関係者
Ran Atkinson Extreme Networks Rob Austein InterNetShare Andy Bierman Cisco Systems Steve Bellovin AT&T Randy Bush AT&T Leslie Daigle VeriSign David Durham Intel Vijay Gill Wes Hardaker Network Associates Laboratories Ed Kern Simon Leinen Switch Ken Lindahl University of California Berkeley David Partain Ericsson Andrew Partan UUnet/Verio/MFN Vern Paxson ICIR Aiko Pras Univeristy of Twente Randy Presuhn BMC Software Juergen Schoenwaelder University of Osnabrueck John Schnizlein Cisco Systems Mike St. Johns Ruediger Volk Deutsche Telekom Steve Waldbusser Margaret Wassermann Windriver Glen Waters Nortel Networks Bert Wijnen Lucent
アトキンソンExtremeネットワークロブAustein InterNetShareアンディBiermanシスコシステムズスティーブBellovin AT&TランディブッシュAT&TレスリーDaigleベリサインデヴィッドダラムインテルビジェイエラウェスHardakerネットワーク関連研究所エドKernサイモンLeinen Switchケンリンダールカリフォルニア大学バークレイ校デヴィッドパーテインエリクソンのためにTwenteランディPresuhn BMC SoftwareユルゲンSchoenwaelder OsnabrueckジョンSchnizleinシスコシステムズ大学マイク通りのアンドリューPartan UUnet/Verio/MFNバーンパクソンICIR Aiko Pras Univeristyを走らせました; ジョーンズルーディガーVolkドイツ・テレコムスティーブWaldbusserマーガレットワッセルマンWindriver谷間Watersノーテルは透明な状態でバートWijnenをネットワークでつなぎます。
Author's Address
作者のアドレス
Comments should be submitted to the <nm-ws@ops.ietf.org> mailing list.
the <nm-ws@ops.ietf.org にコメントを提出するべきである、gt;、メーリングリスト。
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
ユルゲンSchoenwaelderの国際大学ブレーメン私書箱750 561 28725・ブレーメンドイツ
Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de
以下に電話をしてください。 +49 3587年の421 200メール: j.schoenwaelder@iu-bremen.de
Schoenwaelder Informational [Page 19] RFC 3535 IAB Network Management Workshop May 2003
[19ページ]RFC3535IABネットワークマネージメントワークショップ2003年5月の情報のSchoenwaelder
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Schoenwaelder Informational [Page 20]
Schoenwaelder情報です。[20ページ]
一覧
スポンサーリンク
