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
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)
用于策略设置的COPS使用（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）协议支持策略提供（COPS-PR）。本规范独立于所提供的策略类型（QoS、安全性等），但侧重于用于在PDP和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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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........................................................... 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.
PRC供应类。策略数据的一种类型。PRI配置实例。中国的一个例子。PIB政策信息库。政策信息数据库。PDP政策决策点。见[说唱]。政治公众人物政策执行点。见[说唱]。PRID配置实例标识符。唯一标识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）工作组已将COPS（公共开放策略服务）协议[COPS]定义为一种可扩展协议，允许策略服务器（PDP）将策略决策传达给网络设备（PEP）。COP旨在支持多种类型的策略客户端。
COPS is a query/response protocol that supports two common models for policy control: Outsourcing and Configuration.
COPS是一种查询/响应协议，支持两种常见的策略控制模型：外包和配置。
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.
外包模型解决政治公众人物中需要即时政策决策（授权）的事件类型。在外包场景中，政治公众人物将责任委托给外部策略服务器（PDP），以代表其做出决策。例如，在COPS对RSVP[COPRSVP]的使用中，当RSVP保留消息到达时，政治公众人物必须决定是接受还是拒绝请求。它可以通过向其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).
另一方面，COPS配置模型（此处称为供应模型）未假设PEP事件与PDP决策之间存在1:1的直接相关性。PDP可主动提供PEP，以响应外部事件（例如用户输入）、PEP事件及其任何组合（N:M相关性）。供应可以批量执行（例如，整个路由器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实时动态调整外包模型的进度，但PDP在PEP的许多可配置方面以某种灵活的时间调整供应模型的进度。
Edge Device Policy Server
+--------------+ +-----------+ +-----------+
| | | | | External |
| | COPS | | | Events |
| +-----+ | REQ() | +-----+ | +---+-------+
| | |----|----------|->| | | |
| | PEP | | | | PDP |<-|---------+
| | |<---|----------|--| | |
| +-----+ | COPS | +-----+ |
| | DEC() | |
+--------------+ +-----------+
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中，策略请求描述政治公众人物及其可配置参数（而不是操作事件）。如果这些基本参数发生更改，将发送更新的请求。因此，很少发出请求。决策不一定直接映射到请求，通常在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、安全性等）。相反，它侧重于用于在PDP和PEP之间传递供应信息的机制和约定。本文档中假设的数据模型基于定义政策数据的政策信息库（PIB）概念。给定的政策领域可能有一个或多个PIB，不同的政策领域可能有不同的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.
为了支持包含多个PDP的模型，这些PDP控制单个PEP上的非重叠策略区域，PEP向PDP指定的客户端类型对于所管理的策略区域是唯一的。给定策略区域（例如，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客户端类型标识）的策略客户端和服务器之间有一个单一连接，因此它保证在任何给定时间只有一台服务器更新特定的策略配置。当PEP通过COP连接到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检测到当前有效的配置策略中需要进行更改，则PDP将策略中的更改（安装、更新和/或删除）发送给PEP，并且PEP适当地更新其本地配置。
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.
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.translate error, please retry
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携带的数据是一组策略数据。协议采用命名的数据结构，称为策略信息库（PIB），以识别从PDP“推送”到PEP以提供策略或从PEP作为通知发送到PDP的未经请求的策略信息的类型和用途。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:
PIB可以描述为一个概念树名称空间，其中树的分支表示数据或资源调配类（PRC）的结构，而叶子表示资源调配实例（PRI）的各种实例化。对于任何给定的数据结构（PRC），可能存在多个数据实例（PRI）。例如，如果要安装多个访问控制过滤器，PRC可能表示通用访问控制过滤器类型，每个PRI可能表示要应用的单个访问控制过滤器。该树可以表示为如下所示：
-------+-------+----------+---PRC--+--PRI
| | | +--PRI
| | |
| | +---PRC-----PRI
| |
| +---PRC--+--PRI
| +--PRI
| +--PRI
| +--PRI
| +--PRI
|
+---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<Named ClientSI>或<Named Decision Data>对象中，用于标识类的特定实例。
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) 可以将其他PRC添加到PIB或已弃用的现有PRC。
(2) Attributes can be added to, or deprecated from, an existing PRC.
(2) 属性可以添加到现有PRC中，也可以从现有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的机制都允许PDP和PEP之间的互操作性，即使一方使用新版本的PIB，而另一方使用旧版本。
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.
只需修改文档并添加额外的PRC，即可使用新的PRC扩展已发布的PIB。这些额外的PRC很容易通过模块PRID前缀下的新PRID识别。
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的政治公众人物正在由实施旧PIB的PDP配置，政治公众人物将不会收到新PRC的任何实例。如果政治公众人物正在实施旧的政治公众人物身份证，而PDP正在实施新的政治公众人物身份证，政治公众人物可能会收到新的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.
类似地，现有PRC也可以从PIB中弃用。在这种情况下，PEP将忽略由实现旧（未弃用）版本PIB的PDP发送给它的任何PRI。实现新版本PIB的PDP不会发送任何已弃用类的实例。
A PIB can be modified to deprecate existing attributes of a PRC or add new ones.
PIB可以修改为不推荐PRC的现有属性或添加新属性。
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值，以便实现不同版本PIB的PDP和PEP可以互操作。
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空值。对于未弃用的属性，接收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添加新属性时，必须在现有属性之后依次添加这些新属性。接收到属性超过预期的PRI的PEP必须忽略附加属性并向PDP发送警告。
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）通常包含为PRC定义的每个属性的值，PRC是PRC的实例，并且在PEP上给定的COPS客户端类型和请求状态范围内，由配置实例标识符（PRI）唯一标识。PRI支持以下COPS操作：
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的PRID对象和一个带有新值/更新值的编码配置实例数据（EPD）对象。PRID值必须唯一标识单个PRI（即PRID前缀或PRC值是非法的）。只需使用更新的EPD数据重新安装相同的PRI，即可实现对现有PRI的更新。
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的实例。它包括一个参数，一个PRID对象，用于命名要删除的单个PRI，或一个PRID前缀，用于命名一个或多个完整的PRI类。基于前缀的删除支持高效的批量策略删除。移除未知/不存在的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消息关联的客户端句柄对于该客户端必须是唯一的。客户端句柄用于标识特定的请求状态。因此，一个客户端可能会打开多个配置请求状态，每个状态都由其句柄唯一标识。不同的请求状态用于将类似命名的配置信息隔离到非重叠上下文（或逻辑隔离的名称空间）中。因此，命名信息的实例相对于特定客户机类型是唯一的，并且相对于该客户机类型的特定请求状态也是唯一的，即使该信息在其他请求状态中被类似地标识（即，使用相同的PRID）。因此，客户端句柄也是所传送的配置信息的实例标识的一部分。
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.
配置请求消息用作从PEP到PDP的请求，用于提供PDP可能对PEP具有的策略数据，例如访问控制列表等。这包括PDP在接收到REQ时可能具有的策略以及任何未来策略数据或对该数据的更新。
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
配置请求消息应包括配置客户端信息，以向PDP提供有关PEP的特定于客户端的配置或能力信息。由
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可以安装和实施哪些类型的策略。第5节描述了封装在一个或多个名为ClientSI对象的COP中的信息格式。注意，响应于从PDP接收到同步状态请求（SSQ）消息，生成配置请求消息并将其发送给PDP。类似地，由于PEP内部状态的本地修改，PEP也可以随时生成更新的配置请求消息（使用与当前更新的原始请求相同的客户端句柄值）并发送给PDP。这样，PDP将始终与政治公众人物的相关内部状态同步。
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>]
<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-PR请求中不包括Int、OUT Int和LPDPDecisions中的COPS对象。
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消息从PDP发送到策略供应客户端，以响应从PEP接收到的REQ消息。客户端句柄必须与相应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消息也可在原始DEC消息之后的任何时间发送，以向政治公众人物提供附加/更新的策略信息，而无需在COPS消息头中设置请求消息标志（因为它们是未经请求的决定）。
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消息必须首先包含任何必需的删除决定，然后是任何必需的安装决定。这用于解决优先级问题，而不是时间问题：remove决策删除它指定的内容，但同一消息中安装的项目除外。
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.
PDP还可以使用DEC消息命令PEP打开新的请求状态或删除由客户端句柄标识的现有请求状态。为此，COPS-PR为COPS决策标志对象定义了一个新标志。COPS-PR客户端类型将使用标志0x02，以下称为“请求状态”标志。在COPS决策标志对象中设置了请求状态标志的安装决策（决策标志：Command Code=Install）将导致PEP发出具有新客户端句柄的新请求，或者在COPS报告消息中指定相应的错误。在COPS决策标志对象中设置了请求状态标志的删除决策（决策标志：Command Code=Remove）将导致PEP针对DEC消息中客户端句柄标识的请求状态发送COPS Delete Request State（DRQ）消息。只要在DEC消息中的COPS决策标志对象中设置了请求状态标志，相应的决策中就不能包含任何COPS命名的决策数据对象（因为它不用于此决策标志）。请注意，每个DEC消息只能出现一个带有请求状态标志的决策，如果存在，这必须是该消息中的唯一决策。如下文所述，政治公众人物必须以相应的征求RPT回复每个DEC。
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将回滚到其先前的良好状态，这是最后一次成功的DEC事务（如果有）。这允许PDP仅在可以安装其他策略的情况下删除某些策略。DEC消息的格式如下：
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
<Decision Message> ::= <Common Header>
<Client Handle>
*(<Decision>) | <Error>
[<Integrity>]
<Decision> ::= <Context>
<Decision: Flags>
[<Named Decision Data: Provisioning >]
<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-PR客户端类型不支持其他类型的COPS决策数据对象（例如，无状态、替换）。如果Decision Flags对象命令代码为NULL（意味着此时没有要安装的配置信息），或者如果Decision Flags对象中设置了请求状态标志，则命名的Decision数据对象不得包含在决策中。
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消息的响应，策略设置客户端必须将设置了请求消息标志的RPT消息发送回PDP，以通知PDP所采取的操作。
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消息从策略设置客户端发送到PDP，以报告与设置的策略相关的会计信息，或通知PDP与设置客户端相关的PEP（报告类型=‘会计’）的更改。
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还用作一种机制，告知PDP PEP响应DEC消息所采取的行动。例如，作为对“安装”决定的响应，PEP通知PDP是否安装了策略数据（报告类型=“成功”）（报告类型=“失败”）。响应DEC消息的报告必须在其COPS消息头中设置请求消息标志。每个请求的RTP必须按照接收DEC消息的顺序发送相应的DEC。在请求失败的情况下，预计政治公众人物将回滚到其先前的（良好）状态，就好像错误的DEC交易没有发生一样。政治公众人物必须始终以请求的RPT响应DEC，即使是响应空DEC，在这种情况下，报告类型将为“成功”。
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>]
<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 |
+---------------+---------------+---------------+---------------+
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-Type与基本COPS对象中使用的C-Num和C-Type类似。区别在于S-Num和S-Type仅用于COPS-PR客户端，并封装在现有的名为ClientSI或命名决策数据对象的COPS中。S-Num标识对象的一般用途，S-Type描述用于对象的特定编码。本文档中的所有对象描述和示例都使用基本编码规则作为编码类型（S-type=1）。将来可以为剩余的S类型定义额外的编码（例如，可以使用额外的S类型携带基于XML字符串的编码[XML]作为PRI实例数据的EPD，其中URN标识PRC[URN]，XPointers将用于PRI）。
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.
Length是两个八位字节的值，用于描述组成对象的八位字节数（包括标头）。如果以八位字节为单位的长度不在32位字边界上，则必须将填充添加到对象的末尾，以便在将对象发送到线上之前将其与下一个32位边界对齐。在接收端，只需将当前对象的指定对象长度四舍五入到下一个32位边界即可找到后续对象边界。填充的值必须全部为零。
S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable.
S-Num=1（完整PRID），S-Type=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值使用类型/长度/值（TLV）格式和初始子标识符打包进行编码，初始子标识符打包由SNMP PDU中用于对象标识符的二进制编码规则[BER]指定。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Instance Identifier |
+---------------+---------------+---------------+---------------+
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将编码如下（十六进制值）：
06 07 2B 06 01 02 02 08 01
06 07 2B 06 01 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
00 0D-长度01-编号01-S型（完整PRID）06 07 2B 06 01 02 08 01-编码PRID 00-填充
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
注意：当编码由SMI[V2SMI]和SPPI[SPPI]定义的xxxTable的xxxEntry对象类型时，OID将包含xxxEntry OID之前的所有子标识符，但不包含xxxEntry序列中属性的列标识符。最后一个（后缀）标识符是整个数据库实例的索引
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.
xxxEntry，包括EPD中编码的属性序列（定义如下）。就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.
标量（非列）值OID的PRID直接编码为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.
某些操作（如决策删除）可以通过指定PRID前缀来优化，目的是将请求的操作应用于与前缀匹配的所有PRI（例如，相同PRC的所有实例）。PRID前缀对象只能在COPS协议<Remove Decision>操作中使用，在这种情况下，使用类前缀而不是一系列单独的<Remove Decision>操作执行批量决策删除可能更为理想。其他COPS操作，例如，<Install Decision>操作始终需要单独的PRID规范。
S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable.
S-Num=2（前缀PRID），S-Type=1（BER），长度=变量。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PPRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
... ...
| Prefix PRID |
... ...
+---------------+---------------+---------------+---------------+
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):
继续上一个示例，等于1.3.6.1.2.2的前缀PRID将编码如下（十六进制值）：
06 05 2B 06 01 02 02
06 05 2B 06 01 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 - Length
02 - S-Num = Prefix PRID
01 - S-Type = BER
06 05 2B 06 01 02 02 - Encoded Prefix PRID
00 - Padding
S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable.
S-Num=3（EPD），S-Type=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.
此对象用于携带配置实例的编码值。PRI值包含构成类的属性的所有单个值（对应于SMI的xxxEntry对象类型，该对象类型定义了构成表[V2SMI][SPPI]的属性序列），它被编码为一系列TLV子组件。每个子组件表示单个属性的值，并按照BER进行编码。请注意，在[V2SMI]中定义时，EPD中非标量（多个）属性的顺序由其各自的柱状后缀决定。因此，具有最小柱状体后缀的属性将首先出现，具有最大数量柱状体后缀的属性将最后出现。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = EPD | S-Type = BER |
+---------------+---------------+---------------+---------------+
| BER Encoded PRI Value |
+---------------+---------------+---------------+---------------+
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 }
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."
ipv4FilterTable Ipv4FilterEntry MAX-ACCESS的对象类型语法序列不可访问状态当前描述“筛选器定义。数据包必须匹配筛选器中的所有字段。可以为那些不相关的字段指定通配符。”
::= { ipv4FilterIpFilter 1 }
::= { ipv4FilterIpFilter 1 }
ipv4FilterEntry OBJECT-TYPE SYNTAX Ipv4FilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An instance of the filter class."
ipv4FilterEntry对象类型语法ipv4FilterEntry MAX-ACCESS不可访问状态当前描述“筛选器类的实例”
INDEX { ipv4FilterIndex }
索引{ipv4FilterIndex}
::= { ipv4FilterTable 1 }
::= { 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
}
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对象类型语法Unsigned32 MAX-ACCESS读写状态当前描述“用于在所有筛选器中唯一标识此筛选器的整数索引。”
::= { ipv4FilterEntry 1 }
::= { ipv4FilterEntry 1 }
ipv4FilterDstAddr OBJECT-TYPE
ipv4FilterDstAddr对象类型
SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address to match against the packet's destination IP address."
语法IpAddress MAX-ACCESS读写状态当前描述“要与数据包的目标IP地址匹配的IP地址。”
::= { ipv4FilterEntry 2 }
::= { 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
IPV4FilterdStatAddressMask对象类型语法IpAddress MAX-ACCESS读写状态当前描述“用于匹配目标IP地址的掩码。掩码中的零位表示
the address always matches."
地址始终匹配。”
::= { ipv4FilterEntry 3 }
::= { 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."
IPV4FiltersRCAddress对象类型语法IpAddress MAX-ACCESS读写状态当前描述“要与数据包的源IP地址匹配的IP地址。”
::= { ipv4FilterEntry 4 }
::= { ipv4FilterEntry 4 }
ipv4FilterSrcAddrMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "A mask for the matching of the source IP address."
IPV4FiltersRCAddressMask对象类型语法IpAddress MAX-ACCESS读写状态当前描述“用于匹配源IP地址的掩码”
::= { ipv4FilterEntry 5 }
::= { 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对象类型语法整数32（-1 | 0..63）MAX-ACCESS读写状态当前描述“数据包中DSCP可以具有并匹配的值。值-1表示尚未定义特定DSCP值，因此所有DSCP值都被视为匹配。”
::= { ipv4FilterEntry 6 }
::= { 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对象类型语法Integer32（0..255）MAX-ACCESS读写状态当前描述“要与数据包协议匹配的IP协议。值为零表示全部匹配。”
::= { ipv4FilterEntry 7 }
::= { ipv4FilterEntry 7 }
ipv4FilterDstL4PortMin OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-write
ipv4FilterDstL4PortMin对象类型语法整数32（0..65535）最大访问读写
STATUS current DESCRIPTION "The minimum value that the packet's layer 4 destination port number can have and match this filter."
STATUS current DESCRIPTION“数据包的第4层目标端口号可以具有并与此筛选器匹配的最小值。”
::= { ipv4FilterEntry 8 }
::= { 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对象类型语法整数32（0..65535）MAX-ACCESS读写状态当前描述“数据包的第4层目标端口号可以具有并匹配此筛选器的最大值。”
::= { ipv4FilterEntry 9 }
::= { 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对象类型语法整数32（0..65535）最大访问读写状态当前描述“数据包的第4层源端口号可以具有并匹配此筛选器的最小值。”
::= { ipv4FilterEntry 10 }
::= { 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对象类型语法整数32（0..65535）MAX-ACCESS读写状态当前描述“数据包的第4层源端口号可以具有并匹配此筛选器的最大值。”
::= { ipv4FilterEntry 11 }
::= { 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对象类型语法TruthValue MAX-ACCESS读写状态当前描述“如果为false，则计算结果为否定。也就是说，有效匹配将被计算为不匹配，反之亦然。”
::= { ipv4FilterEntry 12 }
::= { 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/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)
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 - 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
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中返回。按照约定，对于不受支持的属性，将返回空值。在上一个示例中，不支持源端口号和目标端口号属性。
S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 8.
S-Num=4（GPERR），S-Type=1（用于BER），长度=8。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = GPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
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.
全局设置错误对象的格式与COPS[COPS]中的错误对象的格式相同，只是C-Num和C-Type替换为所示的S-Num和S-Type值。全局配置错误对象用于传递未映射到特定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.
AvailmelLow（1）Availmexhousted（2）Unknown.1Tag（3）-应在错误子代码字段中指定错误的标记类型。MaxMsgSizeExceeed（4）-COPS消息（事务）太大。未知错误（5）maxRequestStatesOpen（6）-PEP不能再创建请求状态（响应尝试打开新请求状态的DEC消息）。无效长度（7）-ASN.1对象长度不正确。invalidObjectPad（8）-对象未正确填充。unknownPIBData（9）-PDP提供的一些数据是PEP未知/不支持的（但格式正确）。PRC特定错误代码用于提供更多信息。unknownCOPSPRObject（10）-子代码（八位组2）包含未知对象的s-Num，（八位组3）包含未知对象的s-Type。格式错误的决策（11）-无法分析决策。
S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 8.
S-Num=5（CPERR），S-Type=1（用于BER），长度=8。
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = CPERR | S-Type = BER |
+---------------+---------------+---------------+---------------+
| Error-Code | Error Sub-code |
+---------------+---------------+---------------+---------------+
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.
特定于类的配置错误对象与COPS[COPS]中的错误对象具有相同的格式，只是C-Num和C-Type被显示的S-Num和S-Type值替换。类特定的错误对象用于传递与特定PRC相关的错误，并且必须具有关联的错误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.
PrispaceExpensed（1）-给定类中当前不能安装更多实例。priInstanceInvalid（2）-指定的类实例当前无效，无法安装或删除。attrValueInvalid（3）-为已标识属性指定的值非法。attrValueSupLimited（4）-为已标识属性指定的值是合法的，但设备当前不支持该值。attrEnumSupLimited（5）-为已标识属性指定的枚举是合法的，但设备当前不支持该枚举。AttrMaxLengtheExceed（6）-已标识属性的指定值的总长度超过设备限制。attrReferenceUnknown（7）-策略实例标识符指定的类实例不存在。priNotifyOnly（8）-该类当前仅支持由禁止安装决策的请求或报告消息使用。未知NPRC（9）-尝试安装PEP不支持的类的PRI。tooFewAttrs（10）-recvd PRI的属性少于所需的属性。InvalidaterType（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）-已删除PRI仍被其他（非）已删除PRI PRISSpecificError（13）引用-错误子代码字段包含PRC特定错误代码
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-Num=6（ErrorPRID），S-Type=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。标识符的编码和格式与PRID对象中的编码和格式完全相同，如第4.1节所述。
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.
策略设置客户端类型的命名决策数据对象封装的格式取决于决策的类型。Install和Remove是两种类型的决策，它们规定了命名为决策数据对象的COPS的内部格式，并要求其存在。当未设置决策标志时，Install和Remove分别指COPS决策标志对象中指定的“Install”和“Remove”命令代码。通常，数据由一个或多个绑定组成。每个绑定都关联一个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>>
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>)
<Install Decision> ::= *(<PRID> <EPD>)
<Remove Decision> ::= *(<PRID>|<PPRID>)
<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>)>
<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'.
RPT消息中使用名为ClientSI的COPS对象和附带的COPS报告类型对象，以封装从PEP到PDP的COPS-PR报告信息。报告类型可以是“成功”或“失败”，向PDP指示在PEP上成功或未成功安装/删除了一组特定的资源调配策略，或者是“记帐”。
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
报告类型可以是“成功”或“失败”，向PDP指示已在PEP上成功或未成功安装/删除了一组特定的配置策略。配置报告数据包括上述绑定以及全局和特定错误/警告信息。特定错误与特定实例相关联。对于“成功”报告类型，特定错误表示与已安装的特定策略相关的警告，但该策略未完全实现（例如，其参数已近似），如ErrorPRID对象所识别。对于“Failure”报告类型，这是特定于绑定的错误代码，同样由ErrorPRID对象标识。特定错误还可能包括到的常规<PRID><EPD>绑定
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.
以通用方式携带附加信息，以便更详细地描述特定错误/警告，并将其与错误的ErrorPRID对象关联。
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必须将其配置回滚到收到错误决策消息之前的最后一个正常事务。
The format for this data is encapsulated in the COPS Named ClientSI object as follows:
此数据的格式封装在名为ClientSI对象的COPS中，如下所示：
<Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
<Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
<report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
<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使用的已安装配置相关的统计或事件信息。该信息编码为一个或多个<PRID><EPD>绑定，通常描述从政治公众人物向PDP报告的会计信息。
The format for this data is encapsulated in the COPS Named ClientSI object as follows:
此数据的格式封装在名为ClientSI对象的COPS中，如下所示：
<Named ClientSI: Report> ::= <*(<PRID><EPD>)>
<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定义了一个可选的记帐计时器（AcctTimer）对象，用于COPS客户端接受消息。COPS-PR客户的定期会计报告也必须由该计时器进行调整。政治公众人物生成定期会计报告的频率不应超过COPS账户指定的期限。因此，新会计报告之间的期间应大于或等于会计报表中指定的期间（如果指定）。如果PDP未指定AcctTimer对象，则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连接，PEP发送一条客户机打开消息，指定COPS-PR客户机类型（客户机打开消息中的ClientSI对象的使用对于COPS-PR客户机目前尚未定义）。如果PDP支持指定的配置客户机类型，PDP将使用客户机接受（CAT）消息进行响应。如果客户端类型不受支持，PDP将向PEP返回一条客户端关闭（CC）消息，可能标识已知支持指定配置客户端类型策略的备用服务器。
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提供的信息应包括可用的客户端资源（例如，支持的类/属性）和默认策略配置信息以及现有策略的具体化数据。来自供应客户端的配置请求消息有两个用途。首先，鉴于PEP在其REQ中指定的信息，它是向PDP请求PDP当前可能具有的适合于PEP的任何供应配置数据，例如访问控制过滤器等。此外，只要PEP保持其请求状态打开（即，只要PEP不发送带有请求状态的客户端句柄的DRQ），配置请求有效地打开了一个通道，该通道将允许PDP根据PDP的决定向PEP异步发送策略数据。此异步数据可能是新策略数据，也可能是对以前发送的策略数据的更新。可通过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具有客户端的策略设置策略配置信息，则该信息将在DEC消息中返回给客户端，DEC消息包含COPS命名决策数据对象内的策略设置客户端策略数据，并在决策标志对象中指定“安装”命令代码。如果没有定义过滤器，DEC消息将简单地指定在决策标志对象中没有使用“NULL Decision”命令代码的过滤器。由于PEP必须在请求消息中指定客户端句柄，PDP必须处理客户端句柄并将其复制到相应的决策消息中。十二月的消息
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的任何配置信息，都必须由PDP发出，并在COPS消息头中设置请求消息标志。这是为了防止PEP超时REQ并删除客户端句柄。
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消息来添加新策略数据或更新/删除现有配置。PDP只需重新安装相同的配置信息实例（有效覆盖旧数据），即可更新PEP上安装的先前配置。当不再需要客户端句柄时，PEP负责移除该句柄，例如当接口关闭时，并通知PDP将通过COPS DRQ消息删除该客户端句柄。
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决策对象中的策略设置命名决策数据对象。状态信息的任何更新，例如在策略更改或呼叫中断的情况下，通过包含相同客户端句柄和更新的策略设置请求状态的后续未经请求的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
PDP还可以命令PEP打开一个新的请求状态，或者通过发出一个设置了决策标志对象的请求状态标志的决策来删除一个正在退出的请求状态。如果命令代码为“安装”，则PDP将命令PEP创建新的请求状态，并因此发出新的REQ消息，指定新的客户端句柄，或发出“故障”RPT，指定适当的错误条件。每个请求状态表示一个独立且逻辑上不重叠的名称空间，由客户端句柄标识，可以在该名称空间上执行事务（也称为配置安装、删除、更新）。其他现有请求状态将不受新请求状态的影响，因为它们是独立的（因此，一个请求状态中没有配置数据的实例）
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.
可能会受到DEC的影响（由客户端句柄标识的另一个请求状态）。如果命令代码为“删除”，则PDP命令PEP删除DEC消息的客户端句柄指定的现有请求状态，从而导致PEP为此句柄发出DRQ消息。
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.
政治公众人物必须确认DEC消息，并指定通过发送带有“成功”或“失败”报告类型对象的RPT消息（在COPS消息头中设置了请求的消息标志）所采取的操作。这用作向PDP指示可以通知请求者（例如，H.323服务器）该请求是否已被网络接受。如果政治公众人物出于任何原因需要拒绝DEC操作，则会发送RPT消息，其中包含一个值为“Failure”的报告类型，还可以选择一个特定于客户端的信息对象，指定被拒绝的策略数据。在这种请求报告失败的情况下，政治公众人物必须始终回滚到其先前安装（良好）的状态，就像DEC从未发生一样。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
当最终与PDP重新建立连接时，PEP发送一条OPN消息，其中包含一个<LastPDPAddr>对象，该对象提供其仍在缓存决策的最新PDP的地址。如果PEP上未缓存任何决策（由于状态重新启动或TTL超时），则PEP不得包含最后一个PDP地址信息。基于此对象，PDP可请求PEP重新同步其当前状态信息（通过发出COPS SSQ消息）。如果在重新连接后，PDP未请求同步，则客户端可以假定服务器识别该同步，并且PEP的当前状态正确，因此无需发送REQ消息。但是，政治公众人物无法沟通的政治公众人物发生的任何状态变化
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.
由于通信丢失，必须通过PEP向PDP报告，并发送更新的REQ消息。每当请求重新同步时，PEP必须针对所有已知的请求状态重新发出任何REQ消息，PDP必须发出DEC消息以删除单个PRID或前缀（视情况而定），以确保PEP的已知状态一致。
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实现必须支持的强制安全机制。COPS协议使用这些强制安全机制将不透明信息从PEP传输到PDP，反之亦然，以经过身份验证和安全的方式传输。用于策略设置的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协议[COPS]相同的IANA对COPS对象的注意事项。COPS-PR定义了一个额外的决策标志值0x02，仅通过这一值扩展COPS基本协议。本文档未定义新的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-Type值对标识。这些对象封装在名为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.
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.translate error, please retry
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协商一致的情况下添加。本文档在第4.4节中为全局设置错误对象（GPERR）定义了全局设置错误代码值1-11。本文件还定义了第4.5节中针对类配置错误对象（CPERR）的类特定错误代码值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.
本文件是在多个来源的积极参与下编写的。作者特别感谢Michael Fine、Scott Hahn和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]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，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.Guerin，“基于政策的准入控制框架”，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]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，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]信息处理系统-开放系统互连，“抽象语法符号1规范（ASN.1）”，国际标准化组织，国际标准88241987年12月。
[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（1987年12月）。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service," RFC 2475, December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service," RFC 2475, December 1998.translate error, please retry
[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.，Fine，M.，Seligson，J.，Chan，K.，Hahn，S.，Sahita，R.，Smith，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.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，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]Crocker，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]Moats，R.，“统一资源名称（URN）语法”，RFC 21411997年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]万维网联盟（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
Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821translate error, please retry
Phone: (978) 288-8175 EMail: khchan@nortelnetworks.com
电话：（978）288-8175电子邮件：khchan@nortelnetworks.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
大卫·达勒姆英特尔2111东北希尔斯伯勒25大道，或97124
Phone: (503) 264-6232 Email: david.durham@intel.com
电话：（503）264-6232电子邮件：大卫。durham@intel.com
Silvano Gai Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706
Silvano Gai Cisco Systems，Inc.170加利福尼亚州圣何塞塔斯曼博士，邮编95134-1706
Phone: (408) 527-2690 EMail: sgai@cisco.com
电话：（408）527-2690电子邮件：sgai@cisco.com
Shai Herzog IPHighway Inc. 69 Milk Street, Suite 304 Westborough, MA 01581
Shai Herzog IPHighway Inc.马萨诸塞州威斯特堡牛奶街69号304室01581
Phone: (914) 654-4810 EMail: Herzog@iphighway.com
电话：（914）654-4810电子邮件：Herzog@iphighway.com
Keith McCloghrie
基思·麦克洛赫里
Phone: (408) 526-5260 EMail: kzm@cisco.com
电话：（408）526-5260电子邮件：kzm@cisco.com
Francis Reichmeyer PFN, Inc. University Park at MIT 26 Landsdowne Street Cambridge, MA 02139
Francis Reichmeyer PFN，Inc.麻省理工学院大学公园马萨诸塞州剑桥兰德斯敦街26号02139
Phone: (617) 494 9980 EMail: franr@pfn.com
电话：（617）4949980电子邮件：franr@pfn.com
John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054
约翰·塞利格森北电网络公司，加利福尼亚州圣克拉拉大美洲大道4401号，邮编95054
Phone: (408) 495-2992 Email: jseligso@nortelnetworks.com
电话：（408）495-2992电子邮件：jseligso@nortelnetworks.com
Raj Yavatkar
拉吉·亚瓦卡尔
Phone: (503) 264-9077 EMail: raj.yavatkar@intel.com
Phone: (503) 264-9077 EMail: raj.yavatkar@intel.comtranslate error, please retry
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119, USA
Andrew Smith Allegro Networks美国加利福尼亚州圣何塞圣伊格纳西奥大道6399号，邮编95119
EMail: andrew@allegronetworks.com
EMail: 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编辑功能的资金目前由互联网协会提供。