[要約] RFC 3139は、IPベースのネットワークの設定管理に関する要件を定義しています。このRFCの目的は、ネットワークの設定管理の重要性を強調し、効果的な設定管理のためのガイドラインを提供することです。
Network Working Group L. Sanchez
Request for Comments: 3139 Megisto
Category: Informational K. McCloghrie
Cisco
J. Saperia
JDS Consultant
June 2001
Requirements for Configuration Management of IP-based Networks
IPベースのネットワークの構成管理の要件
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks.
このメモは、ネットワークを構成するためのさまざまなアプローチについて説明し、IPベースのネットワークの構成管理要件のセットを識別します。
Table of Contents
目次
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation, Scope and Goals of this document . . . . . . . 2
1.2 Requirements Terminology . . . . . . . . . . . . . . . . . 3
1.3 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Definition of Technical Terms. . . . . . . . . . . . . . . 3
2.0 Statement of the Problem . . . . . . . . . . . . . . . . . . 4
3.0 Requirements for an IP-based Configuration Management System . 7
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 11
A number of IETF working groups have introduced new technologies which offer integrated and differentiated services. To support these new technologies, working group members found that they had new requirements for configuration of these technologies. One of these new requirements was for the provisioning (configuration) of behavior at the network level.
多くのIETFワーキンググループが、統合および差別化されたサービスを提供する新しいテクノロジーを導入しています。これらの新しいテクノロジーをサポートするために、ワーキンググループのメンバーは、これらのテクノロジーの構成に関する新しい要件があることを発見しました。これらの新しい要件の1つは、ネットワークレベルでの動作のプロビジョニング（構成）でした。
An example of this type of configuration would be instructing all routers in a network to provide 'gold' service to a particular set of customers. Depending on the specific network equipment and definition of 'gold' service, this configuration request might translate to different configuration parameters on different vendors equipment and many individual configuration commands at the router. This higher level of configuration management has come to commonly be known as policy based management.
このタイプの構成の例は、ネットワーク内のすべてのルーターに特定の顧客に「ゴールド」サービスを提供するように指示することです。特定のネットワーク機器と「ゴールド」サービスの定義に応じて、この構成要求は、さまざまなベンダー機器の異なる構成パラメーターとルーターの多くの個別の構成コマンドに変換される場合があります。このより高いレベルの構成管理は、一般的にポリシーベースの管理として知られるようになりました。
Working groups associated with these new technologies believed that the existing SNMP based management framework, while adequate for fault, configuration management at the individual instance (e.g., interface) level, performance and other management functions commonly associated with it, was not able to meet these new needs. As a result they began working on new solutions and approaches.
これらの新しいテクノロジーに関連するワーキンググループは、既存のSNMPベースの管理フレームワークは、個々のインスタンス（インターフェイスなど）レベル、パフォーマンス、および一般的に関連するその他の管理機能での障害、構成管理に適していますが、これらを満たすことができないと考えていました。新しいニーズ。その結果、彼らは新しいソリューションとアプローチに取り組み始めました。
COPS [COPS] for RSVP [RSVP] provides routers with the opportunity to ask their Policy Server for an admit/reject decision for a particular RSVP session. This model allows routers to outsource their resource allocation decisions to some other entity. However, this model does not work with DiffServ [DSARCH] where there is no signalling protocol. Therefore, the policies that affect resource allocation decisions must be provisioned to the routers. It became evident that there was a need for coordinating both RSVP-based and DiffServ-based policies to provide end2end QoS. Working groups began to extend and leverage approaches such as COPS for RSVP to support Diffserv policies. This gave birth to COPS-PR [COPS-PR].
RSVP [RSVP]のCOPS [COPS]は、特定のRSVPセッションの入場/拒否決定をポリシーサーバーに依頼する機会をルーターに提供します。このモデルにより、ルーターはリソース割り当ての決定を他のエンティティに外部委託することができます。ただし、このモデルは、シグナル伝達プロトコルがないDiffServ [DSARCH]では機能しません。したがって、リソース割り当ての決定に影響を与えるポリシーは、ルーターにプロビジョニングする必要があります。END2END Qosを提供するために、RSVPベースとDiffServベースのポリシーの両方を調整する必要があることが明らかになりました。ワーキンググループは、RSVPのCOPなどのアプローチを拡張して活用して、DiffServポリシーをサポートしました。これにより、COPS-PR [COPS-PR]が生まれました。
These extensions caused concern that the IETF was about to develop a set of fragmented solutions which were locally optimized for specific technologies and not well integrated in the existing Internet Management Framework. The concern prompted some of the Area Directors associated with the Operations and Management, Transport and General areas, and some IAB members to organize a two day meeting in mid September 1999. The primary purpose of the meeting was to examine the requirements for configuration management and evaluate the COPS/PIB and SNMP/MIB approaches in light of these requirements.
これらの拡張は、IETFが特定のテクノロジー用にローカルに最適化され、既存のインターネット管理フレームワークに十分に統合されていない一連の断片化されたソリューションを開発しようとしていることに懸念を引き起こしました。この懸念により、運用と管理、輸送、一般的なエリアに関連する地域の取締役の一部、および1999年9月中旬に2日間の会議を開催するIABメンバーの一部は、会議の主な目的は、構成管理の要件を調べることでした。これらの要件に照らして、COPS/PIBおよびSNMP/MIBアプローチを評価します。
At the end of the two day meeting there was no consensus on several issues and as a result a number of 'design teams' were created. This document is the output of the design team chartered with the identification of a global set of configuration management requirements. This document has benefited from feedback received during the Configuration Management BOF that took place on November 11, 1999 during the 46th IETF in Washington DC, USA. The document has also benefited from comments sent to the confmgt@ops.ietf.org mailing list.
2日間の会議の終わりに、いくつかの問題に関するコンセンサスはなく、その結果、多くの「デザインチーム」が作成されました。このドキュメントは、構成管理要件のグローバルセットの識別とチャーターされた設計チームの出力です。このドキュメントは、1999年11月11日に米国ワシントンDCで開催された第46 IETFで行われた構成管理BOFで受け取ったフィードバックの恩恵を受けています。このドキュメントは、confmgt@ops.ietf.orgメーリングリストに送信されたコメントの恩恵も受けています。
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119 [Bra97].
キーワード「必須」、「「必須」、「必須」、「必須」、「そうは思わない」、「そうでない」、「可能性」は、このドキュメントに表示される可能性があります。
The target audience for this document includes system designers, implementers of network configuration and management technology and others interested in gaining a general background understanding of the issues related to configuration management in general, and in the Internet in particular along with associated requirements. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general network management terms and concepts.
このドキュメントのターゲットオーディエンスには、システムデザイナー、ネットワーク構成と管理技術の実装者、その他の構成管理に関連する問題の一般的な背景理解を得ることに関心のある他の人々が含まれます。このドキュメントは、読者がインターネットプロトコル、関連するネットワーキングテクノロジー、および一般的なネットワーク管理の用語と概念に精通していることを前提としています。
Device-Local Configuration
デバイスローカル構成
Configuration data that is specific to a particular network device. This is the finest level of granularity for configuring network devices.
特定のネットワークデバイスに固有の構成データ。これは、ネットワークデバイスを構成するための最高レベルの粒度です。
Network-Wide Configuration
ネットワーク全体の構成
Configuration data that is not specific to any particular network device and from which multiple device-local configurations can be derived. Network-wide configuration provides a level of abstraction above device-local configurations.
特定のネットワークデバイスに固有ではなく、複数のデバイスローカル構成を導出できる構成データ。ネットワーク全体の構成は、デバイスのローカル構成よりも抽象化のレベルを提供します。
Configuration Data Translator
構成データ翻訳者
A function that transforms Configuration Management Data (high-level policies) or Network-wide configuration data (middle-level policies) into device local configurations (low-level policies) based on the generic capabilities of network devices. This function can be performed either by devices themselves or by some intermediate entity.
ネットワークデバイスの一般的な機能に基づいて、構成管理データ（高レベルのポリシー）またはネットワーク全体の構成データ（中レベルのポリシー）をデバイスローカル構成（低レベルポリシー）に変換する関数。この関数は、デバイス自体または一部の中間エンティティによって実行できます。
Configuring large networks is becoming an increasingly difficult task. The problem intensifies as networks increase their size, not only in terms of number of devices, but also with a greater variety of devices, with each device having increasing functionality and complexity. That is, networks are getting more complex in multiple dimensions simultaneously (number of devices, time scales for configuration, etc.) making the task of configuring these more complex.
大規模なネットワークの構成は、ますます困難なタスクになりつつあります。ネットワークがデバイスの数だけでなく、各デバイスが機能性と複雑さを高めることで、より多くのデバイスの点でもサイズを増やすため、問題は強化されます。つまり、ネットワークは、複数の次元で同時に複雑になっています（デバイスの数、構成の時間尺度など）により、これらをより複雑にするタスクが作成されます。
In the past, configuring a network device has been a three step process. The network operator, engineer or entity responsible for the network created a model of the network and its expected behavior. Next, this (model + expected behavior) was formalized and recorded in the form of high-level policies. Finally, these policies were then translated into device-local configurations and provisioned into each network device for enforcement.
過去には、ネットワークデバイスの構成は3段階のプロセスでした。ネットワークを担当するネットワークオペレーター、エンジニア、またはエンティティは、ネットワークのモデルとその予想される動作を作成しました。次に、この（モデルの予想される動作）は、高レベルのポリシーの形で正式化および記録されました。最後に、これらのポリシーはデバイスローカル構成に翻訳され、施行のために各ネットワークデバイスにプロビジョニングされました。
Any high-level policy changes (changes in the network topology and/or its expected behavior) needed to be translated and provisioned to all network devices affected by the change. Figure 1 depicts this model and shows how high-level policies for a network could be translated into four device-local configurations. In this model, network operators or engineers functioned as configuration data translators; they translated the high-level policies to device-local configuration data.
高レベルのポリシーの変更（ネットワークトポロジおよび/またはその予想される動作の変更）は、変更の影響を受けたすべてのネットワークデバイスに翻訳してプロビジョニングする必要がありました。図1はこのモデルを示しており、ネットワークの高レベルのポリシーを4つのデバイスローカル構成にどのように変換できるかを示しています。このモデルでは、ネットワークオペレーターまたはエンジニアが構成データ翻訳者として機能しました。彼らは、高レベルのポリシーをデバイスローカル構成データに翻訳しました。
A configuration data translator could take the topology independent behavior description such as high-level policies (first input source) combine it with topology information (second input source) as well as status/performance/monitoring information (third input source) to derive device-local configurations. Note that there could be several configuration data translators operating in tandem on a set of devices. However, there could be only one configuration data translator operating at a particular device at any given instance.
構成データ翻訳者は、高レベルのポリシー（最初の入力ソース）などのトポロジの独立した動作の説明を取得できます。トポロジー情報（2番目の入力ソース）とステータス/パフォーマンス/監視情報（3番目の入力ソース）を組み合わせてデバイスを導き出します。ローカル構成。デバイスのセットでタンデムで動作する構成データ翻訳者がいくつかある可能性があることに注意してください。ただし、特定のインスタンスで特定のデバイスで動作する構成データ翻訳者は1つだけです。
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Configuration <---- Status/performance
Information Data Translator(s) Information
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 1. Current model for configuring network devices.
図1.ネットワークデバイスを構成するための現在のモデル。
Historically, network operators and engineers used protocols and mechanisms such as SNMP and CLI applications to provision or configure network devices. In their current versions, these mechanisms have proven to be difficult to use because of their low-level of granularity and their device-specific nature. This problem is worse when provisioning multiple network devices requiring large amounts of configuration data.
歴史的に、ネットワークオペレーターとエンジニアは、SNMPやCLIアプリケーションなどのプロトコルとメカニズムを使用して、ネットワークデバイスを提供または構成しました。現在のバージョンでは、これらのメカニズムは、低レベルの粒度とデバイス固有の性質のために使用が困難であることが証明されています。この問題は、大量の構成データを必要とする複数のネットワークデバイスをプロビジョニングする場合に悪化します。
It is evident that network administrators and existing configuration management software can not keep up with the growth in complexity of networks and that an efficient, integrated configuration management solution is needed. Several IETF Working Groups working on this problem converged into adding a layer of abstraction to the traditional configuration management process described in figure 1. Figure 2 depicts this process after the layer of abstraction is added. As in the previous figure, first the network operator, engineer or entity responsible for the network creates a model of the network and its expected behavior. This is formalized and recorded in the form of high-level policies.
ネットワーク管理者と既存の構成管理ソフトウェアは、ネットワークの複雑さの成長に追いつくことができず、効率的で統合された構成管理ソリューションが必要であることは明らかです。この問題に取り組んでいるいくつかのIETFワーキンググループは、図1に説明する従来の構成管理プロセスに抽象化のレイヤーを追加することに収束しました。図2は、抽象化の層が追加された後にこのプロセスを示しています。前の図と同様に、最初にネットワークオペレーター、エンジニア、またはネットワークの責任者がネットワークのモデルとその予想される動作を作成します。これは正式にされ、高レベルのポリシーの形で記録されています。
These policies are combined with topology information as well as status/performance information to generate network-wide configuration data. These middle level-policies are simpler to manage and represent behaviors shared by multiple network devices.
これらのポリシーは、トポロジ情報とステータス/パフォーマンス情報と組み合わされて、ネットワーク全体の構成データを生成します。これらのミドルレベルポリシーは、複数のネットワークデバイスが共有する動作を管理および表す方が簡単です。
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Network-Wide <---- Status/performance
Information Configuration Information
Data
|
|
|
|
V
Configuration
Data Translator(s)
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 2. Proposed model for configuring network devices.
図2.ネットワークデバイスを構成するための提案されたモデル。
Device local configurations are generated by automated configuration data translators and are supplied to each network device for enforcement. Note how this model only describes the function of the configuration data translators and it does not dictate its functional location. This is to say that translators may reside outside of the devices (as it was the case in figure 1 since they were humans) or may be possibly collocated with each device.
デバイスローカル構成は、自動構成データ翻訳者によって生成され、施行のために各ネットワークデバイスに提供されます。このモデルは、構成データ翻訳者の関数のみをどのように記述するかに注意してください、そして、その機能位置を決定しません。これは、翻訳者がデバイスの外側に存在する可能性があると言うことです（人間であるため、図1の場合のように）、または各デバイスとcollocedされる可能性があります。
As in the previous model, any high-level policy changes (changes in the network topology and/or its expected behavior) needs to be propagated to all network devices affected by the change. However, in the configuration model depicted in figure 2 network operators and engineers can specify the behavior of the network in a simplified manner reducing the amount of device specific knowledge needed.
前のモデルと同様に、高レベルのポリシーの変更（ネットワークトポロジおよび/またはその予想される動作の変更）は、変更の影響を受けたすべてのネットワークデバイスに伝播する必要があります。ただし、図2に示す構成モデルでは、ネットワーク演算子とエンジニアは、必要なデバイス固有の知識の量を短縮する単純化された方法でネットワークの動作を指定できます。
One should keep in mind that in some cases per instance device local configuration is needed in network devices. An integrated solution MUST allow room for this. Also, the introduction of automated configuration data translators assumes that all information needed to make an error free conversion of network-wide configuration data into device-local configuration data is available. In the event that such data is not available the solution MUST detect this and act accordingly.
インスタンスごとにデバイスごとにネットワークデバイスでローカル構成が必要である場合があることに留意する必要があります。統合されたソリューションは、このためのスペースを確保する必要があります。また、自動構成データ翻訳者の導入は、ネットワーク全体の構成データをデバイスローカル構成データにエラーフリー変換するために必要なすべての情報が利用可能であると想定しています。そのようなデータが利用できない場合、ソリューションはこれを検出し、それに応じて行動する必要があります。
All IETF WGs active in this area agrees upon the following requirements for configuration management. An integrated configuration management solution MUST:
この分野でアクティブにアクティブするすべてのIETF WGは、構成管理のための以下の要件に同意します。統合された構成管理ソリューションは、次のことが必要です。
1) provide means by which the behavior of the network can be specified at a level of abstraction (network-wide configuration) higher than a set of configuration information specific to individual devices,
1) ネットワークの動作を、個々のデバイスに固有の一連の構成情報よりも高いレベルの抽象化（ネットワーク全体の構成）で指定できる手段を提供します。
2) be capable of translating network-wide configurations into device-local configuration. The identification of the relevant subset of the network-wide policies to be down-loaded is according to the capabilities of each device,
2) ネットワーク全体の構成をデバイスローカル構成に変換できます。ダウンロードするネットワーク全体のポリシーの関連するサブセットの識別は、各デバイスの機能に従って、
3) be able to interpret device-local configuration, status and monitoring information within the context of network-wide configurations,
3) ネットワーク全体の構成のコンテキスト内で、デバイスローカル構成、ステータス、監視情報を解釈できるようにすることができます。
4) be capable of provisioning (e.g., adding, modifying, deleting, dumping, restoring) complete or partial configuration data to network devices simultaneously or in a synchronized fashion as necessary,
4) プロビジョニング（例：追加、変更、削除、ダンピング、復元）を完全または部分的な構成データに同時にネットワークデバイスまたは必要に応じて同期した方法で、必要に応じて同期して、
4a) be able to provision multiple device-local configurations to support fast switch-overs without the need to down-load potentially large configuration changes to many devices,
4a）多くのデバイスに潜在的に大規模な構成変更をダウンロードする必要なく、高速スイッチオーバーをサポートするために複数のデバイスローカル構成を提供できるようにします。
5) provide means by which network devices can send feedback information (configuration data confirmation, network status and monitoring information, specific events, etc.) to the management system,
5) ネットワークデバイスがフィードバック情報（構成データ確認、ネットワークステータスと監視情報、特定のイベントなど）を管理システムに送信できる手段を提供します。
6) be capable of provisioning complete or partial configuration data to network devices dynamically as a result of network specific or network-wide events,
6) ネットワーク固有またはネットワーク全体のイベントの結果として、完全または部分的な構成データをネットワークデバイスに動的にプロビジョニングすることができます。
7) provide efficient and reliable means compared to current versions of today's mechanisms (CLI, SNMP) to provision large amounts of configuration data,
7) 今日のメカニズム（CLI、SNMP）の現在のバージョンと比較して、効率的で信頼できる手段を提供して、大量の構成データを提供します。
8) provide secure means to provision configuration data. The system must provide support for access control, authentication, integrity-checking, replay- protection and/or privacy security services. The minimum level of granularity for access control and authentication is host based. The system SHOULD support user/role based access control and authentication for users in different roles with different access privileges,
8) 構成データを提供するための安全な手段を提供します。システムは、アクセス制御、認証、整合性チェック、リプレイ保護、および/またはプライバシーセキュリティサービスのサポートを提供する必要があります。アクセス制御と認証のための最小レベルの粒度はホストベースです。システムは、さまざまなアクセス権限を持つさまざまな役割のユーザーのユーザー/ロールベースのアクセス制御と認証をサポートする必要があります。
9) provide expiration time and effective time capabilities to configuration data. It is required that some configuration data items be set to expire, and other items be set to never expire,
9) 有効期限と効果的な時間機能を構成データに提供します。一部の構成データアイテムを期限切れに設定し、他のアイテムを期限切れにするように設定する必要があります。
10) provide error detection (including data-specific errors) and failure recovery mechanisms (including prevention of inappropriately partial configurations when needed) for the provisioning of configuration data,
10）構成データのプロビジョニングにエラー検出（データ固有のエラーを含む）および障害回復メカニズム（必要に応じて不適切に部分的な構成の防止を含む）を提供する、
11) eliminate the potential for mis-configuration occurring through concurrent shared write access to the device's configuration data,
11）デバイスの構成データへの共有の共有書面アクセスを介して発生する誤って構成の可能性を排除します。
12) provide facilities (with host and user-based authentication granularity) to help in tracing back configuration changes,
12）施設（ホストとユーザーベースの認証の粒度を備えています）を提供して、構成の構成の変更をトレースするのに役立ちます。
13) allow for the use of redundant components, both network elements and configuration application platforms, and for the configuration of redundant network elements.
13）ネットワーク要素と構成アプリケーションプラットフォームの両方の冗長コンポーネントを使用し、冗長ネットワーク要素の構成を可能にします。
14) be flexible and extensible to accommodate future needs. Configuration management data models are not fixed for all time and are subject to evolution like any other management data model. It is therefore necessary to anticipate that changes will be needed, but it is not possible to anticipate what those changes might be. Such changes could be to the configuration data model, supporting message types, data types, etc., and to provide mechanisms that can deal with these changes effectively without causing inter-operability problems or having to replace/update large amounts of fielded networking devices,
14）将来のニーズに対応するために、柔軟で拡張可能である。構成管理データモデルは常に固定されておらず、他の管理データモデルと同様に進化の対象となります。したがって、変更が必要であることを予測する必要がありますが、それらの変更が何であるかを予測することはできません。このような変更は、構成データモデル、メッセージタイプ、データ型などをサポートし、操作性間の問題を引き起こすか、大量のフィールドネットワーキングデバイスを交換/更新する必要なく、これらの変更を効果的に処理できるメカニズムを提供する可能性があります。
15) leverage knowledge of the existing SNMP management infrastructure. The system MUST leverage knowledge of and experience with MIBs and SMI.
15）既存のSNMP管理インフラストラクチャの知識を活用します。システムは、MIBSとSMIの知識と経験を活用する必要があります。
Security Considerations
セキュリティに関する考慮事項
This document reflects the current requirements that the IETF believes configuration management systems MUST have to properly support IP-based networks. The authors believe that a configuration management system MUST provide mechanisms by which one can ascertain the integrity and authenticity of the configuration data at all times. In some cases the privacy of the data is important therefore configuration management system MUST provide facilities to support this services as required not only while the data is stored but also during provisioning or reception. Requirements eight and twelve capture the required security services.
このドキュメントは、IETFが構成管理システムがIPベースのネットワークを適切にサポートする必要があると考えている現在の要件を反映しています。著者は、構成管理システムが常に構成データの完全性と信頼性を確認できるメカニズムを提供しなければならないと考えています。場合によっては、データのプライバシーが重要であるため、構成管理システムは、データが保存されている間だけでなく、プロビジョニングまたは受信中にも必要に応じてこのサービスをサポートする機能を提供する必要があります。要件8と12は、必要なセキュリティサービスをキャプチャします。
Acknowledgments
謝辞
The authors thank Juergen Schoenwaelder for his contributions to this document. The authors also thank Walter Weiss and Andrew Smith for providing feedback to early versions of this document. Finally, the authors thank the IESG for motivating and supporting this work.
著者は、この文書への貢献についてJuergen Schoenwaelderに感謝します。著者はまた、この文書の初期バージョンにフィードバックを提供してくれたWalter WeissとAndrew Smithに感謝します。最後に、著者は、この作業をやる気とサポートしてくれたIESGに感謝します。
References
参考文献
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, August 1999.
[警官]ボイル、J。、コーエン、R。、ダーラム、D。、ヘルツォグ、S。、ラジャン、R。、A。
[RSVP] Braden, R., Editor, et al., "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Editor、et al。、「リソース予約プロトコル（RSVP）バージョン1-機能仕様」、RFC 2205、1997年9月。
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, June 1999.
[COPS-RSVP] Boyle、J.、Cohen、R.、Durham、D.、Herzog、S.、Rajan、R.、A。Sastry、「RSVPのCOPS使用」、RFC 2749、1999年6月。
[COPS-PROV] 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.
[Cops-Prov] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。and A. Smith」ポリシープロビジョニングのためのCOPS使用（COPS-PR） "、RFC 3084、2001年3月。
Authors' Addresses
著者のアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Keith McCloghrie Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Luis A. Sanchez Megisto Systems 20251 Century Boulevard Germantown, MD 02138 USA
Luis A. Sanchez Megisto Systems 20251 Century Boulevard Germantown、MD 02138 USA
Phone: +1 (301) 444-1747
EMail: lsanchez@megisto.com
Jon Saperia JDS Consulting, Inc. 174 Chapman Street Watertown, MA 02472 USA
Jon Saperia JDS Consulting、Inc。174 Chapman Street Watertown、MA 02472 USA
Phone: +1 (617) 744-1079
EMail: saperia@jdscons.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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 assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。