Network Working Group J. Schoenwaelder
Request for Comments: 3535 International University Bremen
Category: Informational May 2003
Overview of the 2002 IAB Network Management Workshop
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書では、ネットワーク管理上のインターネットアーキテクチャ委員会（IAB）で開催されたワークショップの概要を説明します。ワークショップは、ネットワークオペレータとプロトコルの開発者の間で開始し、IETFsはに関する今後の作業に焦点を当てる導くためにワークショップの目的は、重要な対話を継続することだった6月6日、2002年を通して6月4日レストン、VA、USAにCNRIが主催しました。ネットワーク管理。このレポートでは、議論をまとめ、IETF（Internet Engineering Task Force）のコミュニティに結論と提言を示しています。
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
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を簡易ネットワーク管理プロトコル（SNMP）[RFC3410]は1980年代後半に作成されました。 、セキュリティ要件に対応し、最新バージョン（SNMPv3のは）、ちょうど重要な展開を得るために始めている間に最初のバージョン（SNMPv1の）が広く、展開されています。
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.
Distributed Management Task Force（DMTF）によって開発された共通情報モデル（CIM）[CIM]、O、[RFC3060]のルールセット（PCIM）のような高レベルのポリシーを記述するためにDMTFと協力して拡張されました。 LDAPスキーマへの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).
一般的なオープンポリシーサービス（COPS）O [RFC2748]プロトコルが規定の設定にデバイスの情報を拡張されました（COPS-PR）[RFC3084]。作業は、このような差別化サービス（DiffServの）などの特定のサービスのためのデータ定義を定義するために進行中です。
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年の間に、いくつかの会議は、ネットワーク事業者とプロトコルの開発者の間の直接対話を開始するために様々なイベント（NANOG - 2001年5月22日、RIPE-40、IETF-52 2001年12月2001年10月、LISA-XV 2001年12月）で組織されています。これらの会合の間に、いくつかの演算子は、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.
インターネットアーキテクチャ委員会（IAB）は、2002年6月6日スルー6月4日、ネットワーク管理上の招待ワークショップを開催しました。ワークショップの目標は、重要なダイアログがネットワークオペレータとプロトコルの開発者の間で開始し、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.
ワークショップは、（a）は一緒に彼らの長所と短所とネットワーク管理のための関連技術のリストを識別し、（b）は、最も重要な事業者のニーズを特定するためには、2つのブレイクアウトセッションを開始します。これらの議論の結果は、以下の議論の中で第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関連書類の大半については、プロトコルのバージョンは関係ありません。他のステートメント（セキュリティに関係特に）はSNMPv3の環境に、より適用可能であるにもかかわらず、いくつかのステートメントは、SNMPv1の/ SNMPv2cの環境により適用されます。
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,
リストは完全であることをしようとしません。フォーカスは（、HTTP / HTML、XML CLI）IETF特定の技術（SNMP、COPS-PR、PCIM）と広く使われている独自の技術に与えられました。例えばTL1、CORBA、CMIP / GDMO、のような他の一般的な管理技術（の存在
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）などの特定の問題領域のための具体的な管理技術は、（認めたが、議論の焦点ではないありました。
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年代後半に作成され、以来、広く実装され、インターネットで展開されてきました。そこ実装上および運用経験がたくさんある、と技術の特徴は、このようによく理解されています。
+ 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は、広く基本的な監視のために配布されます。このようなIF-MIB [RFC2863]などのいくつかのコアMIBモジュールは、ほとんどのネットワークデバイスに実装されています。
+ 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 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トランザクション・モデルとプロトコルの制約は、MIBを実装することをより複雑にします。 MIBの論理演算は、実装動作が完了するまで、または失敗が決定されるまでの状態を維持しなければならないSNMP相互作用のシーケンスに回すことができます。障害が発生した場合には、堅牢な実装では、一貫性のある状態に戻すデバイスを巻くだけにスマートでなければなりません。
- 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.
SNMP管理技術に関するより詳細な議論は、第4節で見つけることができます。
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]はシグナリングプロトコルのQoS上ポリシー制御をサポートするために、1990年代後半に定義されました。 COPS-PRの拡張子は、クレビスのプロビジョニングポリシー情報を可能にします。
+ COPS-PR allows high-level transactions for single devices, including deleting one configuration and replacing it with another.
+ 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.
+マネージャとデバイスの両方の状態が完全に常時互いに同期しています。通信に障害がある場合は、ネットワークが正常に再び動作しているときの状態を再同期され、デバイスのネットワーク設定は有効です。
+ 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クライアントタイプにマップする。）それは容易に共有状態を維持することができるように、この単一マネージャの仮定は、プロトコルを簡略化します。
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と同様の複雑さを有します。
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].
共通情報モデル（CIM）[CIM]の開発は1990年代半ばDMTFで始まりました。開発は、コアクラスは、最初に定義し、後で特定のサービスをモデル化するために拡張されるトップダウンアプローチに従います。 DMTFとIETFが共同PCIM [RFC3060]として知られ、CIMのポリシー拡張を開発しました。
+ 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.
+ CIM技術は、一般的にSNMPまたはCOPS-PRに利用できない、データオブジェクトのメソッドを完全にサポートしてオブジェクト指向の原則に従います。
+ 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の管理のクエリ言語（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.
+ CIMにおける情報モデリング作業は、グラフィカル表記として統一モデリング言語（UML）を使用して行われます。これは、彼らの教育の一環として、UMLを使用することを学んだコンピュータサイエンスのバックグラウンドを持つ人々を魅了しています。
o The main practical use of CIM schemas today seems to be the definition of data structures used internally by management systems.
CIMスキーマの主な実用oを、今日は管理システムによって内部的に使用されるデータ構造の定義のようです。
- The CIM schemas have rather complex interrelationships that must be understood before one can reasonably extend the set of existing schemas.
- CIMスキーマは1つが合理的に、既存のスキーマのセットを拡張することができる前に理解しなければならないかなり複雑な相互関係を持っています。
- 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スキーマは、管理システムとネットワークデバイス間のインターフェースとして限られた実装と使用方法を見てきました。
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）を持っています。 SSHプロトコルはTELNETに関連するセキュリティ問題に対処するために勢いを増している間にCLIへのネットワークアクセスは、伝統的に、TELNETプロトコルを介してきました。以下では、実際にコマンドを解析して実行するだけのCLIが考慮されます。 （メニュー指向のインターフェイスは、ここでは、自動化のための難しいため、関係ありません。）
+ Command line interfaces are generally task-oriented, which make them easier to use for human operators.
+コマンドラインインターフェイスは、人間のオペレータのために使用しやすいようれ、一般的にタスク指向です。
+ 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.
- コマンド・ライン・インターフェースはプロプライエタリであるので、装置の不均一な集合で環境でプロセスを自動化するために効率的に使用することができません。
- The access control facilities, if present at all, are often ad-hoc and sometimes insufficient.
- アクセス制御機能、現時点ではすべての場合には、多くの場合、アドホックおよび不十分な場合があります。
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.
多くのデバイスは、デバイスを設定するには、ステータス情報を取得するために使用することができます内蔵Webサーバーを持っています。一般的に使用されるプロトコルはHTTPである、との情報がHTMLでレンダリングされます。一部のデバイスでは、クライアントはJavaやJavaスクリプトなどの設備を持っていることを期待しています。
+ Embedded web servers for configuration are end-user friendly and solution oriented.
+コンフィギュレーションのための内蔵Webサーバーは、エンドユーザーフレンドリーとソリューション指向です。
+ Embedded web servers are suitable for configuring consumer devices by inexperienced users.
+内蔵Webサーバーでは、経験の浅いユーザーによる消費者向けデバイスを構成するために適しています。
+ Web server configuration is widely deployed, especially in boxes targeted to the consumer market.
+ Webサーバーの構成は広く、特に消費者市場をターゲットボックスに、展開されています。
+ There is no need for specialized applications to use embedded web servers since web browsers are commonly available today.
+ Webブラウザは、今日一般に入手可能であるため、組み込みWebサーバを使用するための特殊なアプリケーションのための必要はありません。
- Embedded web servers are management application hostile. Parsing HTML pages to extract useful information is extremely painful.
- 内蔵Webサーバーは、管理アプリケーションの敵対的です。有用な情報を抽出するために、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.
- コンフィギュレーションのリプレイは、同じデバイスの異なるバージョンがユーザと対話するさまざまな方法を使用しているため、Webページは、いくつかのアクティブコンテンツに依存しているかのどちらかので、しばしば問題です。
- The access control facilities, if present at all, are often ad-hoc and sometimes insufficient.
- アクセス制御機能、現時点ではすべての場合には、多くの場合、アドホックおよび不十分な場合があります。
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が本当に有用なものとするために設計されなければなりません。
- 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スキーマの欠如があります。
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.
前記構成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.構成をダンプし、復元するためのメカニズムは、オペレータによって必要な基本操作です。デバイスへ/からのコンフィギュレーションを引っ張り、プッシュするための基準が望ましいです。
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のシーケンスを生成することにより、コマンドまたはデバイスにプッシュされ、完全なコンフィギュレーションファイルされています。様々な事業者が使用したモデルは、おそらく非常に類似しているが、ネットワーク構成のための共通のデータベーススキーマは、ありません。文書を抽出し、これらのネットワーク全体の設定データベーススキーマの共通部分を標準化することが望ましいです。
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.
CLIへのアクセス制御は通常コマンド（タスク）配向である14 SNMPアクセス制御は、データ指向です。管理機能に応じて、時々データ指向またはタスク指向のアクセス制御をより理にかなっています。このように、データ指向およびタスク指向アクセス制御の両方をサポートするための要件です。
So far, there is no published document that clearly defines the requirements of the operators.
これまでのところ、はっきりとオペレータの要件を定義一切公表された文書はありません。
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?
MIB設計時に想定していなかったクエリ操作7.パフォーマンスの低下。特定の宛先アドレスに使用されている発信インターフェイス：典型的な例は次のクエリのですか？
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モジュールは、多くの場合、彼らはオペレーターが見ていない変数がたくさん含まれているという意味で過剰設計されています。
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トラップは通常、トラップが実際に何を意味するのかを理解するために、後続のGET操作を必要としています。
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.
構造化タイプと様々なRPCの相互作用（方法）の14欠如が設計し、実装するためのMIBモジュールははるかに複雑にします。
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コマンドすべてのSNMP MIB同等のモジュールを実装するベンダーにとって阻害要因があります。これは、サードパーティの標準のSNMPソリューションの価値を損ないます。
20. Rapid feature development is in general not compatible with the standardization of the configuration interface.
20.急速機能の開発は、一般に、コンフィギュレーション・インタフェースの標準と互換性がありません。
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.プログラム・インタフェースは、それらがとにかくのCLIに復帰しなければならないので、それ以外の場合は、ネットワークオペレータによって使用されない完全なカバレッジを提供しなければなりません。
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にする必要があります。
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.タスク指向のビューとアクセス制御ルールを定義することが可能でなければなりません。
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.デバイスは最小限中断の設定デルタをサポートすることができなければなりません。
33. A solution must support function call semantics (methods) to implement functions, such as a longest prefix match on a routing table.
33.解決策は、ルーティングテーブル上の最長プレフィックスマッチとして、機能を実現するために、関数呼び出しのセマンティクス（メソッド）をサポートしなければなりません。
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ベースのデバイスの構成および管理技術の開発と標準化にリソースを費やす必要があることを、プロトコルの開発者からの事業者からの強いコンセンサスとラフコンセンサスと、お勧めします交換プロトコルなど）。
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ベースの方法の開発にリソースを費やすべきではないと、プロトコルの開発者から事業者からの強いコンセンサスとラフコンセンサスで、推奨しています。
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のPIBを気にしないという荒いコンセンサスを持っていました。
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ネットワーク管理ワークショップの報告です。このように、それはインターネットのための任意の直接のセキュリティ上の影響はありません。
The editor would like to thank Dave Durham, Simon Leinen and John Schnizlein for taking detailed minutes during the workshop.
エディタは、ワークショップで詳細な分を取るためデイブダーラム、サイモンLeinenとジョンSchnizleinに感謝したいと思います。
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.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[CIM] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.
[CIM]分散管理タスクフォース、 "共通情報モデル（CIM）仕様バージョン2.2"、DSP 0004、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つの仕"、RFC 3060、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.、ラジャン、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、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.スミスは、「使用をCOPSポリシープロビジョニング（COPS-PR）」、RFC 3084、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.0"、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"、RFC 2863、2000年6月。
[XSD] David, D., "XML Schema Part 0: Primer", W3C Recommendation, May 2001.
[XSD]デビッド、D.、 "XMLスキーマパート0：入門"、W3C勧告、2001年5月。
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
アトキンソンエクストリームネットワークスのロブAusteinとInterNetShareアンディBiermanシスコシステムズのスティーブBellovin氏AT＆TランディブッシュAT＆TレスリーDaigle氏ベリサインデビッド・ダーラムインテルビジェイ・ギルウェスHardakerネットワークアソシエイツ研究所エド・カーンサイモンLeinenカリフォルニアのスイッチケン・リンダール大学バークレー校のDavidパーテインエリクソンアンドリューPartan UUNET /ベリオ蘭/オスナブリュックジョンSchnizleinシスコシステムズのトウェンテランディPresuhn BMCソフトウェアユルゲンSchoenwaelder大学のマイク・セントジョンズRuedigerヴォルクドイツテレコムスティーブWaldbusserマーガレットワッセルマンWinDriverのグレン・ウォーターズノーテルネットワークスバートWijnenルーセントのMFNバーン・パクソンICIR愛子PRAS Univeristy
Author's Address
著者のアドレス
Comments should be submitted to the <nm-ws@ops.ietf.org> mailing list.
コメントは、<nm-ws@ops.ietf.org>メーリングリストに提出する必要があります。
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 421 200 3587 Eメール：j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。