[要約] RFC 3535は、2002年のIABネットワーク管理ワークショップの概要を提供しています。このRFCの目的は、ネットワーク管理に関する重要な問題と課題を議論し、将来のネットワーク管理の方向性を示すことです。
Network Working Group J. Schoenwaelder
Request for Comments: 3535 International University Bremen
Category: Informational May 2003
Overview of the 2002 IAB Network Management Workshop
2002年のIABネットワーク管理ワークショップの概要
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.
Copyright（c）The Internet Society（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）が開催したワークショップの概要を提供します。ワークショップは、2002年6月4日から6月4日まで、米国バージニア州レストンのCNRIが主催しました。ワークショップの目標は、ネットワークオペレーターとプロトコル開発者の間で開始された重要なダイアログを継続し、IETFが将来のワークに焦点を当てることでした。ネットワーク管理。このレポートは、議論を要約し、インターネットエンジニアリングタスクフォース（IETF）コミュニティに対する結論と推奨事項をリストします。
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年代後半に作成されました。初期バージョン（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 分散管理タスクフォース（DMTF）によって開発された共通情報モデル（CIM）[CIM]は、DMTFと協力して拡張され、高レベルのポリシーをルールセット（PCIM）[RFC3060]として説明しています。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).
o 一般的なオープンポリシーサービス（COPS）[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年には、ネットワークオペレーターとプロトコル開発者の直接的な対話を開始するために、さまざまなイベント（2001年5月NANOG-22、2001年10月40日、2001年12月52日LISA-XV）でいくつかの会議が開催されました。これらの会議中、いくつかのオペレーターは、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.
2002年6月4日から6月4日までのインターネットアーキテクチャ委員会（IAB）は、ネットワーク管理に関する招待ワークショップを開催しました。ワークショップの目標は、ネットワークオペレーターとプロトコル開発者の間で開始された重要なダイアログを継続し、IETFがネットワーク管理に関する将来の作業に焦点を当てることでした。
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関連のステートメントの大部分については、プロトコルバージョンは無関係です。それにもかかわらず、いくつかのステートメントはSNMPV1/SNMPV2C環境により適用可能ですが、他のステートメント（特にセキュリティに関係するもの）はSNMPV3環境により適用可能です。
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, TMN) or specific management technologies for specific problem domains (such as RADIUS, DHCP, BGP, OSPF) were acknowledged, but were not the focus of discussion.
リストは完了しようとはしません。IETF固有のテクノロジー（SNMP、COPS-PR、PCIM）および広く使用されている独自の技術（CLI、HTTP/HTML、XML）に焦点が当てられました。他のジェネリック管理技術（TL1、CORBA、CMIP/GDMO、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トランザクションモデルとプロトコルの制約により、コマンドラインインターフェイスインタープレーターのコマンドの実装と比較して、MIBSを実装する方が複雑になります。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は、簡単な取得と構成の再生をサポートしません。問題の一部は、構成オブジェクトを識別するのが容易ではないことです。問題のもう1つの部分は、命名システムが非常に具体的であり、物理的なデバイスの再構成が行われる可能性があることです。したがって、以前の構成を再生する機能を破ることができます。
- 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は、1つの構成を削除したり、別の構成に置き換えるなど、単一デバイスの高レベルトランザクションを許可します。
+ 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-PRS非重複インスタンス名空間は通常、他のマネージャーが特定の構成を破損できないことを保証します。特定のインスタンス名空間のすべてのトランザクションは、注文内で実行する必要があります。
+ 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 Client-Typeにマッピングします。）この単一のマネージャーの仮定は、共有状態を容易にすることを容易にするため、プロトコルを簡素化します。
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].
Common Information Model（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にはこのような一般的な形式は存在しません。もちろん、エンコードされた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.
+ CIMの情報モデリング作業は、グラフィカルな表記としてUnified Modeling Language（UML）を使用して行われます。これは、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スキーマの主な実際の使用は、管理システムが内部で使用するデータ構造の定義であると思われます。
- The CIM schemas have rather complex interrelationships that must be understood before one can reasonably extend the set of existing schemas.
- CIMスキーマには、既存のスキーマのセットを合理的に拡張する前に理解する必要があるかなり複雑な相互関係があります。
- 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）があります。CLIへのネットワークアクセスは伝統的にTelnetプロトコルを介して行われてきましたが、SSHプロトコルは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.
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. 構成をダンプして復元するメカニズムは、オペレーターが必要とする原始的な操作です。デバイスからの構成をプルしてプッシュするための標準が望ましいです。
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. DIFFなどのテキスト処理ツールや、RCやCVなどのバージョン管理ツールを使用して構成を処理できることが非常に望ましいことです。これは、デバイスがアクセス制御リストなどのデータを任意に並べ替えるべきではないことを意味します。
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.
これまでのところ、オペレーターの要件を明確に定義する公開ドキュメントはありません。
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モジュールは、オペレーターが見ていない多くの変数が含まれているという意味で、しばしば過剰に設計されています。
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.
14. 構造化されたタイプの欠如とさまざまなRPC相互作用（方法）により、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. テキスト構成ファイルは、国際的な文字を含めることができるはずです。人間の読み取り可能な文字列は、最もバッドの少ない国際化されたキャラクターセットとエンコードを利用する必要があります。プロトコル要素は、鈍感な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. 既存のキーおよび資格管理インフラストラクチャとうまく統合する安全なトランスポート、認証、ID、およびアクセス制御が必要です。
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は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を気にしないという大まかなコンセンサスを持っていました。
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.
編集者は、ワークショップ中に詳細な議事録を取ってくれたDave Durham、Simon Leinen、John 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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[CIM] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.
[CIM]分散管理タスクフォース、「Common Information Model（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] Moore、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。
[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] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。ポリシープロビジョニング（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] Bray、T.、Paoli、J。、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（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、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[XSD] David, D., "XML Schema Part 0: Primer", W3C Recommendation, May 2001.
[XSD] David、D。、「XML Schema Part 0：Primer」、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
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
Juergen Schoenwaelder International University Bremen P.O.ボックス750 561 28725ブレーメンドイツ
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。