Network Working Group K. Chan
Request for Comments: 3084 J. Seligson
Category: Standards Track Nortel Networks
D. Durham
Intel
S. Gai
K. McCloghrie
Cisco
S. Herzog
IPHighway
F. Reichmeyer
PFN
R. Yavatkar
Intel
A. Smith
Allegro Networks
March 2001
COPS Usage for Policy Provisioning (COPS-PR)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned (QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data.
この文書では、ポリシープロビジョニング（COPS-PR）をサポートするための一般的なオープンポリシーサービス（COPS）プロトコルの使用を記載しています。この仕様は、プロビジョニングされているポリシーのタイプ（QOS、セキュリティ、等）とは無関係であるが、プラズマディスプレイパネルとのPEP間でプロビジョニング情報を通信するために使用されるメカニズムと規則に焦点を当てています。この文書に記載されているプロトコルの拡張機能は、ポリシーデータモデルは、通信中についての仮定を行うが、モデル化されたポリシーデータを運ぶメッセージフォーマットやオブジェクトを記述しないでください。
Conventions used in this document
この文書で使用されている表記
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC-2119]に記載されているように解釈されます。
Table of Contents
目次
Glossary........................................................... 3
1. Introduction.................................................... 3
1.1. Why COPS for Provisioning?.................................... 5
1.2. Interaction between the PEP and PDP........................... 5
2. Policy Information Base (PIB)................................... 6
2.1. Rules for Modifying and Extending PIBs........................ 7
2.2. Adding PRCs to, or deprecating from, a PIB.................... 7
2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC....... 8
2.3. COPS Operations Supported for a Provisioning Instance......... 8
3. Message Content................................................. 9
3.1. Request (REQ) PEP -> PDP..................................... 9
3.2. Decision (DEC) PDP -> PEP....................................10
3.3. Report State (RPT) PEP -> PDP................................12
4. COPS-PR Protocol Objects........................................13
4.1. Complete Provisioning Instance Identifier (PRID)..............14
4.2. Prefix PRID (PPRID)...........................................15
4.3. Encoded Provisioning Instance Data (EPD)......................16
4.4. Global Provisioning Error Object (GPERR)......................21
4.5. PRC Class Provisioning Error Object (CPERR)...................22
4.6. Error PRID Object (ErrorPRID).................................23
5. COPS-PR Client-Specific Data Formats............................23
5.1. Named Decision Data...........................................23
5.2. ClientSI Request Data.........................................24
5.3. Policy Provisioning Report Data...............................24
5.3.1. Success and Failure Report-Type Data Format.................24
5.3.2. Accounting Report-Type Data Format..........................25
6. Common Operation................................................26
7. Fault Tolerance.................................................28
8. Security Considerations.........................................29
9. IANA Considerations.............................................29
10. Acknowledgements...............................................30
11. References.....................................................30
12. Authors' Addresses.............................................32
13. Full Copyright Statement.......................................34
Glossary
用語集
PRC Provisioning Class. A type of policy data.
PRI Provisioning Instance. An instance of a PRC.
PIB Policy Information Base. The database of policy
information.
PDP Policy Decision Point. See [RAP].
PEP Policy Enforcement Point. See [RAP].
PRID Provisioning Instance Identifier. Uniquely identifies an
instance of a PRC.
The IETF Resource Allocation Protocol (RAP) WG has defined the COPS (Common Open Policy Service) protocol [COPS] as a scalable protocol that allows policy servers (PDPs) to communicate policy decisions to network devices (PEPs). COPS was designed to support multiple types of policy clients.
IETFリソース割り当てプロトコル（RAP）WGは、ポリシーサーバ（のPDP）は、ネットワークデバイス（のPEP）に政策決定を通信することを可能にする、スケーラブルなプロトコルとしてCOPS（コモンオープンポリシーサービス）プロトコル[COPS]を定義しました。 COPSは、ポリシーのクライアントの複数のタイプをサポートするように設計されました。
COPS is a query/response protocol that supports two common models for policy control: Outsourcing and Configuration.
アウトソーシングと設定：COPSは、ポリシー制御のための2つの一般的なモデルをサポートし、クエリ/応答プロトコルです。
The Outsourcing model addresses the kind of events at the PEP that require an instantaneous policy decision (authorization). In the outsourcing scenario, the PEP delegates responsibility to an external policy server (PDP) to make decisions on its behalf. For example, in COPS Usage for RSVP [COPRSVP] when a RSVP reservation message arrives, the PEP must decide whether to admit or reject the request. It can outsource this decision by sending a specific query to its PDP, waiting for its decision before admitting the outstanding reservation.
アウトソーシングモデルは瞬間的政策決定（承認）を必要とPEPでのイベントの種類に対応しています。外部ポリシーサーバ（PDP）へのアウトソーシングのシナリオでは、PEPの代表者が責任その代表して決定を行います。 RSVP予約メッセージが到着したとき例えば、RSVP用COPSの使用に[COPRSVP]、PEPは要求を認めるか拒否するかを決定する必要があります。それは優秀な予約を入れる前に、その決定を待って、そのPDPに特定のクエリを送信することにより、この決定を外部委託することができます。
The COPS Configuration model (herein described as the Provisioning model), on the other hand, makes no assumptions of such direct 1:1 correlation between PEP events and PDP decisions. The PDP may proactively provision the PEP reacting to external events (such as user input), PEP events, and any combination thereof (N:M correlation). Provisioning may be performed in bulk (e.g., entire router QoS configuration) or in portions (e.g., updating a DiffServ marking filter).
PEPイベントとPDPの決定との間の1の相関関係：（ここでプロビジョニングモデルとして記載）COPS構成モデルは、一方で、そのような直接1の仮定を行いません。 PDPは、積極的に規定PEPは、外部（例えば、ユーザ入力など）イベント、PEPイベント、およびそれらの任意の組み合わせ（：M相関N）に反応することができます。プロビジョニングは、（例えば、フィルタをマーキングDiffServの更新）は、バルクで（例えば、ルータ全体のQoS設定）または部分で行うことができます。
Network resources are often provisioned based on relatively static SLAs (Service Level Agreements) at network boundaries. While the Outsourcing model is dynamically paced by the PEP in real-time, the Provisioning model is paced by the PDP in somewhat flexible timing over a wide range of configurable aspects of the PEP.
ネットワークリソースは、多くの場合、ネットワーク境界で比較的静的なのSLA（サービスレベル契約）に基づいてプロビジョニングされます。アウトソーシングモデルを動的にリアルタイムでPEPによってペースされている間、プロビジョニングモデルは、PEPの設定態様の広い範囲にわたって幾分柔軟なタイミングでPDPによってペーシングされます。
Edge Device Policy Server
+--------------+ +-----------+ +-----------+
| | | | | External |
| | COPS | | | Events |
| +-----+ | REQ() | +-----+ | +---+-------+
| | |----|----------|->| | | |
| | PEP | | | | PDP |<-|---------+
| | |<---|----------|--| | |
| +-----+ | COPS | +-----+ |
| | DEC() | |
+--------------+ +-----------+
Figure 1: COPS Provisioning Model
図1：モデルのプロビジョニングCOPS
In COPS-PR, policy requests describe the PEP and its configurable parameters (rather than an operational event). If a change occurs in these basic parameters, an updated request is sent. Hence, requests are issued quite infrequently. Decisions are not necessarily mapped directly to requests, and are issued mostly when the PDP responds to external events or PDP events (policy/SLA updates).
COPS-PRでは、ポリシー要求はPEPとその設定可能なパラメータ（というよりも操作イベント）が説明しています。変更は、これらの基本的なパラメータで発生した場合は、更新要求が送信されます。したがって、要求は非常にまれにしか発行されています。決定は必ずしも要求に直接マッピングされていない、とPDPは、外部イベントやPDPイベント（ポリシー/ SLAのアップデート）に応答するとき、主に発行されます。
This document describes the use of the COPS protocol [COPS] for support of policy provisioning. This specification is independent of the type of policy being provisioned (QoS, Security, etc.). Rather, it focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The data model assumed in this document is based on the concept of Policy Information Bases (PIBs) that define the policy data. There may be one or more PIBs for given area of policy and different areas of policy may have different sets of PIBs.
この文書では、ポリシーのプロビジョニングをサポートするためのCOPSプロトコル[COPS]の使用を記載しています。この仕様は、（などのQoS、セキュリティ、）プロビジョニングされているポリシーのタイプとは無関係です。むしろ、それは、プラズマディスプレイパネルとのPEP間でプロビジョニング情報を通信するために使用されるメカニズムと規則に焦点を当てています。本書で想定しているデータモデルは、ポリシーデータを定義するポリシー情報ベース（のPIB）の概念に基づいています。 PIBの異なるセットを有することが政策や方針の異なる領域の所定の領域に1つのまたは複数のPIBがあるかもしれません。
In order to support a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP, the client-type specified by the PEP to the PDP is unique for the area of policy being managed. A single client-type for a given area of policy (e.g., QoS) will be used for all PIBs that exist in that area. The client should treat all the COPS-PR client-types it supports as non-overlapping and independent namespaces where instances MUST NOT be shared.
単一PEPのポリシーの非重複領域を制御する複数のPDPを含むモデルをサポートするために、PDPにPEPにより指定されたクライアントタイプが管理されているポリシーの領域に対して一意です。ポリシー（例えば、QoS）の所与の領域のための単一のクライアントタイプは、その領域内に存在する全てのPIBのために使用されるであろう。クライアントは、インスタンスが共有されてはならない非重複および独立した名前空間としてサポートしているすべてのCOPS-PRクライアント・タイプを処理する必要があります。
The examples used in this document are biased toward QoS Policy Provisioning in a Differentiated Services (DiffServ) environment. However, COPS-PR can be used for other types of provisioning policies under the same framework.
この文書で使用されている例は、差別化サービス（DiffServの）環境でのQoSポリシーのプロビジョニングに向かって付勢されています。しかし、COPS-PRは、同じ枠組みの下での政策のプロビジョニング、他のタイプのために使用することができます。
COPS-PR has been designed within a framework that is optimized for efficiently provisioning policies across devices, based on the requirements defined in [RAP]. First, COPS-PR allows for efficient transport of attributes, large atomic transactions of data, and efficient and flexible error reporting. Second, as it has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS. COPS uses reliable TCP transport and, thus, uses a state sharing/synchronization mechanism and exchanges differential updates only. If either the server or client are rebooted (or restarted) the other would know about it quickly. Last, it is defined as a real-time event-driven communications mechanism, never requiring polling between the PEP and PDP.
COPS-PRは、[RAP]で定義された要件に基づいて、効率的にデバイス間でポリシーをプロビジョニングするために最適化された枠組みの中で設計されています。まず、COPS-PRは、属性、データの大アトミックトランザクション、及び効率的で柔軟なエラー報告の効率的な輸送を可能にします。それはCOPSクライアントタイプで識別されるポリシー制御の面積あたりのポリシークライアントとサーバの間の単一の接続を持っているように、第2、それは1つのサーバのみ、任意の時点で特定のポリシーの設定を更新し保証します。 PEPはCOPSを介してPDPに接続されているようなポリシー設定を有効にさえローカルコンソール構成から、ロックされています。 COPSは、信頼性の高いTCPトランスポートを使用し、従って、状態共有/同期機構を使用してのみ、差分更新を交換します。サーバーまたはクライアントが再起動（または再起動）している場合は、他のはすぐにそれについて知っているだろう。最後に、それは、PEPとPDPの間でポーリングを必要としたことがない、リアルタイムイベント駆動型の通信メカニズムとして定義されます。
When a device boots, it opens a COPS connection to its Primary PDP. When the connection is established, the PEP sends information about itself to the PDP in the form of a configuration request. This information includes client specific information (e.g., hardware type, software release, configuration information). During this phase the client may also specify the maximum COPS-PR message size supported.
場合は、デバイスを起動すると、それはそのプライマリPDPへのCOPS接続を開きます。接続が確立されると、PEPは、構成要求の形でPDPに自分自身についての情報を送信します。この情報は、クライアント固有の情報（例えば、ハードウェアタイプ、ソフトウェアリリース、構成情報）を含みます。このフェーズでは、クライアントにも対応し、最大COPS-PRのメッセージサイズを指定することもできます。
In response, the PDP downloads all provisioned policies that are currently relevant to that device. On receiving the provisioned policies, the device maps them into its local QoS mechanisms, and installs them. If conditions change at the PDP such that the PDP detects that changes are required in the provisioned policies currently in effect, then the PDP sends the changes (installs, updates, and/or deletes) in policy to the PEP, and the PEP updates its local configuration appropriately.
応答では、PDPは、現在、そのデバイスに関連するすべてのプロビジョニングポリシーをダウンロードします。プロビジョニングされたポリシーを受信すると、デバイスはそのローカルQoSメカニズムにそれらをマッピングし、それらをインストールします。条件は、PDPの変更が現在有効でプロビジョニングポリシーに必要とされていることを検出し、その後、PDPがPEPにポリシーの変更（インストール、更新、および/または削除）を送信し、及びPEPがを更新するPDPように変更した場合適切ローカル設定。
If, subsequently, the configuration of the device changes (board removed, board added, new software installed, etc.) in ways not covered by policies already known to the PEP, then the PEP asynchronously sends this unsolicited new information to the PDP in an updated configuration request. On receiving this new information, the PDP sends to the PEP any additional provisioned policies now needed by the PEP, or removes those policies that are no longer required.
、その後、すでにPEPに知られているポリシーによってカバーされていない方法で（ボードを外し、ボードが追加され、新しいソフトウェアなど、インストールされた）デバイスの変更の構成は、その後、PEPは非同期的にPDPにこの迷惑新しい情報を送信する場合更新された構成要求。この新しい情報を受信すると、PDPは、PEPになりましPEPが必要とする追加のプロビジョニングポリシーを送信し、または不要になったこれらのポリシーを削除します。
The data carried by COPS-PR is a set of policy data. The protocol assumes a named data structure, known as a Policy Information Base (PIB), to identify the type and purpose of unsolicited policy information that is "pushed" from the PDP to the PEP for provisioning policy or sent to the PDP from the PEP as a notification. The PIB name space is common to both the PEP and the PDP and data instances within this space are unique within the scope of a given Client-Type and Request-State per TCP connection between a PEP and PDP. Note that given a device might implement multiple COPS Client-Types, a unique instance space is to be provided for each separate Client-Type. There is no sharing of instance data across the Client-Types implemented by a PEP, even if the classes being instantiated are of the same type and share the same instance identifier.
COPS-PRによって運ばれたデータは、ポリシーデータのセットです。プロトコルは、ポリシーのプロビジョニングまたはPEPからPDPに送信するためのPEPにPDPから「プッシュ」される迷惑ポリシー情報の種類及び目的を識別するために、ポリシー情報ベース（PIB）として知られているというデータ構造を想定しています通知として。 PIBの名前空間は、この空間内PEPとPDPとデータ・インスタンスの両方に共通であるPEPとPDPの間のTCP接続ごとに与えられたクライアントタイプとリクエストステートの範囲内で一意です。与えられたデバイスが複数のCOPSクライアントタイプを実装するかもしれないことに注意してください、ユニークなインスタンス空間は、それぞれ別々のクライアントタイプのために提供されるべきです。 PEPによって実装クライアントの種類、全体でインスタンスデータのない共有がインスタンス化されているクラスは、同じタイプのものであり、同じインスタンス識別子を共有している場合でもありません。
The PIB can be described as a conceptual tree namespace where the branches of the tree represent structures of data or Provisioning Classes (PRCs), while the leaves represent various instantiations of Provisioning Instances (PRIs). There may be multiple data instances (PRIs) for any given data structure (PRC). For example, if one wanted to install multiple access control filters, the PRC might represent a generic access control filter type and each PRI might represent an individual access control filter to be applied. The tree might be represented as follows:
葉はプロビジョニング・インスタンスの様々なインスタンス（のPRI）を表すながらPIBは、木の枝がデータまたはプロビジョニングクラス（位相応答曲線）の構造を表す概念的なツリー名前空間として説明することができます。任意のデータ構造（PRC）のための複数のデータ・インスタンス（のPRI）があってもよいです。 1は、複数のアクセス制御フィルタをインストールしたい場合たとえば、PRCは、一般的なアクセス制御フィルタの種類を表すかもしれませんし、各PRIは、個々のアクセス制御フィルタが適用されるように表すことができます。次のように木が表現されることがあります。
-------+-------+----------+---PRC--+--PRI
| | | +--PRI
| | |
| | +---PRC-----PRI
| |
| +---PRC--+--PRI
| +--PRI
| +--PRI
| +--PRI
| +--PRI
|
+---PRC---PRI
Figure 2: The PIB Tree
図2：PIBツリー
Instances of the policy classes (PRIs) are each identified by a Provisioning Instance Identifier (PRID). A PRID is a name, carried in a COPS <Named ClientSI> or <Named Decision Data> object, which identifies a particular instance of a class.
ポリシークラス（のPRI）のインスタンスが各プロビジョニングインスタンス識別子（PRID）によって識別されます。 PRIDは、クラスの特定のインスタンスを識別するCOPS <名前ClientSI>または<名前判定データ>オブジェクトで運ば名前、です。
As experience is gained with policy based management, and as new requirements arise, it will be necessary to make changes to PIBs. Changes to an existing PIB can be made in several ways.
経験したようポリシーベースの管理で獲得され、そして新たな要件が生じて、PIBのに変更を加えることが必要であろう。既存のPIBへの変更は、いくつかの方法で行うことができます。
(1) Additional PRCs can be added to a PIB or an existing one deprecated.
（1）追加の位相応答曲線は、PIB又は非推奨既存のものに追加することができます。
(2) Attributes can be added to, or deprecated from, an existing PRC.
（2）属性に追加、または既存のPRCから廃止されることができます。
(3) An existing PRC can be extended or augmented with a new PRC defined in another (perhaps enterprise specific) PIB.
（3）既存のPRCは、拡張または別の（おそらくエンタープライズ特定）PIBで定義された新しいPRCで拡張することができます。
The rules for each of these extension mechanisms is described in this sub-section. All of these mechanisms for modifying a PIB allow for interoperability between PDPs and PEPs even when one party is using a new version of the PIB while the other is using an old version.
これらの拡張機構の各々についての規則はこのサブセクションに記載されています。 PIBを修正するためのこれらのメカニズムのすべては、他の古いバージョンを使用している間に一方の当事者がPIBの新しいバージョンを使用しても、プラズマディスプレイパネルとのPEP間の相互運用性を確保するため。
Note that the SPPI [SPPI] provides the authoritative rules for updating BER encoded PIBs. It is the purpose of the following section to explain how such changes affect senders and receivers of COPS messages.
SPPI [SPPI]はBER符号化されたのPIBを更新するための正式なルールを提供することに留意されたいです。このような変化は、COPSメッセージの送信側と受信側にどのように影響するかを説明するには、以下のセクションの目的です。
A published PIB can be extended with new PRCs by simply revising the document and adding additional PRCs. These additional PRCs are easily identified with new PRIDs under the module's PRID Prefix.
公表されPIBは、単に文書を改訂し、追加のPRCsを追加することによって、新しいのPRCsに拡張することができます。これらの追加のPRCsは簡単に、モジュールのPRIDプレフィックスの下に新しいPRIDsで識別されます。
In the event that a PEP implementing the new PIB is being configured by a PDP implementing the old PIB, the PEP will simply not receive any instances of the new PRC. In the event that the PEP is implementing the old PIB and the PDP the new one, the PEP may receive PRIs for the new PRC. Under such conditions, the PEP MUST return an error to the PDP, and rollback to its previous (good) state.
新しいPIBを実装PEPが古いPIBを実装するPDPによって構成されていることをイベントでは、PEPは、単に新しいPRCのインスタンスを受け取りません。 PEPは、新しいもの、古いPIBとPDPを実装した場合には、PEPは、新しいPRCのためのPRIを受け取ることができます。このような条件下で、PEPは、PDPにエラーを返さなければなりません、その前の（良好な）状態にロールバックします。
Similarly, existing PRCs can be deprecated from a PIB. In this case, the PEP ignores any PRIs sent to it by a PDP implementing the old (non-deprecated) version of the PIB. A PDP implementing the new version of the PIB simply does not send any instances of the deprecated class.
同様に、既存の位相応答曲線は、PIBから廃止されることができます。この場合には、PEPは、PIBの古い（非廃止予定の）バージョンを実装するPDPによってそれに送信された任意のPRIを無視します。 PIBの新しいバージョンを実装するPDPは、単純に廃止予定のクラスのすべてのインスタンスを送信しません。
A PIB can be modified to deprecate existing attributes of a PRC or add new ones.
PIBは、中国の既存の属性を廃止したり、新しいものを追加するように変更することができます。
When deprecating the attributes of a PRC, it must be remembered that, with the COPS-PR protocol, the attributes of the PRC are identified by their order in the sequence rather than an explicit label (or attribute OID). Consequently, an ASN.1 value MUST be sent even for deprecated attributes so that a PDP and PEP implementing different versions of the PIB are inter-operable.
PRCの属性を卑下すると、COPS-PRプロトコルで、PRCの属性は、その配列内の順序ではなく、明示的なラベルによって識別される（またはOID属性）されている、ということを忘れてはなりません。したがって、ASN.1値はPDPとPEPがPIBの異なるバージョンを実装するように廃止予定の属性にも送ら相互動作可能でなければなりません。
For a deprecated attribute, if the PDP is using a BER encoded PIB, the PDP MUST send either an ASN.1 value of the correct type, or it may send an ASN.1 NULL value. A PEP that receives an ASN.1 NULL for an attribute that is not deprecated SHOULD substitute a default value. If it has no default value to substitute it MUST return an error to the PDP.
PDPは、BER符号化PIBを使用している場合、推奨されない属性については、PDPは、いずれかの適切なタイプのASN.1値を送信しなければならない、またはそれはASN.1のNULL値を送信することができます。非推奨されていない属性のASN.1のNULLを受けるPEPはデフォルト値に置き換えてください。それが置換するデフォルト値を持たない場合には、PDPにエラーを返さなければなりません。
When adding new attributes to a PIB, these new attributes must be added in sequence after the existing ones. A PEP that receives a PRI with more attributes than it is expecting MUST ignore the additional attributes and send a warning back to the PDP.
PIBに新しい属性を追加する場合、これらの新しい属性は、既存のものの後の順序で追加する必要があります。追加の属性を無視して、バックPDPに警告を送らなければなりません期待しているよりも多くの属性を持つPRIを受信PEP。
A PEP that receives a PRI with fewer attributes than it is expecting SHOULD assume default values for the missing attributes. It MAY send a warning back to the PDP. If the missing attributes are required and there is no suitable default, the PEP MUST send an error back to the PDP. In all cases the missing attributes are assumed to correspond to the last attributes of the PRC.
不足している属性のデフォルト値を前提とすべきであることが期待されるよりも少ない数の属性を持つPRIを受信PEP。これは、バックPDPに警告を送信することができます。行方不明の属性が必要ともし適切なデフォルトが存在していない場合、PEPは戻ってPDPに誤りを送らなければなりません。すべての場合において不足している属性は、PRCの最後の属性に対応すると仮定されています。
A Provisioning Instance (PRI) typically contains a value for each attribute defined for the PRC of which it is an instance and is identified uniquely, within the scope of a given COPS Client-Type and Request-State on a PEP, by a Provisioning Instance Identifier (PRID). The following COPS operations are supported on a PRI:
プロビジョニング・インスタンス（PRI）は、典型的にプロビジョニングインスタンスによって、PEP上の所与のCOPSクライアントタイプ及び要求ステートの範囲内で、それがインスタンスであり、一意に識別されたPRCのために定義されている各属性の値を含みます識別子（PRID）。次COPS操作がPRIでサポートされています。
o Install - This operation creates or updates a named instance of a PRC. It includes two parameters: a PRID object to name the PRI and an Encoded Provisioning Instance Data (EPD) object with the new/updated values. The PRID value MUST uniquely identify a single PRI (i.e., PRID prefix or PRC values are illegal). Updates to an existing PRI are achieved by simply reinstalling the same PRID with the updated EPD data.
Oインストール - この操作は、PRCの名前付きインスタンスを作成または更新します。 PRIと新規/更新された値でエンコードされたプロビジョニングインスタンスデータ（EPD）のオブジェクトに名前を付けるためにPRIDオブジェクト：それは2つのパラメータを含んでいます。 PRID値が一意に単一のPRIを識別しなければならない（すなわち、PRIDプレフィックスまたはPRC値が不正です）。既存のPRIへの更新は、単に更新EPDデータと同じPRIDを再インストールすることによって達成されます。
o Remove - This operation is used to delete an instance of a PRC. It includes one parameter, a PRID object, which names either the individual PRI to be deleted or a PRID prefix naming one or more complete classes of PRIs. Prefix-based deletion supports efficient bulk policy removal. The removal of an unknown/non-existent PRID SHOULD result in a warning to the PDP (no error).
O削除 - この操作は、PRCのインスタンスを削除するために使用されます。これは、1つの名前のいずれかの個々のPRIを削除するパラメータ、PRIDオブジェクト、またはのPRIの1つまたはそれ以上の完全なクラスを命名PRID接頭辞が含まれています。プレフィックスベースの削除は、効率的なバルクポリシーの削除をサポートしています。未知/非存在PRIDの除去は、PDP（エラーなし）に警告をもたらすはずです。
The COPS protocol provides for different COPS clients to define their own "named", i.e., client-specific, information for various messages. This section describes the messages exchanged between a COPS server (PDP) and COPS Policy Provisioning clients (PEP) that carry client-specific data objects. All the COPS messages used by COPS-PR conform to the message specifications defined in the COPS base protocol [COPS].
COPSプロトコルは、様々なメッセージのために独自の「名前付き」、すなわち、クライアント固有の情報を定義するために異なるCOPSクライアントのために用意されています。このセクションでは、メッセージがCOPSサーバ（PDP）およびクライアント固有のデータオブジェクトを運ぶCOPSポリシープロビジョニングクライアント（PEP）との間でやりとりについて説明します。 COPS-PRによって使用されるすべてのCOPSメッセージはCOPSベースプロトコル[COPS]で定義されたメッセージ仕様に準拠します。
Note: The use of the '*' character represented throughout this document is consistent with the ABNF [RFC2234] and means 0 or more of the following entities.
注意：この文書を通して表現「*」文字の使用はABNF [RFC2234]と一致していると、次のエンティティの0またはそれ以上を意味します。
The REQ message is sent by policy provisioning clients to issue a 'configuration request' to the PDP as specified in the COPS Context Object. The Client Handle associated with the REQ message originated by a provisioning client MUST be unique for that client. The Client Handle is used to identify a specific request state. Thus, one client can potentially open several configuration request states, each uniquely identified by its handle. Different request states are used to isolate similarly named configuration information into non-overlapping contexts (or logically isolated namespaces). Thus, an instance of named information is unique relative to a particular client-type and is unique relative to a particular request state for that client-type, even if the information was similarly identified in other request states (i.e., uses the same PRID). Thus, the Client Handle is also part of the instance identification of the communicated configuration information.
REQメッセージは、COPSのコンテキスト・オブジェクトに指定されているPDPに「コンフィグレーション要求」を発行するポリシープロビジョニングクライアントによって送信されます。プロビジョニングクライアントによって発信REQメッセージに関連付けられたクライアントハンドルは、そのクライアントのためにユニークでなければなりません。クライアントハンドルは、特定の要求の状態を識別するために使用されます。したがって、1つのクライアントは、潜在的にいくつかの構成要求の状態、一意にそのハンドルで識別された各を開くことができます。異なる要求状態は、非重複コンテキスト（または論理的に単離された名前空間）に同様に指定されたコンフィギュレーション情報を単離するために使用されます。したがって、名前付き情報のインスタンスは、特定のクライアントタイプに固有の相対的な情報は、同様に（すなわち、同じPRIDを使用して）他の要求の状態で同定された場合でも、そのクライアントタイプのための特定の要求状態に対して独特です。したがって、クライアントハンドルは、また、連通設定情報のインスタンスIDの一部です。
The configuration request message serves as a request from the PEP to the PDP for provisioning policy data that the PDP may have for the PEP, such as access control lists, etc. This includes policy the PDP may have at the time the REQ is received as well as any future policy data or updates to this data.
構成要求メッセージは、これは、PDPがREQをとして受信される時に有していてもよいポリシーを含むなど、このようなアクセス制御リストとして、PEPのためのPDPが有していてもよいことは、ポリシーデータをプロビジョニングするためのPEPからPDPへの要求として機能しますだけでなく、将来のポリシー・データまたは更新このデータへ。
The configuration request message should include provisioning client information to provide the PDP with client-specific configuration or capability information about the PEP. The information provided by the PEP should include client resources (e.g., queuing capabilities) and default policy configuration (e.g., default role combinations) information as well as incarnation data on existing policy. This information typically does not include all the information previously installed by a PDP but rather should include checksums or shortened references to previously installed information for synchronization purposes. This information from the client assists the server in deciding what types of policy the PEP can install and enforce. The format of the information encapsulated in one or more of the COPS Named ClientSI objects is described in section 5. Note that the configuration request message(s) is generated and sent to the PDP in response to the receipt of a Synchronize State Request (SSQ) message from the PDP. Likewise, an updated configuration request message (using the same Client Handle value as the original request now being updated) may also be generated by the PEP and sent to the PDP at any time due to local modifications of the PEP's internal state. In this way, the PDP will be synchronized with the PEP's relevant internal state at all times.
構成要求メッセージは、PEP約クライアント固有の設定または能力情報をPDPを提供するプロビジョニングクライアントの情報を含むべきです。 PEPによって提供される情報は、クライアントのリソースを含めるべきである（例えば、機能キューイング）と、デフォルトのポリシー設定（例えば、デフォルトの役割の組み合わせ）の情報だけでなく、既存のポリシーの化身データ。この情報は一般的に、以前にPDPによってインストールされたすべての情報が含まれていませんが、むしろ同期目的のために、以前にインストールされた情報にチェックサムまたは短縮の参照を含める必要があります。クライアントからこの情報は、PEPは、インストールして施行することができますどのようなポリシーの種類を決定する際に、サーバーを支援します。 ClientSIオブジェクト名前COPSの一つ以上にカプセル化された情報のフォーマットは、構成要求メッセージ（単数または複数）を同期状態要求（SSQの受信に応答して生成され、PDPに送信されること部5注記に記載されていますPDPからの）メッセージ。同様に、（現在更新されて、元の要求と同じクライアントハンドル値を使用して）更新された設定要求メッセージは、PEPによって生成され、PEPの内部状態の局所変形に起因する任意の時点でPDPに送信することができます。このように、PDPは、すべての回でPEPの関連する内部状態と同期されます。
The policy information supplied by the PDP MUST be consistent with the named decision data defined for the policy provisioning client. The PDP responds to the configuration request with a DEC message containing any available provisioning policy data.
PDPから供給されたポリシー情報は、ポリシープロビジョニングクライアント用に定義された名前の判定データと一致していなければなりません。 PDPは、任意の利用可能なプロビジョニングポリシーデータを含むDECメッセージで設定要求に応答します。
The REQ message has the following format:
REQメッセージの形式は次のとおりです。
<Request> ::= <Common Header>
<Client Handle>
<Context = config request>
*(<Named ClientSI>)
[<Integrity>]
Note that the COPS objects IN-Int, OUT-Int and LPDPDecisions are not included in a COPS-PR Request.
COPSは、IN-のIntオブジェクト、OUT-INTとLPDPDecisionsがCOPS-PR要求に含まれていないことに注意してください。
The DEC message is sent from the PDP to a policy provisioning client in response to the REQ message received from the PEP. The Client Handle MUST be the same Handle that was received in the corresponding REQ message.
DECメッセージはPEPから受信REQメッセージに応答して、クライアントのプロビジョニングポリシーにPDPから送信されます。クライアントハンドルは、対応REQメッセージで受信した同じハンドルでなければなりません。
The DEC message is sent as an immediate response to a configuration request with the solicited message flag set in the COPS message header. Subsequent DEC messages may also be sent at any time after the original DEC message to supply the PEP with additional/updated policy information without the solicited message flag set in the COPS message header (as they are unsolicited decisions).
DECメッセージは、COPSメッセージヘッダ内に設定要請メッセージフラグを構成要求に即座に応答として送信されます。後続のDECメッセージは、（それらが迷惑決定されるような）COPSメッセージヘッダに設定要請メッセージフラグなし追加/更新されたポリシー情報とPEPを供給するために、元のDECメッセージの後、いつでも送信することができます。
Each DEC message may contain multiple decisions. This means a single message can install some policies and delete others. In general a single COPS-PR DEC message MUST contain any required remove decisions first, followed by any required install decisions. This is used to solve a precedence issue, not a timing issue: the remove decision deletes what it specifies, except those items that are installed in the same message.
各DECメッセージは、複数の意思決定が含まれていてもよいです。これは、いくつかのポリシーをインストールして、他の人を削除することができ、単一のメッセージを意味します。一般的には単一COPS-PR DECメッセージは、任意の任意の意思決定をインストールする必要が続き、最初の決定を削除する必要が含まれなければなりません。削除決定が同じメッセージ内に設置されているこれらの項目を除いて、それが指定するものを削除します。これは、優先順位の問題ではなく、タイミングの問題を解決するために使用されます。
The DEC message can also be used by the PDP to command the PEP to open a new Request State or Delete an existing Request-State as identified by the Client-Handle. To accomplish this, COPS-PR defines a new flag for the COPS Decision Flags object. The flag 0x02 is to be used by COPS-PR client-types and is hereafter referred to as the "Request-State" flag. An Install decision (Decision Flags: Command-Code=Install) with the Request-State flag set in the COPS Decision Flags object will cause the PEP to issue a new Request with a new Client Handle or else specify the appropriate error in a COPS Report message. A Remove decision (Decision Flags: Command-Code=Remove) with the Request-State flag set in the COPS Decision Flags object will cause the PEP to send a COPS Delete Request State (DRQ) message for the Request-State identified by the Client Handle in the DEC message. Whenever the Request-State flag is set in the COPS Decision Flags object in the DEC message, no COPS Named Decision Data object can be included in the corresponding decision (as it serves no purpose for this decision flag). Note that only one decision with the Request-State flag can be present per DEC message, and, if present, this MUST be the only decision in that message. As described below, the PEP MUST respond to each and every DEC with a corresponding solicited RPT.
DECメッセージは、新しい要求状態を開いたり、クライアントハンドルによって識別されるように、既存の要求ステートを削除するPEPを指令するPDPで使用することができます。これを実現するために、COPS-PRはFlagsオブジェクトCOPS決定のための新しいフラグを定義します。フラグ0x02のはCOPS-PRクライアント・タイプで使用されるべきであり、以下「要求ステート」フラグと呼ばれています。 （決定フラグ：コマンドコード=インストール）の決定をインストールCOPS決定フラグに設定されたリクエストステートフラグを持つオブジェクトの新しいクライアントハンドルを持つ新しい要求を発行するか、他COPSレポートに適切なエラーを指定するには、PEPが発生しますメッセージ。削除の決定（決定フラグ：コマンドコード=削除）COPS決定フラグに設定されたリクエストステートフラグがオブジェクトには、PEPが要求ステートクライアントによって識別されるための要求状態（DRQ）メッセージを削除COPSを送信するようになりますDECメッセージで処理します。要求状態フラグがDECメッセージ内のオブジェクトCOPS決定フラグに設定されたとき（この判定フラグのための目的を果たしていないように）、判定データオブジェクトという名前のCOPSは、対応する決定に含めることはできません。存在する場合、これはそのメッセージでのみ決定していなければなりません、要求状態フラグを持つ唯一の決定はDECメッセージごとに存在することができることに注意してください。以下に説明するように、PEPは、対応する要請RPTとそれぞれすべての12月に応答しなければなりません。
A COPS-PR DEC message MUST be treated as a single "transaction", i.e., either all the decisions in a DEC message succeed or they all fail. If they fail, the PEP will rollback to its previous good state, which is the last successful DEC transaction, if any. This allows the PDP to delete some policies only if other policies can be installed in their place. The DEC message has the following format:
COPS-PR DECメッセージは、DECメッセージ内のすべての決定は成功するか、それらはすべて失敗のいずれか、すなわち、単一の「トランザクション」として扱わなければなりません。彼らが失敗した場合、もしあれば、PEPは、最後に成功した12月の取引でその前の良好な状態にロールバックされます。これは、PDPは、他のポリシーがその場所に設置することができる場合にのみ、いくつかのポリシーを削除することができます。 DECメッセージの形式は次のとおりです。
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
<Decision> ::= <Context>
<Decision: Flags>
[<Named Decision Data: Provisioning >]
Note that the Named Decision Data (Provisioning) object is included in a COPS-PR Decision when it is an Install or Remove decision with no Decision Flags set. Other types of COPS decision data objects (e.g., Stateless, Replacement) are not supported by COPS-PR client-types. The Named Decision Data object MUST NOT be included in the decision if the Decision Flags object Command-Code is NULL (meaning there is no configuration information to install at this time) or if the Request-State flag is set in the Decision Flags object.
それが設定されていない意思決定フラグとインストールまたは削除を決定する場合、名前付き判定データ（プロビジョニング）オブジェクトがCOPS-PRの意思決定に含まれていることに注意してください。 COPS決定データオブジェクト（例えば、ステートレス、交換）の他のタイプのCOPS-PRクライアント・タイプによってサポートされていません。リクエストステートフラグが決定フラグオブジェクトに設定されている場合、名前付き意思決定意思決定フラグはコマンドコードをオブジェクトと、データオブジェクトは、決定に含んではいけませんが（この時点でインストールする設定情報が存在しないという意味）NULLですか。
For each decision in the DEC message, the PEP performs the operation specified in the Command-Code and Flags field in the Decision Flags object on the Named Decision Data. For the policy provisioning clients, the format for this data is defined in the context of the Policy Information Base (see section 5). In response to a DEC message, the policy provisioning client MUST send a RPT message, with the solicited message flag set, back to the PDP to inform the PDP of the action taken.
DECメッセージ内の各意思決定のために、PEPはフラグが名前付き判定データ上のオブジェクト意思決定にコマンドコードとフラグフィールドで指定された操作を実行します。ポリシーのプロビジョニングクライアントのために、このデータの形式は、ポリシー情報ベース（セクション5を参照）の文脈で定義されます。 DECメッセージに応答して、クライアントプロビジョニングポリシーは、実行されるアクションのPDPを通知するバックPDPに、要請メッセージのフラグを設定して、RPTメッセージを送らなければなりません。
The RPT message is sent from the policy provisioning clients to the PDP to report accounting information associated with the provisioned policy, or to notify the PDP of changes in the PEP (Report-Type = ' Accounting') related to the provisioning client.
RPTメッセージは、プロビジョニングポリシーに関連付けられた会計情報を報告するために、またはプロビジョニングクライアントに関連PEP（レポート・タイプ=「会計」）の変化のPDPに通知するPDPへのクライアントのプロビジョニングポリシーから送信されます。
RPT is also used as a mechanism to inform the PDP about the action taken at the PEP in response to a DEC message. For example, in response to an 'Install' decision, the PEP informs the PDP if the policy data is installed (Report-Type = 'Success') or not (Report-Type = 'Failure'). Reports that are in response to a DEC message MUST set the solicited message flag in their COPS message header. Each solicited RTP MUST be sent for its corresponding DEC in the order the DEC messages were received. In case of a solicited failure, the PEP is expected to rollback to its previous (good) state as if the erroneous DEC transaction did not occur. The PEP MUST always respond to a DEC with a solicited RPT even in response to a NULL DEC, in which case the Report-Type will be 'Success'.
RPTはまた、DECメッセージに応答して、PEPで取られた行動についてPDPに通知するメカニズムとして使用されます。ポリシーデータは、（レポート・タイプ=「成功」）かない（レポート・タイプ=「失敗」）がインストールされている場合たとえば、「インストール」の決定に応じて、PEPはPDPに通知します。 DECメッセージに応答しているレポートは、それらのCOPSメッセージヘッダに要請メッセージフラグを設定しなければなりません。それぞれのRTPは、12月のメッセージが受信されたために、その対応する12月のために送らなければなりません募集しました。募集障害が発生した場合には、PEPは、誤った12月のトランザクションが発生しなかったかのようにその前の（良い）状態にロールバックすることが期待されます。 PEPは常に偶数レポート-Typeは「成功」となります。その場合にはNULL 12月、に応じて募集RPTと12月に反応しなければなりません。
Reports can also be unsolicited and all unsolicited Reports MUST NOT set the solicited message flag in their COPS message header. Examples of unsolicited reports include 'Accounting' Report-Types, which were not triggered by a specific DEC messages, or 'Failure' Report-Types, which indicate a failure in a previously successfully installed configuration (note that, in the case of such unsolicited failures, the PEP cannot rollback to a previous "good" state as it becomes ambiguous under these asynchronous conditions what the correct state might be).
レポートはまた、迷惑することができ、すべての未承諾のレポートは、彼らのCOPSメッセージのヘッダーに募集メッセージフラグを設定してはいけません。迷惑レポートの例には、以前に正常にインストールされた構成に失敗したことを示す特定のDECメッセージによってトリガされませんでした「会計」レポート-タイプ、または「失敗」レポート・タイプが含まれる（例えば迷惑の場合には、その点に注意してくださいそれは正しい状態が何であるかこれらの非同期の条件で曖昧になると故障、PEP）は、前の「良い」状態にロールバックすることはできません。
The RPT message may contain provisioning client information such as accounting parameters or errors/warnings related to a decision. The data format for this information is defined in the context of the policy information base (see section 5). The RPT message has the following format:
RPTメッセージは、このような会計パラメータや意思決定に関連するエラー/警告としてクライアントプロビジョニング情報を含んでいてもよいです。この情報のデータ形式は、ポリシー情報ベース（セクション5を参照）の文脈で定義されます。 RPTメッセージの形式は次のとおりです。
<Report State> ::= <Common Header>
<Client Handle>
<Report Type>
*(<Named ClientSI>)
[<Integrity>]
The COPS Policy Provisioning clients encapsulate several new objects within the existing COPS Named Client-specific information object and Named Decision Data object. This section defines the format of these new objects.
COPSポリシープロビジョニングクライアントは、クライアント固有の情報オブジェクトと名前付き判定データオブジェクトという名前の既存のCOPS内のいくつかの新しいオブジェクトをカプセル化します。このセクションでは、これらの新しいオブジェクトのフォーマットを定義します。
COPS-PR classifies policy data according to "bindings", where a binding consists of a Provisioning Instance Identifier and the Provisioning Instance data, encoded within the context of the provisioning policy information base (see section 5).
COPS-PRは、結合は、プロビジョニングポリシー情報ベースのコンテキスト内で符号化されたプロビジョニング・インスタンス識別子およびプロビジョニングインスタンスデータ、から成る「バインディング」、（第5章を参照）に従って、ポリシーデータを分類します。
The format for these new objects is as follows:
次のようにこれらの新しいオブジェクトの形式は次のとおりです。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num | S-Type |
+---------------+---------------+---------------+---------------+
| 32 bit unsigned integer |
+---------------+---------------+---------------+---------------+
S-Num and S-Type are similar to the C-Num and C-Type used in the base COPS objects. The difference is that S-Num and S-Type are used only for COPS-PR clients and are encapsulated within the existing COPS Named ClientSI or Named Decision Data objects. The S-Num identifies the general purpose of the object, and the S-Type describes the specific encoding used for the object. All the object descriptions and examples in this document use the Basic Encoding Rules as the encoding type (S-Type = 1). Additional encodings can be defined for the remaining S-Types in the future (for example, an additional S-Type could be used to carry XML string based encodings [XML] as an EPD of PRI instance data, where URNs identify PRCs [URN] and XPointers would be used for PRIDs).
S-numとS-タイプC-numとベースCOPSオブジェクトで使用されるC型と類似しています。違いは、S-numとS-TypeがCOPS-PRクライアントに対してのみ使用され、ClientSIまたは名前付き判定データオブジェクトという名前の既存のCOPS内にカプセル化されていることです。 S-民は、オブジェクトの一般的な目的を特定し、S-タイプオブジェクトに使用される特定の符号化を記載しています。この文書に記載されているすべてのオブジェクトの説明と例は、符号化タイプ（Sタイプ= 1）などの基本的な符号化規則を使用します。付加的なエンコーディングのURNは位相応答曲線を特定PRIインスタンスデータのEPDとして[XML]（例えば、追加のS-TypeがXML文字列ベースの符号化を実行するために使用することができ、将来的に残っているS-タイプのために定義することができる[URN]そしてXPointerは）PRIDsために使用されるであろう。
Length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding MUST be added to the end of the object so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the stated object length of the current object to the next 32-bit boundary. The values for the padding MUST be all zeros.
長さは、対象物を構成する（ヘッダを含む）のオクテットの数を記載する2オクテットの値です。オクテットの長さが32ビットワード境界に該当しない場合、パディングは、オブジェクトがワイヤ上で送信することができる前に、それは次の32ビット境界に位置合わせされるように、オブジェクトの末尾に追加する必要があります。受信側では、後続のオブジェクト境界は、単に次の32ビット境界に、現在のオブジェクトの上記目的長を切り上げにより求めることができます。パディングの値がすべてゼロでなければなりません。
S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable.
S-民= 1（完全PRID）、S-タイプ= 1（BER）、長さ=可変。
This object is used to carry the identifier, or PRID, of a Provisioning Instance. The identifier is encoded following the rules that have been defined for encoding SNMP Object Identifier (OID) values. Specifically, PRID values are encoded using the Type/Length/Value (TLV) format and initial sub-identifier packing that is specified by the binary encoding rules [BER] used for Object Identifiers in an SNMP PDU.
この目的は、プロビジョニング・インスタンスの識別子、またはPRIDを搬送するために使用されます。識別子は、SNMPオブジェクト識別子（OID）の値を符号化するために定義された規則に従って符号化されます。具体的には、PRID値は、SNMP PDUにおけるオブジェクト識別子のために使用されるバイナリ符号化規則[BER]で指定されたタイプ/長さ/値（TLV）形式と初期サブ識別子パッキンを使用して符号化されます。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Instance Identifier |
+---------------+---------------+---------------+---------------+
For example, a (fictitious) PRID equal to 1.3.6.1.2.2.8.1 would be encoded as follows (values in hex):
例えば、1.3.6.1.2.2.8.1に等しい（架空の）PRIDは、（16進数の値）を次のように符号化されるであろう。
06 07 2B 06 01 02 02 08 01
06 07 AP 06 01 02 02 08 01
The entire PRID object would be encoded as follows:
次のように全体PRIDオブジェクトが符号化されるであろう。
00 0D - Length
01 - S-Num
01 - S-Type (Complete PRID)
06 07 2B 06 01 02 02 08 01 - Encoded PRID
00 00 00 - Padding
NOTE: When encoding an xxxTable's xxxEntry Object-Type as defined by the SMI [V2SMI] and SPPI [SPPI], the OID will contain all the sub-identifiers up to and including the xxxEntry OID but not the columnar identifiers for the attributes within the xxxEntry's SEQUENCE. The last (suffix) identifier is the INDEX of an instance of an entire xxxEntry including its SEQUENCE of attributes encoded in the EPD (defined below). This constitutes an instance (PRI) of a class (PRC) in terms of the SMI.
注：xxxTableのxxxEntryオブジェクト型をコードするSMI [V2SMI]とSPPI [SPPI]で定義されている場合は、OIDをアップするために、すべてのサブ識別子を含んでおり、xxxEntry OIDではなく、内の属性のための柱状の識別子を含めますxxxEntryのSEQUENCE。最後（接尾辞）識別子は、EPD（以下に定義）で符号化された属性のその配列を含む全体xxxEntryのインスタンスのインデックスです。これは、SMIの点でクラス（PRC）のインスタンス（PRI）を構成します。
A PRID for a scalar (non-columnar) value's OID is encoded directly as the PRC where the instance identifier suffix is always zero as there will be only one instance of a scalar value. The EPD will then be used to convey the scalar value.
スカラーためPRID（非柱状）値のOIDは、スカラー値の唯一のインスタンスが存在するであろうように、インスタンス識別子のサフィックスは常にゼロであるPRCとして直接符号化されます。 EPDは、スカラー値を伝えるために使用されます。
Certain operations, such as decision removal, can be optimized by specifying a PRID prefix with the intent that the requested operation be applied to all PRIs matching the prefix (for example, all instances of the same PRC). PRID prefix objects MUST only be used in the COPS protocol <Remove Decision> operation where it may be more optimal to perform bulk decision removal using class prefixes instead of a sequence of individual <Remove Decision> operations. Other COPS operations, e.g., <Install Decision> operations always require individual PRID specification.
そのような決定の除去などの特定の操作は、要求された操作がプレフィックスに一致するすべてのPRIに適用されることを意図してPRIDプレフィックスを指定することによって最適化することができる（例えば、同じ中国のすべてのインスタンス）。 PRIDプレフィックスオブジェクトは、COPSプロトコルで使用されなければならない操作<決定を削除>ではなく個々の配列のクラスプレフィックスを使用してバルク決定除去を行うことがより最適かもしれ操作<決定を削除>。その他のCOPSの操作は、例えば、操作常に個々のPRIDの仕様を必要とし、<決定インストール>。
S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable.
S-民= 2（プレフィックスPRID）、S-タイプ= 1（BER）、長さ=可変。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PPRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
... ...
| Prefix PRID |
... ...
+---------------+---------------+---------------+---------------+
Continuing with the previous example, a prefix PRID that is equal to 1.3.6.1.2.2 would be encoded as follows (values in hex):
（16進数の値）を次のように前の例を続けると、1.3.6.1.2.2に等しいプレフィックスPRIDは、符号化されるであろう。
06 05 2B 06 01 02 02
05 06 AP 02 01 06 02
The entire PPRID object would be encoded as follows:
次のように全体PPRIDオブジェクトが符号化されるであろう。
00 0B - Length 02 - S-Num = Prefix PRID 01 - S-Type = BER 06 05 2B 06 01 02 02 - Encoded Prefix PRID 00 - Padding
00 0B - 長さ02 - S-民=プレフィックスPRID 01 - Sタイプ= BER 06 05 2B 06 01 02 02 - エンコードプレフィックスPRID 00 - パディング
S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable.
S-民= 3（EPD）、S-タイプ= 1（BER）、長さ=可変。
This object is used to carry the encoded value of a Provisioning Instance. The PRI value, which contains all of the individual values of the attributes that comprise the class (which corresponds to the SMI's xxxEntry Object-Type defining the SEQUENCE of attributes comprising a table [V2SMI][SPPI]), is encoded as a series of TLV sub-components. Each sub-component represents the value of a single attribute and is encoded following the BER. Note that the ordering of non-scalar (multiple) attributes within the EPD is dictated by their respective columnar OID suffix when defined in [V2SMI]. Thus, the attribute with the smallest columnar OID suffix will appear first and the attribute with the highest number columnar OID suffix will be last.
このオブジェクトは、プロビジョニング・インスタンスのエンコードされた値を搬送するために使用されます。 （表[V2SMI] [SPPI]を含む属性のシーケンスを定義SMIのxxxEntryオブジェクトタイプに対応する）クラスを含む属性の個々の値のすべてを含むPRI値は、一連の符号化されていますTLVのサブコンポーネント。各サブコンポーネントは、単一の属性の値を表し、BER次符号化されます。 [V2SMI]で定義されたときにEPDがそれぞれの柱状OIDサフィックスによって決定された内の非スカラー（複数）の順序属性があります。このように、最小の柱状OID接尾辞を持つ属性が最初に表示され、最も多くの柱状OID接尾辞を持つ属性が最後になります。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = EPD | S-Type = BER |
+---------------+---------------+---------------+---------------+
| BER Encoded PRI Value |
+---------------+---------------+---------------+---------------+
As an example, a fictional definition of an IPv4 packet filter class could be described using the SMI as follows:
一例として、IPv4のパケットフィルタクラスの架空の定義は次のようにSMIを使用して記述することができます。
ipv4FilterIpFilter OBJECT IDENTIFIER ::= { someExampleOID 1 }
-- The IP Filter Table
- IPフィルタテーブル
ipv4FilterTable OBJECT-TYPE SYNTAX SEQUENCE OF Ipv4FilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Filter definitions. A packet has to match all fields in a filter. Wildcards may be specified for those fields that are not relevant."
Ipv4FilterEntry MAX-ACCESSステータス現在の説明のipv4FilterTable OBJECT-TYPE構文配列「フィルタ定義。パケットは、フィルタのすべてのフィールドに一致しなければならない。ワイルドカードは関連しないこれらのフィールドに指定することができます。」
::= { ipv4FilterIpFilter 1 }
ipv4FilterEntry OBJECT-TYPE SYNTAX Ipv4FilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An instance of the filter class."
ipv4FilterEntry OBJECT-TYPE SYNTAX Ipv4FilterEntry MAX-ACCESSステータス現在の説明は「フィルタクラスのインスタンス。」
INDEX { ipv4FilterIndex }
INDEX {ipv4FilterIndex}
::= { ipv4FilterTable 1 }
Ipv4FilterEntry ::= SEQUENCE {
ipv4FilterIndex Unsigned32,
ipv4FilterDstAddr IpAddress,
ipv4FilterDstAddrMask IpAddress,
ipv4FilterSrcAddr IpAddress,
ipv4FilterSrcAddrMask IpAddress,
ipv4FilterDscp Integer32,
ipv4FilterProtocol Integer32,
ipv4FilterDstL4PortMin Integer32,
ipv4FilterDstL4PortMax Integer32,
ipv4FilterSrcL4PortMin Integer32,
ipv4FilterSrcL4PortMax Integer32,
ipv4FilterPermit TruthValue
}
ipv4FilterIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "An integer index to uniquely identify this filter among all the filters."
ipv4FilterIndex OBJECT-TYPEの構文Unsigned32 MAX-ACCESS読み取りと書き込みステータス現在の説明「すべてのフィルタのうち、このフィルタを識別するための整数インデックス。」
::= { ipv4FilterEntry 1 }
ipv4FilterDstAddr OBJECT-TYPE
ipv4FilterDstAddrのOBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address to match against the packet's destination IP
address."
::= { ipv4FilterEntry 2 }
ipv4FilterDstAddrMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "A mask for the matching of the destination IP address. A zero bit in the mask means that the corresponding bit in the address always matches."
ipv4FilterDstAddrMask OBJECT-TYPE構文IPアドレスMAX-ACCESS読み取りと書き込みステータス現在の説明「宛先IPアドレスのマッチングのためのマスク。マスクのゼロビットは、アドレスの対応するビットが常に一致することを意味します。」
::= { ipv4FilterEntry 3 }
ipv4FilterSrcAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address to match against the packet's source IP address."
ipv4FilterSrcAddr OBJECT-TYPEの構文のIPアドレスMAX-ACCESS読み取りと書き込みステータス現在の説明「パケットの送信元IPアドレスと照合するIPアドレス。」
::= { ipv4FilterEntry 4 }
ipv4FilterSrcAddrMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "A mask for the matching of the source IP address."
ipv4FilterSrcAddrMask OBJECT-TYPE構文IPアドレスMAX-ACCESS読み取りと書き込みステータス現在の説明「送信元IPアドレスのマッチングのためのマスク」。
::= { ipv4FilterEntry 5 }
ipv4FilterDscp OBJECT-TYPE SYNTAX Integer32 (-1 | 0..63) MAX-ACCESS read-write STATUS current DESCRIPTION "The value that the DSCP in the packet can have and match. A value of -1 indicates that a specific DSCP value has not been defined and thus all DSCP values are considered a match."
ipv4FilterDscpのOBJECT-TYPE構文Integer32（-1 | 0 63）MAX-ACCESS読み取りと書き込みステータスパケット内のDSCPを持つと一致することができること現在の説明は「値-1の値は、特定のDSCP値を有していることを示しています。定義され、したがって、すべてのDSCP値が一致するとみなされません。」
::= { ipv4FilterEntry 6 }
ipv4FilterProtocol OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The IP protocol to match against the packet's protocol. A value of zero means match all."
ipv4FilterProtocolのOBJECT-TYPE構文Integer32（0 255）MAX-ACCESS読み取りと書き込みステータス現在の説明「パケットのプロトコルと照合するIPプロトコル。ゼロの値は、すべての一致を意味します。」
::= { ipv4FilterEntry 7 }
ipv4FilterDstL4PortMin OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write
ipv4FilterDstL4PortMinのOBJECT-TYPE構文Integer32（0 65535）MAX-ACCESSの読み取りと書き込み
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 destination
port number can have and match this filter."
::= { ipv4FilterEntry 8 }
ipv4FilterDstL4PortMax OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum value that the packet's layer 4 destination port number can have and match this filter."
ipv4FilterDstL4PortMaxのOBJECT-TYPE構文Integer32（0 65535）MAX-ACCESS読み取りと書き込みステータス現在の説明「パケットのレイヤ4宛先ポート番号を持っていると、このフィルタに一致することができる最大値」。
::= { ipv4FilterEntry 9 }
ipv4FilterSrcL4PortMin OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum value that the packet's layer 4 source port number can have and match this filter."
ipv4FilterSrcL4PortMinのOBJECT-TYPE構文Integer32（0 65535）MAX-ACCESS読み取りと書き込みステータス現在の説明「パケットのレイヤ4送信元ポート番号を持っていると、このフィルタに一致することができる最小値」。
::= { ipv4FilterEntry 10 }
ipv4FilterSrcL4PortMax OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum value that the packet's layer 4 source port number can have and match this filter."
ipv4FilterSrcL4PortMaxのOBJECT-TYPE構文Integer32（0 65535）MAX-ACCESS読み取りと書き込みステータス現在の説明「パケットのレイヤ4送信元ポート番号を持っていると、このフィルタに一致することができる最大値」。
::= { ipv4FilterEntry 11 }
ipv4FilterPermit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If false, the evaluation is negated. That is, a valid match will be evaluated as not a match and vice versa."
ipv4FilterPermit OBJECT-TYPEの構文のTruthValue MAX-ACCESS読み取りと書き込みステータス現在の説明「falseの場合、評価が否定された。それは、有効な一致がない試合とその逆として評価されますされています。」
::= { ipv4FilterEntry 12 }
A fictional instance of the filter class defined above might then be encoded as follows:
以下のように定義フィルタクラスの架空のインスタンスは、符号化されるかもしれません。
02 01 08 :ipv4FilterIndex/Unsigned32/Value = 8 40 04 C0 39 01 05 :ipv4FilterDstAddr/IpAddress/Value = 192.57.1.5 40 04 FF FF FF FF :ipv4FilterDstMask/IpAddress/Value=255.255.255.255 40 04 00 00 00 00 :ipv4FilterSrcAddr/IpAddress/Value = 0.0.0.0 40 04 00 00 00 00 :ipv4FilterSrcMask/IpAddress/Value = 0.0.0.0 02 01 FF :ipv4FilterDscp/Integer32/Value = -1 (not used) 02 01 06 :ipv4FilterProtocol/Integer32/Value = 6 (TCP) 05 00 :ipv4FilterDstL4PortMin/NULL/not supported 05 00 :ipv4FilterDstL4PortMax/NULL/not supported 05 00 :ipv4FilterSrcL4PortMin/NULL/not supported 05 00 :ipv4FilterSrcL4PortMax/NULL/not supported 02 01 01 :ipv4FilterPermit/TruthValue/Value = 1 (true)
02 01 08：ipv4FilterIndex / Unsigned32の/値= 8 40 04 C0 39 01 05：ipv4FilterDstAddr / IPアドレス/値= 192.57.1.5 40 04 FF FF FF FF：ipv4FilterDstMask / IPアドレス/値= 255.255.255.255 40 04 00 00 00 00： ipv4FilterSrcAddr / IPアドレス/値= 0.0.0.0 40 04 00 00 00 00：ipv4FilterSrcMask / IPアドレス/値= 0.0.0.0 02 01 FF：ipv4FilterDscp / Integer32の/値= -1（未使用）02 01 06：ipv4FilterProtocol / Integer32の/値= 6（TCP）05 00：ipv4FilterDstL4PortMin / NULLがサポートされていない/ 05 00：ipv4FilterDstL4PortMaxは/ NULLがサポートされていない/ 05 00：ipv4FilterSrcL4PortMin / NULLがサポートされていない/ 05 00：ipv4FilterPermit /のTruthValue /値：02 01 01サポートされていない/ ipv4FilterSrcL4PortMax / NULL = 1（真）
The entire EPD object for this instance would then be encoded as follows:
次のようにこのインスタンスの全体EPDオブジェクトは、符号化されるであろう。
00 30 - Length 03 - S-Num = EPD 01 - S-Type = BER 02 01 08 - ipv4FilterIndex 40 04 C0 39 01 05 - ipv4FilterDstAddr 40 04 FF FF FF FF - ipv4FilterDstMask 40 04 00 00 00 00 - ipv4FilterSrcAddr 40 04 00 00 00 00 - ipv4FilterSrcMask 02 01 FF - ipv4FilterDscp 02 01 06 - ipv4FilterProtocol 05 00 - ipv4FilterDstL4PortMin 05 00 - ipv4FilterDstL4PortMax 05 00 - ipv4FilterSrcL4PortMin 05 00 - ipv4FilterSrcL4PortMax 02 01 01 - ipv4FilterPermit
00 30 - 長さ03 - S-民= EPD 01 - Sタイプ= BER 02 01 08 - ipv4FilterIndex 40 04 C0 39 01 05 - ipv4FilterDstAddr 40 04 FF FF FF FF - ipv4FilterDstMask 40 04 00 00 00 00 - ipv4FilterSrcAddr 40 04 00 00 00 00 - 02 01 ipv4FilterSrcMask FF - ipv4FilterDscp 02 01 06から05 00 ipv4FilterProtocol - ipv4FilterDstL4PortMin 05 00 - 05 00 ipv4FilterDstL4PortMax - ipv4FilterSrcL4PortMin 05 00 - 02 01 01 ipv4FilterSrcL4PortMax - ipv4FilterPermit
Note that attributes not supported within a class are still returned in the EPD for a PRI. By convention, a NULL value is returned for attributes that are not supported. In the previous example, source and destination port number attributes are not supported.
クラス内でサポートされていない属性注はまだPRIのためのEPDで返されます。慣例により、NULL値がサポートされていない属性に返されます。前の例では、送信元および宛先ポート番号属性はサポートされていません。
S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8.
= 4（GPERR）S-numが、Sタイプ= 1（BER用）、長さ= 8。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = GPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
The global provisioning error object has the same format as the Error object in COPS [COPS], except with C-Num and C-Type replaced by the S-Num and S-Type values shown. The global provision error object is used to communicate general errors that do not map to a specific PRC.
グローバルプロビジョニングエラーオブジェクトは、C-numと示すS-numとS-Type値によって置き換えC型を除いてCOPS [COPS]のエラーオブジェクトと同じフォーマットを有します。グローバルプロビジョニングエラーオブジェクトは、特定のPRCにマップされない一般的なエラーを通信するために使用されます。
The following global error codes are defined:
次のグローバルエラーコードが定義されています。
availMemLow(1) availMemExhausted(2) unknownASN.1Tag(3) - The erroneous tag type SHOULD be specified in the Error Sub-Code field. maxMsgSizeExceeded(4) - COPS message (transaction) was too big. unknownError(5) maxRequestStatesOpen(6)- No more Request-States can be created by the PEP (in response to a DEC message attempting to open a new Request-State). invalidASN.1Length(7) - An ASN.1 object length was incorrect. invalidObjectPad(8) - Object was not properly padded. unknownPIBData(9) - Some of the data supplied by the PDP is unknown/unsupported by the PEP (but otherwise formatted correctly). PRC specific error codes are to be used to provide more information. unknownCOPSPRObject(10)- Sub-code (octet 2) contains unknown object's S-Num and (octet 3) contains unknown object's S-Type. malformedDecision(11) - Decision could not be parsed.
availMemLow（1）availMemExhausted（2）unknownASN.1Tag（3） - 間違ったタグタイプは、エラーサブコードフィールドに指定されるべきです。 maxMsgSizeExceededは（4） - メッセージ（トランザクション）があまりにも大きかったCOPS。ないUnknownError（5）maxRequestStatesOpen（6） - これ以上の要求-国は（新しいRequest-状態を開こうとDECメッセージに応じて）PEPによって作成することができます。 invalidASN.1Lengthは（7） - ASN.1オブジェクトの長さが間違っていました。 invalidObjectPad（8） - オブジェクトが適切にパディングされていませんでした。 unknownPIBDataは（9） - PDPによって供給されたデータの一部は、PEPによってサポートされていない/不明である（それ以外は正しくフォーマット）。 PRC特定のエラーコードは、より多くの情報を提供するために使用されます。 unknownCOPSPRObject（10） - サブコード（オクテット2）は、未知のオブジェクトのS-民を含み、（オクテット3）は、未知のオブジェクトのS-タイプを含みます。 malformedDecision（11） - 意思決定を解析できませんでした。
S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8.
S-民= 5（CPERR）、S-タイプ= 1（BER用）、長さ= 8。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = CPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
The class-specific provisioning error object has the same format as the Error object in COPS [COPS], except with C-Num and C-Type replaced by the S-Num and S-Type values shown. The class-specific error object is used to communicate errors relating to specific PRCs and MUST have an associated Error PRID Object.
クラス固有のプロビジョニング・エラー・オブジェクトは、C-numと示すS-numとS-Type値によって置き換えC型を除いてCOPS [COPS]のエラーオブジェクトと同じフォーマットを有します。クラス固有のエラーオブジェクトは、特定の位相応答曲線に関連するエラーを通信するために使用され、関連するエラーPRIDオブジェクトを持たなければなりません。
The following Generic Class-Specific errors are defined:
以下のジェネリッククラス固有のエラーが定義されています。
priSpaceExhausted(1) - no more instances may currently be installed in the given class. priInstanceInvalid(2) - the specified class instance is currently invalid prohibiting installation or removal. attrValueInvalid(3) - the specified value for identified attribute is illegal. attrValueSupLimited(4) - the specified value for the identified attribute is legal but not currently supported by the device. attrEnumSupLimited(5) - the specified enumeration for the identified attribute is legal but not currently supported by the device. attrMaxLengthExceeded(6) - the overall length of the specified value for the identified attribute exceeds device limitations. attrReferenceUnknown(7) - the class instance specified by the policy instance identifier does not exist. priNotifyOnly(8) - the class is currently only supported for use by request or report messages prohibiting decision installation. unknownPrc(9) - attempt to install a PRI of a class not supported by PEP. tooFewAttrs(10) - recvd PRI has fewer attributes than required. invalidAttrType(11) - recvd PRI has an attribute of the wrong type.
priSpaceExhausted（1） - ない複数のインスタンスは、現在指定されたクラス内に設置することができます。 priInstanceInvalid（2） - 指定されたクラスのインスタンスが現在無効な禁止のインストールまたは削除です。 attrValueInvalidは（3） - 特定された属性に指定された値が不正です。 attrValueSupLimited（4） - 特定された属性に指定された値は有効ですが、現在のデバイスでサポートされていません。 attrEnumSupLimitedは（5） - 特定された属性に指定された列挙は合法ですが、現在のデバイスでサポートされていません。 attrMaxLengthExceeded（6） - 識別された属性の指定された値の全体の長さは、デバイスの制限を超えています。 attrReferenceUnknown（7） - ポリシーインスタンス識別子によって指定されたクラスのインスタンスが存在しません。 priNotifyOnlyは（8） - クラスは現在、意思決定のインストールを禁止する要求またはレポートメッセージで使用するためにサポートされています。 unknownPrc（9） - PEPによってサポートされていないクラスのPRIをインストールしようとする試み。 tooFewAttrs（10） - PRIが必要とされるよりも少ない属性がありRECVD。 invalidAttrType（11） - RECVD PRIは、間違った型の属性を持っています。
deletedInRef(12) - deleted PRI is still referenced by other (non) deleted PRIs priSpecificError(13) - the Error Sub-code field contains the PRC specific error code
deletedInRef（12） - エラーサブコードフィールドは、PRC特定のエラーコードが含まれてい - PRIは、さらに他の（非）のPRI priSpecificError（13）削除によって参照されている削除
Where appropriate (errors 3, 4, 5, 6, 7 above) the error sub-code SHOULD identify the OID sub-identifier of the attribute associated with the error.
適切な場合（エラー3、4、5、6、上記7）のエラーサブコードは、エラーに関連付けられた属性のOIDサブ識別子を識別すべきです。
S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable.
S-民= 6（ErrorPRID）、S-タイプ= 1（BER）、長さ=可変。
This object is used to carry the identifier, or PRID, of a Provisioning Instance that caused an installation error or could not be installed or removed. The identifier is encoded and formatted exactly as in the PRID object as described in section 4.1.
このオブジェクトは、インストールエラーの原因となったプロビジョニング・インスタンスの識別子、またはPRIDを搬送するために使用されるか、インストールまたは削除することができませんでした。識別子は、符号化され、セクション4.1で説明したように正確PRIDオブジェクトのようにフォーマットされます。
This section describes the format of the named client specific information for the COPS policy provisioning client. ClientSI formats are defined for Decision message's Named Decision Data object, the Request message's Named ClientSI object and Report message's Named ClientSI object. The actual content of the data is defined by the policy information base for a specific provisioning client-type (see below).
このセクションでは、COPSポリシープロビジョニングクライアント用という名前のクライアント固有情報の形式について説明します。 ClientSI形式は、意思決定のメッセージの名前付き判定データオブジェクトの要求メッセージの名前付きClientSIオブジェクトとレポートメッセージの名前付きClientSIオブジェクトを定義しています。データの実際の内容は、特定のプロビジョニングクライアントタイプのポリシー情報ベース（下記参照）によって定義されます。
The formats encapsulated by the Named Decision Data object for the policy provisioning client-types depends on the type of decision. Install and Remove are the two types of decisions that dictate the internal format of the COPS Named Decision Data object and require its presence. Install and Remove refer to the 'Install' and 'Remove' Command-Code, respectively, specified in the COPS Decision Flags Object when no Decision Flags are set. The data, in general, is composed of one or more bindings. Each binding associates a PRID object and a EPD object. The PRID object is always present in both install and remove decisions, the EPD object MUST be present in the case of an install decision and MUST NOT be present in the case of a remove decision.
クライアントの種類をプロビジョニングポリシーの名前判定データオブジェクトによってカプセル化されたフォーマットは、決定の種類によって異なります。判定データオブジェクトの名前付きCOPSの内部フォーマットを決定し、その存在を必要とする意思決定の2種類がインストールし、削除します。インストールと削除を参照して「インストール」と「削除」コマンドコード、それぞれ、何の決定フラグが設定されていないときFlagsオブジェクトCOPS決定に指定されています。データは、一般的に、一つ以上のバインディングで構成されています。各結合仲間PRIDオブジェクトとEPDオブジェクト。 PRIDオブジェクトは常にインストールおよび削除の両方の決定に存在する、EPDオブジェクトは、インストールの決定の際に存在しなければならないと削除の決定の際に存在してはなりません。
The format for this data is encapsulated within the COPS Named
Decision Data object as follows:
<Named Decision Data> ::= <<Install Decision> |
<Remove Decision>>
<Install Decision> ::= *(<PRID> <EPD>)
<Remove Decision> ::= *(<PRID>|<PPRID>)
Note that PRID objects in a Remove Decision may specify PRID prefix values. Explicit and implicit deletion of installed policies is supported by a client. Install Decision data MUST be explicit (i.e., PRID prefix values are illegal and MUST be rejected by a client).
削除意思決定におけるPRIDオブジェクトがPRIDプレフィックス値を指定することに注意してください。インストールされているポリシーの明示的および暗黙の削除は、クライアントによってサポートされています。判定データをインストールする（すなわち、PRIDプレフィックス値は不正であり、クライアントによって拒否されなければならない）、明示的でなければなりません。
The provisioning client request data will use same bindings as described above. The format for this data is encapsulated in the COPS Named ClientSI object as follows:
前述したように、プロビジョニングクライアント要求のデータは同じバインディングを使用します。このデータのフォーマットは、以下のようClientSIオブジェクト名前COPSにカプセル化されます。
<Named ClientSI: Request> ::= <*(<PRID> <EPD>)>
The COPS Named ClientSI object is used in the RPT message in conjunction with the accompanying COPS Report Type object to encapsulate COPS-PR report information from the PEP to the PDP. Report types can be 'Success' or 'Failure', indicating to the PDP that a particular set of provisioning policies has been either successfully or unsuccessfully installed/removed on the PEP, or 'Accounting'.
ClientSIオブジェクトの名前付きCOPSはPDPへのPEPからCOPS-PRレポート情報をカプセル化するレポートタイプのオブジェクトに付随するCOPSと一緒にRPTメッセージで使用されています。レポートの種類は、「成功」か「失敗」、PEPで除去/プロビジョニング・ポリシーの特定のセットが正常終了または失敗したインストールされていることをPDPに指示、または「会計」にすることができます。
Report-types can be 'Success' or 'Failure' indicating to the PDP that a particular set of provisioning policies has been either successfully or unsuccessfully installed/removed on the PEP. The provisioning report data consists of the bindings described above and global and specific error/warning information. Specific errors are associated with a particular instance. For a 'Success' Report-Type, a specific error is an indication of a warning related to a specific policy that has been installed, but that is not fully implemented (e.g., its parameters have been approximated) as identified by the ErrorPRID object. For a 'Failure' Report-Type, this is an error code specific to a binding, again, identified by the ErrorPRID object. Specific errors may also include regular <PRID><EPD> bindings to carry additional information in a generic manner so that the specific errors/warnings may be more verbosely described and associated with the erroneous ErrorPRID object.
レポート・タイプは、プロビジョニング・ポリシーの特定のセットが正常終了または失敗したPEPに削除/インストールされていることをPDPに示す「成功」か「失敗」することができます。プロビジョニングレポートデータは、上述のバインディング、グローバルおよび特定のエラー/警告情報から成ります。特定のエラーは、特定のインスタンスに関連付けられています。 ErrorPRIDオブジェクトによって識別されるように「成功」を報告するタイプのため、特定のエラーがインストールされている特定のポリシーに関連する警告の表示であるが、それは完全に実装されていない（例えば、そのパラメータは、近似されています）。 「失敗」レポート・タイプの場合、これは結合に固有のエラーコードで、再び、ErrorPRIDオブジェクトによって識別されます。特定のエラーは、特定のエラー/警告がより冗長に記載の誤ErrorPRIDオブジェクトに関連付けることができるように、一般的な方法で追加情報を搬送するために定期的に<PRID> <EPD>バインディングを含んでいてもよいです。
Global errors are not tied to a specific ErrorPRID. In a 'Success' RPT message, a global error is an indication of a general warning at the PEP level (e.g., memory low). In a 'Failure' RPT message, this is an indication of a general error at the PEP level (e.g., memory exhausted).
グローバル・エラーは、特定のErrorPRIDに縛られていません。 「成功」RPTメッセージに、グローバルエラー（例えば、メモリ低い）PEPレベルでの一般的な警告の表示です。 「失敗」RPTメッセージには、これは、PEPレベル（例えば、メモリ枯渇）における一般的な誤差の指標です。
In the case of a 'Failure' Report-Type the PEP MUST report at least the first error and SHOULD report as many errors as possible. In this case the PEP MUST roll-back its configuration to the last good transaction before the erroneous Decision message was received.
「失敗」レポートタイプの場合、PEPは、少なくとも最初のエラーを報告しなければなりませんし、できるだけ多くのエラーとして報告すべきです。この場合、PEPは、ロールバックしなければならない、その構成を、最後の良好な取引に誤判定のメッセージを受信する前に。
The format for this data is encapsulated in the COPS Named ClientSI object as follows:
このデータのフォーマットは、以下のようClientSIオブジェクト名前COPSにカプセル化されます。
<Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
<report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
Additionally, reports can be used to carry accounting information when specifying the 'Accounting' Report-Type. This accounting report message will typically carry statistical or event information related to the installed configuration for use at the PDP. This information is encoded as one or more <PRID><EPD> bindings that generally describe the accounting information being reported from the PEP to the PDP.
また、報告書は、「会計」レポート・タイプを指定するときに会計情報を運ぶために使用することができます。この会計報告メッセージは、通常、PDPで使用するためにインストールされた構成に関連する統計やイベント情報を伝達します。この情報は、一般的にPDPにPEPから報告された課金情報を記述する1つ以上の<PRID> <EPD>バインディングとして符号化されます。
The format for this data is encapsulated in the COPS Named ClientSI object as follows:
このデータのフォーマットは、以下のようClientSIオブジェクト名前COPSにカプセル化されます。
<Named ClientSI: Report> ::= <*(<PRID><EPD>)>
NOTE: RFC 2748 defines an optional Accounting-Timer (AcctTimer) object for use in the COPS Client-Accept message. Periodic accounting reports for COPS-PR clients are also obligated to be paced by this timer. Periodic accounting reports SHOULD NOT be generated by the PEP more frequently than the period specified by the COPS AcctTimer. Thus, the period between new accounting reports SHOULD be greater-than or equal-to the period specified (if specified) in the AcctTimer. If no AcctTimer object is specified by the PDP, then there are no constraints imposed on the PEP's accounting interval.
注：RFC 2748はCOPSクライアント-Acceptメッセージで使用するためのオプションの会計タイマー（AcctTimer）オブジェクトを定義します。 COPS-PRクライアントの定期的な会計報告書はまた、このタイマーによってペースことを義務付けています。定期的な会計報告書は、COPS AcctTimerで指定された期間よりも頻繁にPEPによって生成されるべきではありません。したがって、新たな会計報告の期間は次のようになり大なり又はAcctTimerに（指定されている場合）指定された期間に等しいから。何AcctTimerオブジェクトはPDPによって指定されていない場合、PEPの会計期間に課せられた制約事項はありません。
This section describes, in general, typical exchanges between a PDP and Policy Provisioning COPS client.
このセクションでは、PDPおよびポリシープロビジョニングCOPSクライアントの間で一般的な、一般的な取引所で、説明しています。
First, a TCP connection is established between the client and server and the PEP sends a Client-Open message specifying a COPS- PR client-type (use of the ClientSI object within the Client-Open message is currently undefined for COPS-PR clients). If the PDP supports the specified provisioning client-type, the PDP responds with a Client-Accept (CAT) message. If the client-type is not supported, a Client-Close (CC) message is returned by the PDP to the PEP, possibly identifying an alternate server that is known to support the policy for the provisioning client-type specified.
まず、TCP接続が（クライアントのオープンメッセージ内ClientSIオブジェクトの使用がCOPS-PRのクライアントのために、現在定義されていない）は、クライアントとサーバの間で確立し、PEPはCOPS- PRクライアントタイプを指定してクライアントを開き、メッセージを送信しています。 PDPは、指定されたプロビジョニングクライアントタイプをサポートしている場合、PDPは、Client-受け入れ（CAT）メッセージで応答します。クライアントタイプがサポートされていない場合、クライアントを閉じる（CC）メッセージは、おそらく指定プロビジョニングクライアントタイプのポリシーをサポートすることが知られている代替サーバを識別する、PEPとPDPによって返されます。
After receiving the CAT message, the PEP can send requests to the server. The REQ from a policy provisioning client contains a COPS 'Configuration Request' context object and, optionally, any relevant named client specific information from the PEP. The information provided by the PEP should include available client resources (e.g., supported classes/attributes) and default policy configuration information as well as incarnation data on existing policy. The configuration request message from a provisioning client serves two purposes. First, it is a request to the PDP for any provisioning configuration data which the PDP may currently have that is suitable for the PEP, such as access control filters, etc., given the information the PEP specified in its REQ. Also, the configuration request effectively opens a channel that will allow the PDP to asynchronously send policy data to the PEP, as the PDP decides is necessary, as long as the PEP keeps its request state open (i.e., as long as the PEP does not send a DRQ with the request state's Client Handle). This asynchronous data may be new policy data or an update to policy data sent previously. Any relevant changes to the PEP's internal state can be communicated to the PDP by the PEP sending an updated REQ message. The PEP is free to send such updated REQ messages at any time after a CAT message to communicate changes in its local state.
CATメッセージを受信した後、PEPは、サーバに要求を送信することができます。クライアントプロビジョニングポリシーからREQはCOPS「構成要求」PEPからコンテキストオブジェクトと、必要に応じて、任意の関連という名前のクライアント固有の情報が含まれています。 PEPによって提供される情報は、利用可能なクライアントのリソース（例えば、クラス/属性をサポート）、デフォルトのポリシー設定情報だけでなく、既存のポリシー上の化身のデータを含める必要があります。プロビジョニングクライアントからの構成要求メッセージは、2つの目的を果たします。まず、PDPは、現在PEPは、そのREQで指定された情報が与えられると、それは等、アクセス制御フィルタとしてPEP、適している必要がある可能性があり、任意のプロビジョニング構成データのPDPへの要求です。また、コンフィギュレーション要求が効果的に限りPEPは限りPEPがないよう、すなわち（オープンその要求状態を保つよう、PDPが決定したように、PDPは、非同期PEPにポリシーデータを送信することができますチャネルを開き必要があります）要求状態のクライアントハンドルをDRQを送信します。この非同期データは、新しいポリシー・データまたは以前に送信されたポリシーデータに更新することがあります。 PEPの内部状態に関連するすべての変更は、更新されREQメッセージを送信することにより、PEP PDPに伝達することができます。 PEPは、そのローカル状態の変化を伝達するためにCATメッセージの後に任意の時点で、このような更新REQメッセージを送信して自由です。
After the PEP sends a REQ, if the PDP has Policy Provisioning policy configuration information for the client, that information is returned to the client in a DEC message containing the Policy Provisioning client policy data within the COPS Named Decision Data object and specifying an "Install" Command-Code in the Decision Flags object. If no filters are defined, the DEC message will simply specify that there are no filters using the "NULL Decision" Command-Code in the Decision Flags object. As the PEP MUST specify a Client Handle in the request message, the PDP MUST process the Client Handle and copy it in the corresponding decision message. A DEC message
PEPはREQを送信した後、PDPは、クライアントのためのポリシープロビジョニングポリシーの設定情報を持っている場合、その情報は、判定データオブジェクトと、「インストールを指定する名前付きCOPS内のポリシープロビジョニングクライアントポリシーデータを含むDECメッセージでクライアントに返されますFlagsオブジェクト意思決定における「コマンドコード。何のフィルタが定義されていない場合は、DECメッセージは、単にFlagsオブジェクトの決定に「NULL決定」コマンドのコードを使用して何のフィルタが存在しないことを指定します。 PEPは、要求メッセージにクライアントハンドルを指定しなければならないとして、PDPは、クライアントハンドルを処理し、対応する決定メッセージでそれをコピーする必要があります。 DECメッセージ
MUST be issued by the PDP with the Solicited Message Flag set in the COPS message header, regardless of whether or not the PDP has any configuration information for the PEP at the time of the request. This is to prevent the PEP from timing out the REQ and deleting the Client Handle.
かかわらず、PDPは、要求時にPEPの構成情報を有するか否かの、COPSメッセージヘッダーの要請メッセージフラグが設定されたPDPによって発行されなければなりません。これは、REQがタイムアウトし、クライアントハンドルを削除するからPEPを防ぐためです。
The PDP can then add new policy data or update/delete existing configurations by sending subsequent unsolicited DEC message(s) to the PEP, with the same Client Handle. Previous configurations installed on the PEP are updated by the PDP by simply re-installing the same instance of configuration information again (effectively overwriting the old data). The PEP is responsible for removing the Client handle when it is no longer needed, for example when an interface goes down, and informing the PDP that the Client Handle is to be deleted via the COPS DRQ message.
PDPは、新しいポリシーデータを追加または更新/同じクライアントハンドルと、PEP後に迷惑DECメッセージ（単数または複数）を送信することによって、既存の構成を削除することができます。 PEPにインストール前の構成は、（効果的に古いデータを上書き）もう一度設定情報の同じインスタンスを再インストールすることにより、PDPによって更新されます。 PEPは、それが不要になったときのインターフェイスがダウンした場合、たとえば、クライアントハンドルを削除しないと、クライアントハンドルがCOPS DRQメッセージを介して削除されることをPDPに通知する責任があります。
For Policy Provisioning purposes, access state, and access requests to the policy server can be initiated by other sources besides the PEP. Examples of other sources include attached users requesting network services via a web interface into a central management application, or H.323 servers requesting resources on behalf of a user for a video conferencing application. When such a request is accepted, the edge device affected by the decision (the point where the flow is to enter the network) needs to be informed of the decision. Since the PEP in the edge device did not initiate the request, the specifics of the request, e.g., flowspec, packet filter, and PHB to apply, needs to be communicated to the PEP by the PDP. This information is sent to the PEP using the Decision message containing Policy Provisioning Named Decision Data objects in the COPS Decision object as specified. Any updates to the state information, for example in the case of a policy change or call tear down, is communicated to the PEP by subsequent unsolicited DEC messages containing the same Client Handle and the updated Policy Provisioning request state. Updates can specify that policy data is to be installed, deleted, or updated (re-installed).
ポリシープロビジョニング目的で、アクセス状態、およびポリシーサーバへのアクセス要求のためにPEP以外の他のソースによって開始することができます。他の情報源の例としては、ビデオ会議アプリケーションのためのユーザーの代わりにリソースを要求添付中央管理アプリケーションにWebインターフェイスを介してネットワークサービスを要求するユーザ、またはH.323サーバが含まれます。そのような要求が受け付けられると、決定（フローがネットワークに入ることにある点）の影響を受け、エッジデバイスは、決定を通知する必要があります。エッジ装置におけるPEPが要求を開始しなかったため、要求の詳細は、例えば、フロースペックは、パケットフィルタ、およびPHBを適用するために、PDPによってPEPに伝達する必要があります。この情報は、指定されたCOPS決定オブジェクトに判定データオブジェクトを名前付きポリシープロビジョニングを含む決定メッセージを使用してPEPに送信されます。例えば、状態情報への更新、ポリシーが変更された場合、または取りこわしを呼び出すには、同じクライアントハンドルと更新ポリシープロビジョニング要求状態を含む、後続の未承諾のDECメッセージによってPEPに伝達されます。更新は（再インストール）を削除、ポリシーデータをインストールすることを指定、または更新することができます。
PDPs may also command the PEP to open a new Request State or delete an exiting one by issuing a decision with the Decision Flags object's Request-State flag set. If the command-code is "install", then the PDP is commanding the PEP to create a new Request State, and therefore issue a new REQ message specifying a new Client Handle or otherwise issue a "Failure" RPT specifying the appropriate error condition. Each request state represents an independent and logically non-overlapping namespace, identified by the Client Handle, on which transactions (a.k.a., configuration installations, deletions, updates) may be performed. Other existing Request States will be unaffected by the new request state as they are independent (thus, no instances of configuration data within one Request State can be affected by DECs for another Request State as identified by the Client Handle). If the command-code is "Remove", then the PDP is commanding the PEP to delete the existing Request-State specified by the DEC message's Client Handle, thereby causing the PEP to issue a DRQ message for this Handle.
PDPはまた、新しい要求状態を開いたり、意思決定の国旗オブジェクトの要求ステートフラグを設定して意思決定を発行して出て行くものを削除するには、PEPを命令することができます。コマンドコードが「インストール」であれば、PDPは、新しい要求状態を作成し、そのための新しいクライアントハンドルを指定して、新たなREQメッセージを発行するか、そうでない場合には適切なエラー条件を指定して「失敗」RPTを発行するPEPを指令されます。各リクエストの状態は、トランザクション（別名、コンフィギュレーションのインストール、削除、更新）を実行することができる、クライアントハンドルによって識別され、独立した論理的に非重複の名前空間を表します。彼らは独立しているように、他の既存の要求は国が新しい要求状態によって影響を受けません（クライアントハンドルによって識別されるので、1つの要求状態内のコンフィギュレーション・データのインスタンスは、別の要求状態についてDECSによって影響を受けることができません）。コマンドコードが「削除」である場合には、PDPは、それによって、PEPは、このハンドルのためのDRQメッセージを発行させ、DECメッセージのクライアントハンドルによって指定された既存の要求ステートを削除するには、PEPを指令されます。
The PEP MUST acknowledge a DEC message and specify what action was taken by sending a RPT message with a "Success" or "Failure" Report-Type object with the Solicited Message Flag set in the COPS message header. This serves as an indication to the PDP that the requestor (e.g., H.323 server) can be notified whether the request has been accepted by the network or not. If the PEP needs to reject the DEC operation for any reason, a RPT message is sent with a Report-Type with the value "Failure" and optionally a Client Specific Information object specifying the policy data that was rejected. Under such solicited report failure conditions, the PEP MUST always rollback to its previously installed (good) state as if the DEC never occurred. The PDP is then free to modify its decision and try again.
PEPは、DECメッセージを確認し、COPSメッセージヘッダーに設定要請メッセージ旗と「成功」または「失敗」レポート-TypeオブジェクトをRPTメッセージを送信することにより、撮影されたアクションを指定しなければなりません。これは、要求者（例えば、H.323サーバ）要求は、ネットワークによって受け入れされたか否かを通知することができる。PDPへの指示として役立ちますPEPは、何らかの理由で12月の操作を拒絶する必要がある場合、RPTメッセージが値「失敗」と、必要に応じて拒否されたポリシーデータを指定し、クライアント固有の情報オブジェクトを使用したレポート・タイプで送信されます。 DECが発生したことがないかのような勧誘レポート故障条件の下で、PEPは常にその以前にインストール（良い）状態にロールバックする必要があります。 PDPは、その決定を変更し、再度お試しは無料です。
The PEP can report to the PDP the current status of any installed request state when appropriate. This information is sent in a Report-State (RPT) message with the "Accounting" flag set. The request state that is being reported is identified via the associated Client Handle in the report message.
PEPは、PDPに取り付けられているすべての要求状態適切な場合の現在の状況を報告することができます。この情報は、「会計」フラグが設定されたレポートステート（RPT）メッセージで送信されます。報告されているリクエストの状態は、報告メッセージに関連付けられたクライアントハンドルを介して識別されます。
Finally, Client-Close (CC) messages are used to cancel the corresponding Client-Open message. The CC message informs the other side that the client-type specified is no longer supported.
最後に、クライアント・クローズ（CC）メッセージは、対応するクライアントのオープンメッセージをキャンセルするために使用されています。 CCメッセージは、指定したクライアントタイプがサポートされなくなりました反対側に通知します。
When communication is lost between PEP and PDP, the PEP attempts to re-establish the TCP connection with the PDP it was last connected to. If that server cannot be reached, then the PEP attempts to connect to a secondary PDP, assumed to be manually configured (or otherwise known) at the PEP.
通信がPEPとPDPの間で失われた場合には、PEPは、それが接続された最後のPDPとのTCP接続を再確立しようとします。そのサーバに到達できない場合、PEPは、二次PDPに接続しようと、PEPで手動で設定（または他の知られている）とします。
When a connection is finally re-established with a PDP, the PEP sends a OPN message with a <LastPDPAddr> object providing the address of the most recent PDP for which it is still caching decisions. If no decisions are being cached on the PEP (due to reboot or TTL timeout of state) the PEP MUST NOT include the last PDP address information. Based on this object, the PDP may request the PEP to re-synch its current state information (by issuing a COPS SSQ message). If, after re-connecting, the PDP does not request synchronization, the client can assume the server recognizes it and the current state at the PEP is correct, so a REQ message need not be sent. Still, any state changes which occurred at the PEP that the PEP could not communicate to the PDP due to communication having been lost, MUST be reported to the PDP via the PEP sending an updated REQ message. Whenever re-synchronization is requested, the PEP MUST reissue any REQ messages for all known Request-States and the PDP MUST issue DEC messages to delete either individual PRIDs or prefixes as appropriate to ensure a consistent known state at the PEP.
接続は最終的にはPDPで再確立されると、PEPは、それはまだ決断をキャッシュされている最新のPDPのアドレスを提供する<LastPDPAddr>オブジェクトにOPNメッセージを送信します。何の決定はPEPにキャッシュされていないされている場合（起因する状態のタイムアウトを再起動するか、TTLに）PEPは、最後のPDPアドレス情報を含んではいけません。このオブジェクトに基づいて、PDPは（COPS SSQメッセージを発行することにより）現在の状態情報、同期を再ためにPEPを要求することができます。再接続した後、PDPが同期を要求していない、場合、クライアントは、サーバがそれを認識し、PEPでの現在の状態が正しいので、REQメッセージが送信される必要がないと仮定することができます。依然として、PEPが失われた原因通信にPDPと通信できなかったことをPEPに発生した状態変化は、更新されたREQメッセージを送信PEPを介してPDPに報告しなければなりません。再同期が要求されるたびに、PEPは、PEPで一貫性のある既知の状態を確保するために、必要に応じて、個々のPRIDsまたはプレフィックスのいずれかを削除するには、12月のメッセージを発行しなければなりませんすべての既知のRequest-米国およびPDPのための任意のREQメッセージを再発行する必要があります。
While the PEP is disconnected from the PDP, the active request-state at the PEP is to be used for policy decisions. If the PEP cannot re-connect in some pre-specified period of time, all installed Request-States are to be deleted and their associated Handles removed. The same holds true for the PDP; upon detecting a failed TCP connection, the time-out timer is started for all Request-States associated with the PEP and these states are removed after the administratively specified period without a connection.
PEPは、PDPから切り離されている間、PEPでアクティブ要求状態は、ポリシー決定に使用されます。 PEPは、時間のいくつか事前に指定した期間内に再接続できない場合は、インストールされているすべての要求-国は、削除されるべきであり、それに関連するハンドルを除去しました。同じことは、PDPにも当てはまります。失敗したTCP接続を検出すると、タイムアウトタイマーは、PEPに関連するすべての要求、国のために開始され、これらの状態は接続せずに、管理上、一定期間後に削除されます。
The COPS protocol [COPS], from which this document derives, describes the mandatory security mechanisms that MUST be supported by all COPS implementations. These mandatory security mechanisms are used by the COPS protocol to transfer opaque information from PEP to PDP and vice versa in an authenticated and secure manner. COPS for Policy Provisioning simply defines a structure for this opaque information already carried by the COPS protocol. As such, the security mechanisms described for the COPS protocol will also be deployed in a COPS-PR environment, thereby ensuring the integrity of the COPS-PR information being communicated. Furthermore, in order to fully describe a practical set of structured data for use with COPS-PR, a PIB (Policy Information Base) will likely be written in a separate document. The authors of such a PIB document need to be aware of the security concerns associated with the specific data they have defined. These concerns MUST be fully specified in the security considerations section of the PIB document along with the required security mechanisms for transporting this newly defined data.
この文書が由来するCOPSプロトコル[COPS]は、すべてのCOPS実装によってサポートしなければならない必須のセキュリティ機構が記載されています。これら必須のセキュリティメカニズムは、認証され、安全な方法でPDP及びその逆にPEPから不透明な情報を転送するためにCOPSプロトコルによって使用されます。ポリシーのプロビジョニングのためのCOPSは、単に既にCOPSプロトコルによって運ばれ、この不透明な情報のための構造を定義します。このように、COPSプロトコルに記載されているセキュリティメカニズムは、それによって通信されるCOPS-PR情報の完全性を保証する、COPS-PR環境に配置されます。さらに、完全にCOPS-PR、PIB（ポリシー情報ベース）で使用するための構造化されたデータの実際的なセットを記述するためにおそらく別の文書に書き込まれます。このようPIB文書の作成者は、彼らが定義した特定のデータに関連するセキュリティ上の懸念を認識する必要があります。これらの懸念は完全にこの新しく定義されたデータを転送するために必要なセキュリティメカニズムとともにPIB文書のセキュリティの考慮事項のセクションで指定する必要があります。
COPS for Policy Provisioning follows the same IANA considerations for COPS objects as the base COPS protocol [COPS]. COPS-PR has defined one additional Decision Flag value of 0x02, extending the COPS base protocol only by this one value. No new COPS Client- Types are defined by this document.
ポリシーのプロビジョニングのためのCOPSはCOPSに対して同じIANAの考慮事項は、ベースCOPSプロトコル[COPS]などのオブジェクト以下。 COPS-PRは、これだけの値でCOPSベースのプロトコルを拡張、0×02の一つの追加判定フラグの値を定義しています。タイプのClient新しいCOPSは、この文書で定義されていません。
COPS-PR also introduces a new object number space with each object being identified by its S-Num and S-Type value pair. These objects are encapsulated within the existing COPS Named ClientSI or Named Decision Data objects [COPS] and, therefore, do not conflict with any
COPS-PRはまた、S-numとS型と値のペアによって識別される各オブジェクトに新しいオブジェクト番号空間を導入します。これらのオブジェクトはClientSIという名前の既存のCOPSまたは名前付き判定データオブジェクト[COPS]内にカプセル化されており、そのため、いずれかと競合しません
assigned numbers in the COPS base protocol. Additional S-Num and S-Type pairs can only be added to COPS-PR using the IETF Consensus rule as defined in [IANA]. These two numbers are always to be treated as a pair, with one or more S-Types defined per each S-Num. This document defines the S-Num values 1-6 and the S-Type 1 for each of these six values (note that the S-Type value of 2 is reserved for transport of XML encoded data). A listing of all the S-Num and S-Type pairs defined by this document can be found in sections 4.1-4.6.
COPSに割り当てられた番号は、プロトコルの基礎。 [IANA]で定義されるように、追加のS-numとS型ペアのみIETFコンセンサスルールを使用して、COPS-PRに加えることができます。これらの二つの数字は、常に各S-民ごと定義された1つまたはそれ以上のS-タイプと、ペアとして扱われます。この文書では、S-民は1~6の値およびこれら6つの値のそれぞれについてS-1型（2のS-Type値は、XML符号化データのトランスポートのために予約されていることに注意）を定義します。この文書で定義されたすべてのS-numとS型のペアのリストは、セクション4.1から4.6に記載されています。
Likewise, additional Global Provisioning error codes and Class-Specific Provisioning error codes defined for COPS-PR can only be added with IETF Consensus. This document defines the Global Provisioning error code values 1-11 in section 4.4 for the Global Provisioning Error Object (GPERR). This document also defines the Class-Specific error code values 1-13 in section 4.5 for the Class Provisioning Error Object (CPERR).
同様に、追加のグローバルプロビジョニングエラーコードとCOPS-PRのために定義されたクラス固有のプロビジョニングのエラーコードは、IETFコンセンサスを追加することができます。この文書では、グローバルプロビジョニング・エラー・コードは、グローバルプロビジョニング・エラー・オブジェクト（GPERR）のためのセクション4.4で1-11値規定します。この文書は、クラス固有のエラーコードは、クラスプロビジョニング・エラー・オブジェクト（CPERR）のためのセクション4.5で1-13値規定します。
This document has been developed with active involvement from a number of sources. The authors would specifically like to acknowledge the valuable input given by Michael Fine, Scott Hahn, and Carol Bell.
この文書では、多数のソースからの積極的な関与で開発されました。著者は、特にマイケル・ファイン、スコット・ハーン、そしてキャロル・ベルによって与えられた貴重な情報を確認したいと思います。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[COPS]ボイル、J.、コーエン、R.、ダーラム、D.、ヘルツォーク、S.、ラジャ、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[RAP] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[COPRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
【COPRSVP】ボイル、J.、コーエン、R.、ダラム、D.、ヘルツォーク、S.、ラージャ、R.およびA. Sastryは、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[ASN1] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.
[ASN1]情報処理システム - 開放型システム間相互接続、標準化、国際標準8824、1987年12月のための国際組織「抽象構文記法1（ASN.1）の仕様」。
[BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987).
[BER]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）のための基本的な符号化規則、国際標準化機構の仕様。国際標準8825、（12月、1987）。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service," RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ、" RFC 2475、1998年12月。
[SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information SPPI", Work in Progress.
[SPPI] McCloghrie、K.、ファイン、M.、Seligson、J.、チャン、K.、ハーン、S.、Sahita、R.、スミス、A.及びF. Reichmeyer、 "ポリシーのプロビジョニング情報SPPIの構造" 、進行中の作業。
[V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2(SMIv2)", STD 58, RFC 2578, April 1999.
【V2SMI] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、STD 58、RFC 2578は、 1999年4月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[IANA] Alvestrand, H. and T. Narten, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[URN] Moats, R., "Uniform Resource Names (URN) Syntax", RFC 2141, May 1997.
[URN]堀、R.、 "統一リソース名（URN）構文"、RFC 2141、1997年5月。
[XML] World Wide Web Consortium (W3C), "Extensible Markup Language (XML)," W3C Recommendation, February, 1998, http://www.w3.org/TR/1998/REC-xml-19980210.
[XML] World Wide Webコンソーシアム（W3C）、 "拡張マークアップ言語（XML）、" W3C勧告、1998年2月、http://www.w3.org/TR/1998/REC-xml-19980210。
Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821
クォックホーチャンノーテルネットワークス株式会社600テクノロジーパークドライブビレリカ、MA 01821
Phone: (978) 288-8175 EMail: khchan@nortelnetworks.com
電話：（978）288-8175 Eメール：khchan@nortelnetworks.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
デビッド・ダーラムインテル2111 NE 25日アベニューヒルズボロ、OR 97124
Phone: (503) 264-6232 Email: david.durham@intel.com
電話：（503）264-6232 Eメール：david.durham@intel.com
Silvano Gai Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706
シルヴァーノガイシスコシステムズ社170タスマン博士はカリフォルニア州サンノゼ95134-1706
Phone: (408) 527-2690 EMail: sgai@cisco.com
電話：（408）527-2690 Eメール：sgai@cisco.com
Shai Herzog IPHighway Inc. 69 Milk Street, Suite 304 Westborough, MA 01581
シャイヘルツォークIPHighway株式会社69ミルク・ストリート、スイート304ウェストボロ、MA 01581
Phone: (914) 654-4810 EMail: Herzog@iphighway.com
電話：（914）654-4810 Eメール：Herzog@iphighway.com
Keith McCloghrie
キースMcCloghrie
Phone: (408) 526-5260 EMail: kzm@cisco.com
電話：（408）526-5260 Eメール：kzm@cisco.com
Francis Reichmeyer PFN, Inc. University Park at MIT 26 Landsdowne Street Cambridge, MA 02139
フランシスReichmeyer PFN、MIT 26ランズダウン・ストリート、ケンブリッジ、MA 02139で株式会社ユニバーシティパーク
Phone: (617) 494 9980 EMail: franr@pfn.com
電話：（617）494 9980 Eメール：franr@pfn.com
John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054
ジョンSeligsonノーテルネットワークス株式会社4401グレートアメリカパークウェイサンタクララ、CA 95054
Phone: (408) 495-2992 Email: jseligso@nortelnetworks.com
電話：（408）495-2992 Eメール：jseligso@nortelnetworks.com
Raj Yavatkar
ラジYawatkar
Phone: (503) 264-9077 EMail: raj.yavatkar@intel.com
電話：（503）264-9077 Eメール：raj.yavatkar@intel.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
アンドリュー・スミスアレグロ・ネットワーク6399サンイグナチオアベニュー。サンノゼ、CA 95119、USA
EMail: andrew@allegronetworks.com
メールアドレス：andrew@allegronetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。