RFC relevance of decision

As per Relevance of the word decision, we have this rfc below:

Network Working Group K.
Request for Comments: 3084 J.
Category: Standards Track Nortel
D.

S.
K.

S.

F.

R.

A.
Allegro
March 2001

COPS Usage for Policy Provisioning (COPS-PR

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (2001). All Rights Reserved

This document describes the use of the Common Open Policy
(COPS) protocol for support of policy provisioning (COPS-PR).
specification is independent of the type of policy being
(QoS, Security, etc.) but focuses on the mechanisms and
used to communicate provisioned information between PDPs and PEPs
The protocol extensions described in this document do not make
assumptions about the policy data model being communicated,
describe the message formats and objects that carry the
policy data

Chan, et al. Standards Track [Page 1]

RFC 3084 COPS-PR March 2001

Conventions used in this

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC-2119].

Table of

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

Chan, et al. Standards Track [Page 2]

RFC 3084 COPS-PR March 2001

PRC Provisioning Class. A type of policy data
PRI Provisioning Instance. An instance of a PRC
PIB Policy Information Base. The database of
information
PDP Policy Decision Point. See [RAP].
PEP Policy Enforcement Point. See [RAP].
PRID Provisioning Instance Identifier. Uniquely identifies
instance of a PRC

1.

The IETF Resource Allocation Protocol (RAP) WG has defined the
(Common Open Policy Service) protocol [COPS] as a scalable
that allows policy servers (PDPs) to communicate policy decisions
network devices (PEPs). COPS was designed to support multiple
of policy clients

COPS is a query/response protocol that supports two common models
policy control: Outsourcing and Configuration

The Outsourcing model addresses the kind of events at the PEP
require an instantaneous policy decision (authorization). In
outsourcing scenario, the PEP delegates responsibility to an
policy server (PDP) to make decisions on its behalf. For example,
COPS Usage for RSVP [COPRSVP] when a RSVP reservation
arrives, the PEP must decide whether to admit or reject the request
It can outsource this decision by sending a specific query to
PDP, waiting for its decision before admitting the
reservation

The COPS Configuration model (herein described as the
model), on the other hand, makes no assumptions of such direct 1:1
correlation between PEP events and PDP decisions. The PDP
proactively provision the PEP reacting to external events (such
user input), PEP events, and any combination thereof (N:
correlation). Provisioning may be performed in bulk (e.g.,
router QoS configuration) or in portions (e.g., updating a
marking filter).

Network resources are often provisioned based on relatively
SLAs (Service Level Agreements) at network boundaries. While
Outsourcing model is dynamically paced by the PEP in real-time,
Provisioning model is paced by the PDP in somewhat flexible
over a wide range of configurable aspects of the PEP

Chan, et al. Standards Track [Page 3]

RFC 3084 COPS-PR March 2001

Edge Device Policy
+--------------+ +-----------+ +-----------+
| | | | | External |
| | COPS | | | Events |
| +-----+ | REQ() | +-----+ | +---+-------+
| | |----|----------|->| | | |
| | PEP | | | | PDP |<-|---------+
| | |<---|----------|--| | |
| +-----+ | COPS | +-----+ |
| | DEC() | |
+--------------+ +-----------+

Figure 1: COPS Provisioning

In COPS-PR, policy requests describe the PEP and its
parameters (rather than an operational event). If a change
in these basic parameters, an updated request is sent. Hence
requests are issued quite infrequently. Decisions are
necessarily mapped directly to requests, and are issued
when the PDP responds to external events or PDP events (policy/
updates).

This document describes the use of the COPS protocol [COPS]
support of policy provisioning. This specification is
of the type of policy being provisioned (QoS, Security, etc.).
Rather, it focuses on the mechanisms and conventions used
communicate provisioned information between PDPs and PEPs.
data model assumed in this document is based on the concept
Policy Information Bases (PIBs) that define the policy data.
may be one or more PIBs for given area of policy and
areas of policy may have different sets of PIBs

In order to support a model that includes multiple
controlling non-overlapping areas of policy on a single PEP,
client-type specified by the PEP to the PDP is unique for the
of policy being managed. A single client-type for a given area
policy (e.g., QoS) will be used for all PIBs that exist in
area. The client should treat all the COPS-PR client-types
supports as non-overlapping and independent namespaces
instances MUST NOT be shared

The examples used in this document are biased toward QoS
Provisioning in a Differentiated Services (DiffServ) environment
However, COPS-PR can be used for other types of
policies under the same framework

Chan, et al. Standards Track [Page 4]

RFC 3084 COPS-PR March 2001

1.1. Why COPS for Provisioning

COPS-PR has been designed within a framework that is optimized
efficiently provisioning policies across devices, based on
requirements defined in [RAP]. First, COPS-PR allows for
transport of attributes, large atomic transactions of data,
efficient and flexible error reporting. Second, as it has a
connection between the policy client and server per area of
control identified by a COPS Client-Type, it guarantees only
server updates a particular policy configuration at any
time. Such a policy configuration is effectively locked, even
local console configuration, while the PEP is connected to a
via COPS. COPS uses reliable TCP transport and, thus, uses a
sharing/synchronization mechanism and exchanges
updates only. If either the server or client are rebooted (
restarted) the other would know about it quickly. Last, it
defined as a real-time event-driven communications mechanism
never requiring polling between the PEP and PDP

1.2. Interaction between the PEP and

When a device boots, it opens a COPS connection to its
PDP. When the connection is established, the PEP sends
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-
message size supported

In response, the PDP downloads all provisioned policies that
currently relevant to that device. On receiving the
policies, the device maps them into its local QoS mechanisms,
installs them. If conditions change at the PDP such that the
detects that changes are required in the provisioned
currently in effect, then the PDP sends the changes (installs
updates, and/or deletes) in policy to the PEP, and the PEP
its local configuration appropriately

If, subsequently, the configuration of the device changes (
removed, board added, new software installed, etc.) in ways
covered by policies already known to the PEP, then the
asynchronously sends this unsolicited new information to the
in an updated configuration request. On receiving this
information, the PDP sends to the PEP any additional
policies now needed by the PEP, or removes those policies that
no longer required

Chan, et al. Standards Track [Page 5]

RFC 3084 COPS-PR March 2001

2. Policy Information Base (PIB

The data carried by COPS-PR is a set of policy data. The
assumes a named data structure, known as a Policy Information
(PIB), to identify the type and purpose of unsolicited
information that is "pushed" from the PDP to the PEP
provisioning policy or sent to the PDP from the PEP as
notification. The PIB name space is common to both the PEP and
PDP and data instances within this space are unique within
scope of a given Client-Type and Request-State per TCP
between a PEP and PDP. Note that given a device might
multiple COPS Client-Types, a unique instance space is to
provided for each separate Client-Type. There is no sharing
instance data across the Client-Types implemented by a PEP,
if the classes being instantiated are of the same type and
the same instance identifier

The PIB can be described as a conceptual tree namespace where
branches of the tree represent structures of data or
Classes (PRCs), while the leaves represent various
of Provisioning Instances (PRIs). There may be multiple
instances (PRIs) for any given data structure (PRC). For example
if one wanted to install multiple access control filters, the
might represent a generic access control filter type and each
might represent an individual access control filter to be applied
The tree might be represented as follows

-------+-------+----------+---PRC--+--
| | | +--
| | |
| | +---PRC-----
| |
| +---PRC--+--
| +--
| +--
| +--
| +--
|
+---PRC---

Figure 2: The PIB

Instances of the policy classes (PRIs) are each identified by
Provisioning Instance Identifier (PRID). A PRID is a name,
in a COPS or Decision Data> object,
identifies a particular instance of a class

Chan, et al. Standards Track [Page 6]

RFC 3084 COPS-PR March 2001

2.1. Rules for Modifying and Extending

As experience is gained with policy based management, and as
requirements arise, it will be necessary to make changes to PIBs
Changes to an existing PIB can be made in several ways

(1) Additional PRCs can be added to a PIB or an existing
deprecated

(2) Attributes can be added to, or deprecated from, an
PRC

(3) An existing PRC can be extended or augmented with a new
defined in another (perhaps enterprise specific) PIB

The rules for each of these extension mechanisms is described in
sub-section. All of these mechanisms for modifying a PIB allow
interoperability between PDPs and PEPs even when one party is using
new version of the PIB while the other is using an old version

Note that the SPPI [SPPI] provides the authoritative rules
updating BER encoded PIBs. It is the purpose of the
section to explain how such changes affect senders and receivers
COPS messages

2.2. Adding PRCs to, or deprecating from, a

A published PIB can be extended with new PRCs by simply revising
document and adding additional PRCs. These additional PRCs
easily identified with new PRIDs under the module's PRID Prefix

In the event that a PEP implementing the new PIB is being
by a PDP implementing the old PIB, the PEP will simply not
any instances of the new PRC. In the event that the PEP
implementing the old PIB and the PDP the new one, the PEP may
PRIs for the new PRC. Under such conditions, the PEP MUST return
error to the PDP, and rollback to its previous (good) state

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
(non-deprecated) version of the PIB. A PDP implementing the
version of the PIB simply does not send any instances of
deprecated class

Chan, et al. Standards Track [Page 7]

RFC 3084 COPS-PR March 2001

2.2.1. Adding or Deprecating Attributes of a BER Encoded

A PIB can be modified to deprecate existing attributes of a PRC
add new ones

When deprecating the attributes of a PRC, it must be remembered that
with the COPS-PR protocol, the attributes of the PRC are
by their order in the sequence rather than an explicit label (
attribute OID). Consequently, an ASN.1 value MUST be sent even
deprecated attributes so that a PDP and PEP implementing
versions of the PIB are inter-operable

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
may send an ASN.1 NULL value. A PEP that receives an ASN.1 NULL
an attribute that is not deprecated SHOULD substitute a
value. If it has no default value to substitute it MUST return
error to the PDP

When adding new attributes to a PIB, these new attributes must
added in sequence after the existing ones. A PEP that receives a
with more attributes than it is expecting MUST ignore the
attributes and send a warning back to the PDP

A PEP that receives a PRI with fewer attributes than it is
SHOULD assume default values for the missing attributes. It MAY
a warning back to the PDP. If the missing attributes are
and there is no suitable default, the PEP MUST send an error back
the PDP. In all cases the missing attributes are assumed
correspond to the last attributes of the PRC

2.3. COPS Operations Supported for a Provisioning

A Provisioning Instance (PRI) typically contains a value for
attribute defined for the PRC of which it is an instance and
identified uniquely, within the scope of a given COPS Client-Type
Request-State on a PEP, by a Provisioning Instance Identifier (PRID).
The following COPS operations are supported on a PRI

o Install - This operation creates or updates a named instance of
PRC. It includes two parameters: a PRID object to name the PRI
an Encoded Provisioning Instance Data (EPD) object with
new/updated values. The PRID value MUST uniquely identify a
PRI (i.e., PRID prefix or PRC values are illegal). Updates to
existing PRI are achieved by simply reinstalling the same PRID
the updated EPD data

Chan, et al. Standards Track [Page 8]

RFC 3084 COPS-PR March 2001

o Remove - This operation is used to delete an instance of a PRC.
includes one parameter, a PRID object, which names either
individual PRI to be deleted or a PRID prefix naming one or
complete classes of PRIs. Prefix-based deletion supports
bulk policy removal. The removal of an unknown/non-existent
SHOULD result in a warning to the PDP (no error).

3. Message

The COPS protocol provides for different COPS clients to define
own "named", i.e., client-specific, information for various messages
This section describes the messages exchanged between a COPS
(PDP) and COPS Policy Provisioning clients (PEP) that carry client
specific data objects. All the COPS messages used by COPS-PR
to the message specifications defined in the COPS base
[COPS].

Note: The use of the '*' character represented throughout
document is consistent with the ABNF [RFC2234] and means 0 or more
the following entities

3.1. Request (REQ) PEP ->

The REQ message is sent by policy provisioning clients to issue
'configuration request' to the PDP as specified in the COPS
Object. The Client Handle associated with the REQ message
by a provisioning client MUST be unique for that client. The
Handle is used to identify a specific request state. Thus,
client can potentially open several configuration request states
each uniquely identified by its handle. Different request states
used to isolate similarly named configuration information into non
overlapping contexts (or logically isolated namespaces). Thus,
instance of named information is unique relative to a
client-type and is unique relative to a particular request state
that client-type, even if the information was similarly identified
other request states (i.e., uses the same PRID). Thus, the
Handle is also part of the instance identification of
communicated configuration information

The configuration request message serves as a request from the PEP
the PDP for provisioning policy data that the PDP may have for
PEP, such as access control lists, etc. This includes policy the
may have at the time the REQ is received as well as any future
data or updates to this data

The configuration request message should include provisioning
information to provide the PDP with client-specific configuration
capability information about the PEP. The information provided

Chan, et al. Standards Track [Page 9]

RFC 3084 COPS-PR March 2001

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.
information typically does not include all the information
installed by a PDP but rather should include checksums or
references to previously installed information for
purposes. This information from the client assists the server
deciding what types of policy the PEP can install and enforce.
format of the information encapsulated in one or more of the
Named ClientSI objects is described in section 5. Note that
configuration request message(s) is generated and sent to the PDP
response to the receipt of a Synchronize State Request (SSQ)
from the PDP. Likewise, an updated configuration request
(using the same Client Handle value as the original request now
updated) may also be generated by the PEP and sent to the PDP at
time due to local modifications of the PEP's internal state. In
way, the PDP will be synchronized with the PEP's relevant
state at all times

The policy information supplied by the PDP MUST be consistent
the named decision data defined for the policy provisioning client
The PDP responds to the configuration request with a DEC
containing any available provisioning policy data

The REQ message has the following format

::= *()
[<Integrity>]

Note that the COPS objects IN-Int, OUT-Int and LPDPDecisions are
included in a COPS-PR Request

3.2. Decision (DEC) PDP ->

The DEC message is sent from the PDP to a policy provisioning
in response to the REQ message received from the PEP. The
Handle MUST be the same Handle that was received in the
REQ message

The DEC message is sent as an immediate response to a
request with the solicited message flag set in the COPS
header. Subsequent DEC messages may also be sent at any time
the original DEC message to supply the PEP with additional/
policy information without the solicited message flag set in the
message header (as they are unsolicited decisions).

Chan, et al. Standards Track [Page 10]

RFC 3084 COPS-PR March 2001

Each DEC message may contain multiple decisions. This means a
message can install some policies and delete others. In general
single COPS-PR DEC message MUST contain any required remove
first, followed by any required install decisions. This is used
solve a precedence issue, not a timing issue: the remove
deletes what it specifies, except those items that are installed
the same message

The DEC message can also be used by the PDP to command the PEP
open a new Request State or Delete an existing Request-State
identified by the Client-Handle. To accomplish this, COPS-PR
a new flag for the COPS Decision Flags object. The flag 0x02 is
be used by COPS-PR client-types and is hereafter referred to as
"Request-State" flag. An Install decision (Decision Flags: Command
Code=Install) with the Request-State flag set in the COPS
Flags object will cause the PEP to issue a new Request with a
Client Handle or else specify the appropriate error in a COPS
message. A Remove decision (Decision Flags: Command-Code=Remove
with the Request-State flag set in the COPS Decision Flags
will cause the PEP to send a COPS Delete Request State (DRQ)
for the Request-State identified by the Client Handle in the
message. Whenever the Request-State flag is set in the COPS
Flags object in the DEC message, no COPS Named Decision Data
can be included in the corresponding decision (as it serves
purpose for this decision flag). Note that only one decision
the Request-State flag can be present per DEC message, and,
present, this MUST be the only decision in that message.
described below, the PEP MUST respond to each and every DEC with
corresponding solicited RPT

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
fail. If they fail, the PEP will rollback to its previous
state, which is the last successful DEC transaction, if any.
allows the PDP to delete some policies only if other policies can
installed in their place. The DEC message has the following format

<Decision Message> ::= *(<Decision>) | [<Integrity>]

<Decision> ::= <Decision: Flags
[Decision Data: Provisioning >]

Chan, et al. Standards Track [Page 11]

RFC 3084 COPS-PR March 2001

Note that the Named Decision Data (Provisioning) object is
in a COPS-PR Decision when it is an Install or Remove decision
no Decision Flags set. Other types of COPS decision data
(e.g., Stateless, Replacement) are not supported by COPS-PR client
types. The Named Decision Data object MUST NOT be included in
decision if the Decision Flags object Command-Code is NULL (
there is no configuration information to install at this time) or
the Request-State flag is set in the Decision Flags object

For each decision in the DEC message, the PEP performs the
specified in the Command-Code and Flags field in the Decision
object on the Named Decision Data. For the policy
clients, the format for this data is defined in the context of
Policy Information Base (see section 5). In response to a
message, the policy provisioning client MUST send a RPT message,
the solicited message flag set, back to the PDP to inform the PDP
the action taken

3.3. Report State (RPT) PEP ->

The RPT message is sent from the policy provisioning clients to
PDP to report accounting information associated with the
policy, or to notify the PDP of changes in the PEP (Report-Type = '
Accounting') related to the provisioning client

RPT is also used as a mechanism to inform the PDP about the
taken at the PEP in response to a DEC message. For example,
response to an 'Install' decision, the PEP informs the PDP if
policy data is installed (Report-Type = 'Success') or not (Report
Type = 'Failure'). Reports that are in response to a DEC
MUST set the solicited message flag in their COPS message header
Each solicited RTP MUST be sent for its corresponding DEC in
order the DEC messages were received. In case of a
failure, the PEP is expected to rollback to its previous (good)
as if the erroneous DEC transaction did not occur. The PEP
always respond to a DEC with a solicited RPT even in response to
NULL DEC, in which case the Report-Type will be 'Success'.

Reports can also be unsolicited and all unsolicited Reports MUST
set the solicited message flag in their COPS message header.
of unsolicited reports include 'Accounting' Report-Types, which
not triggered by a specific DEC messages, or 'Failure' Report-Types
which indicate a failure in a previously successfully
configuration (note that, in the case of such unsolicited failures
the PEP cannot rollback to a previous "good" state as it
ambiguous under these asynchronous conditions what the correct
might be).

Chan, et al. Standards Track [Page 12]

RFC 3084 COPS-PR March 2001

The RPT message may contain provisioning client information such
accounting parameters or errors/warnings related to a decision.
data format for this information is defined in the context of
policy information base (see section 5). The RPT message has
following format

::= *()
[<Integrity>]

4. COPS-PR Protocol

The COPS Policy Provisioning clients encapsulate several new
within the existing COPS Named Client-specific information object
Named Decision Data object. This section defines the format of
new objects

COPS-PR classifies policy data according to "bindings", where
binding consists of a Provisioning Instance Identifier and
Provisioning Instance data, encoded within the context of
provisioning policy information base (see section 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
COPS objects. The difference is that S-Num and S-Type are used
for COPS-PR clients and are encapsulated within the existing
Named ClientSI or Named Decision Data objects. The S-Num
the general purpose of the object, and the S-Type describes
specific encoding used for the object. All the object
and examples in this document use the Basic Encoding Rules as
encoding type (S-Type = 1). Additional encodings can be defined
the remaining S-Types in the future (for example, an additional S
Type could be used to carry XML string based encodings [XML] as
EPD of PRI instance data, where URNs identify PRCs [URN]
XPointers would be used for PRIDs).

Chan, et al. Standards Track [Page 13]

RFC 3084 COPS-PR March 2001

Length is a two-octet value that describes the number of
(including the header) that compose the object. If the length
octets does not fall on a 32-bit word boundary, padding MUST be
to the end of the object so that it is aligned to the next 32-
boundary before the object can be sent on the wire. On the
side, a subsequent object boundary can be found by simply rounding
the stated object length of the current object to the next 32-
boundary. The values for the padding MUST be all zeros

4.1. Complete Provisioning Instance Identifier (PRID

S-Num = 1 (Complete PRID), S-Type = 1 (BER), Length = variable

This object is used to carry the identifier, or PRID, of
Provisioning Instance. The identifier is encoded following the
that have been defined for encoding SNMP Object Identifier (OID
values. Specifically, PRID values are encoded using
Type/Length/Value (TLV) format and initial sub-identifier
that is specified by the binary encoding rules [BER] used for
Identifiers in an SNMP PDU

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
encoded as follows (values in hex):

06 07 2B 06 01 02 02 08 01

The entire PRID object would be encoded as follows

00 0D -
01 - S-
01 - S-Type (Complete PRID
06 07 2B 06 01 02 02 08 01 - Encoded
00 00 00 -

NOTE: When encoding an xxxTable's xxxEntry Object-Type as defined
the SMI [V2SMI] and SPPI [SPPI], the OID will contain all the sub
identifiers up to and including the xxxEntry OID but not the
identifiers for the attributes within the xxxEntry's SEQUENCE.
last (suffix) identifier is the INDEX of an instance of an

Chan, et al. Standards Track [Page 14]

RFC 3084 COPS-PR March 2001

xxxEntry including its SEQUENCE of attributes encoded in the
(defined below). This constitutes an instance (PRI) of a class (PRC
in terms of the SMI

A PRID for a scalar (non-columnar) value's OID is encoded directly
the PRC where the instance identifier suffix is always zero as
will be only one instance of a scalar value. The EPD will then
used to convey the scalar value

4.2. Prefix PRID (PPRID

Certain operations, such as decision removal, can be optimized
specifying a PRID prefix with the intent that the requested
be applied to all PRIs matching the prefix (for example,
instances of the same PRC). PRID prefix objects MUST only be used
the COPS protocol Decision> operation where it may be
optimal to perform bulk decision removal using class prefixes
of a sequence of individual Decision> operations. Other
operations, e.g., Decision> operations always
individual PRID specification

S-Num = 2 (Prefix PRID), S-Type = 1 (BER), Length = variable

0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | S-Num = PPRID | S-Type = BER |
+---------------+---------------+---------------+---------------+
... ...
| Prefix PRID |
... ...
+---------------+---------------+---------------+---------------+

Continuing with the previous example, a prefix PRID that is equal
1.3.6.1.2.2 would be encoded as follows (values in hex):

06 05 2B 06 01 02 02

The entire PPRID object would be encoded as follows

00 0B -
02 - S-Num = Prefix
01 - S-Type =
06 05 2B 06 01 02 02 - Encoded Prefix
00 -

Chan, et al. Standards Track [Page 15]

RFC 3084 COPS-PR March 2001

4.3. Encoded Provisioning Instance Data (EPD

S-Num = 3 (EPD), S-Type = 1 (BER), Length = variable

This object is used to carry the encoded value of a
Instance. The PRI value, which contains all of the individual
of the attributes that comprise the class (which corresponds to
SMI's xxxEntry Object-Type defining the SEQUENCE of
comprising a table [V2SMI][SPPI]), is encoded as a series of
sub-components. Each sub-component represents the value of a
attribute and is encoded following the BER. Note that the
of non-scalar (multiple) attributes within the EPD is dictated
their respective columnar OID suffix when defined in [V2SMI]. Thus
the attribute with the smallest columnar OID suffix will appear
and the attribute with the highest number columnar OID suffix will
last

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
could be described using the SMI as follows

ipv4FilterIpFilter OBJECT IDENTIFIER ::= { someExampleOID 1 }

-- The IP Filter

ipv4FilterTable OBJECT-
SYNTAX SEQUENCE OF Ipv4
MAX-ACCESS not-
STATUS

"Filter definitions. A packet has to match all fields
a filter. Wildcards may be specified for those
that are not relevant."

::= { ipv4FilterIpFilter 1 }

ipv4FilterEntry OBJECT-
SYNTAX Ipv4
MAX-ACCESS not-
STATUS

"An instance of the filter class."

Chan, et al. Standards Track [Page 16]

RFC 3084 COPS-PR March 2001

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
}

ipv4FilterIndex OBJECT-
SYNTAX Unsigned32
MAX-ACCESS read-
STATUS

"An integer index to uniquely identify this filter among
the filters."

::= { ipv4FilterEntry 1 }

ipv4FilterDstAddr OBJECT-

SYNTAX
MAX-ACCESS read-
STATUS

"The IP address to match against the packet's destination
address."

::= { ipv4FilterEntry 2 }

ipv4FilterDstAddrMask OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"A mask for the matching of the destination IP address
A zero bit in the mask means that the corresponding bit

Chan, et al. Standards Track [Page 17]

RFC 3084 COPS-PR March 2001

the address always matches."

::= { ipv4FilterEntry 3 }

ipv4FilterSrcAddr OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"The IP address to match against the packet's source
address."

::= { ipv4FilterEntry 4 }

ipv4FilterSrcAddrMask OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"A mask for the matching of the source IP address."

::= { ipv4FilterEntry 5 }

ipv4FilterDscp OBJECT-
SYNTAX Integer32 (-1 | 0..63)
MAX-ACCESS read-
STATUS

"The value that the DSCP in the packet can have
match. A value of -1 indicates that a
DSCP value has not been defined and thus all DSCP
are considered a match."

::= { ipv4FilterEntry 6 }

ipv4FilterProtocol OBJECT-
SYNTAX Integer32 (0..255)
MAX-ACCESS read-
STATUS

"The IP protocol to match against the packet's protocol
A value of zero means match all."

::= { ipv4FilterEntry 7 }

ipv4FilterDstL4PortMin OBJECT-
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-

Chan, et al. Standards Track [Page 18]

RFC 3084 COPS-PR March 2001

STATUS

"The minimum value that the packet's layer 4
port number can have and match this filter."

::= { ipv4FilterEntry 8 }

ipv4FilterDstL4PortMax OBJECT-
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-
STATUS

"The maximum value that the packet's layer 4
port number can have and match this filter."

::= { ipv4FilterEntry 9 }

ipv4FilterSrcL4PortMin OBJECT-
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-
STATUS

"The minimum value that the packet's layer 4 source
number can have and match this filter."

::= { ipv4FilterEntry 10 }

ipv4FilterSrcL4PortMax OBJECT-
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-
STATUS

"The maximum value that the packet's layer 4 source
number can have and match this filter."

::= { ipv4FilterEntry 11 }

ipv4FilterPermit OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS

"If false, the evaluation is negated. That is,
valid match will be evaluated as not a match and
versa."

::= { ipv4FilterEntry 12 }

Chan, et al. Standards Track [Page 19]

RFC 3084 COPS-PR March 2001

A fictional instance of the filter class defined above might
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
05 00 :ipv4FilterDstL4PortMax/NULL/not
05 00 :ipv4FilterSrcL4PortMin/NULL/not
05 00 :ipv4FilterSrcL4PortMax/NULL/not
02 01 01 :ipv4FilterPermit/TruthValue/Value = 1 (true

The entire EPD object for this instance would then be encoded
follows

00 30 -
03 - S-Num =
01 - S-Type =
02 01 08 - ipv4
40 04 C0 39 01 05 - ipv4
40 04 FF FF FF FF - ipv4
40 04 00 00 00 00 - ipv4
40 04 00 00 00 00 - ipv4
02 01 FF - ipv4
02 01 06 - ipv4
05 00 - ipv4FilterDstL4
05 00 - ipv4FilterDstL4
05 00 - ipv4FilterSrcL4
05 00 - ipv4FilterSrcL4
02 01 01 - ipv4

Note that attributes not supported within a class are still
in the EPD for a PRI. By convention, a NULL value is returned
attributes that are not supported. In the previous example,
and destination port number attributes are not supported

Chan, et al. Standards Track [Page 20]

RFC 3084 COPS-PR March 2001

4.4. Global Provisioning Error Object (GPERR

S-Num = 4 (GPERR), S-Type = 1 (for BER), Length = 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
object in COPS [COPS], except with C-Num and C-Type replaced by
S-Num and S-Type values shown. The global provision error object
used to communicate general errors that do not map to a specific PRC

The following global error codes are defined

availMemLow(1)
availMemExhausted(2)
unknownASN.1Tag(3) - The erroneous tag type SHOULD
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
by the PEP (in response to a
message attempting to open a
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
unknown/unsupported by the PEP (
otherwise formatted correctly).
specific error codes are to be used
provide more information
unknownCOPSPRObject(10)- Sub-code (octet 2) contains
object's S-Num and (octet 3)
unknown object's S-Type
malformedDecision(11) - Decision could not be parsed

Chan, et al. Standards Track [Page 21]

RFC 3084 COPS-PR March 2001

4.5. PRC Class Provisioning Error Object (CPERR

S-Num = 5 (CPERR), S-Type = 1 (for BER), Length = 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
the Error object in COPS [COPS], except with C-Num and C-
replaced by the S-Num and S-Type values shown. The class-
error object is used to communicate errors relating to specific
and MUST have an associated Error PRID Object

The following Generic Class-Specific errors are defined

priSpaceExhausted(1) - no more instances may currently
installed in the given class
priInstanceInvalid(2) - the specified class instance
currently invalid
installation or removal
attrValueInvalid(3) - the specified value for
attribute is illegal
attrValueSupLimited(4) - the specified value for the
attribute is legal but not
supported by the device
attrEnumSupLimited(5) - the specified enumeration for
identified attribute is legal but
currently supported by the device
attrMaxLengthExceeded(6) - the overall length of the
value for the identified
exceeds device limitations
attrReferenceUnknown(7) - the class instance specified by
policy instance identifier does
exist
priNotifyOnly(8) - the class is currently only
for use by request or report
prohibiting decision installation
unknownPrc(9) - attempt to install a PRI of a class
supported by PEP
tooFewAttrs(10) - recvd PRI has fewer attributes
required
invalidAttrType(11) - recvd PRI has an attribute of the
type

Chan, et al. Standards Track [Page 22]

RFC 3084 COPS-PR March 2001

deletedInRef(12) - deleted PRI is still referenced
other (non) deleted
priSpecificError(13) - the Error Sub-code field contains
PRC specific error

Where appropriate (errors 3, 4, 5, 6, 7 above) the error sub-
SHOULD identify the OID sub-identifier of the
associated with the error

4.6. Error PRID Object (ErrorPRID

S-Num = 6 (ErrorPRID), S-Type = 1 (BER), Length = variable

This object is used to carry the identifier, or PRID, of
Provisioning Instance that caused an installation error or could
be installed or removed. The identifier is encoded and
exactly as in the PRID object as described in section 4.1.

5. COPS-PR Client-Specific Data

This section describes the format of the named client
information for the COPS policy provisioning client.
formats are defined for Decision message's Named Decision
object, the Request message's Named ClientSI object and
message's Named ClientSI object. The actual content of the data
defined by the policy information base for a specific
client-type (see below).

5.1. Named Decision

The formats encapsulated by the Named Decision Data object for
policy provisioning client-types depends on the type of decision
Install and Remove are the two types of decisions that dictate
internal format of the COPS Named Decision Data object and
its presence. Install and Remove refer to the 'Install' and 'Remove
Command-Code, respectively, specified in the COPS Decision
Object when no Decision Flags are set. The data, in general,
composed of one or more bindings. Each binding associates a
object and a EPD object. The PRID object is always present in
install and remove decisions, the EPD object MUST be present in
case of an install decision and MUST NOT be present in the case of
remove decision

Chan, et al. Standards Track [Page 23]

RFC 3084 COPS-PR March 2001

The format for this data is encapsulated within the COPS
Decision Data object as follows
Decision Data> ::= <Decision> |
Decision>>

Decision> ::= *( )

Decision> ::= *(|)

Note that PRID objects in a Remove Decision may specify PRID
values. Explicit and implicit deletion of installed policies
supported by a client. Install Decision data MUST be explicit (i.e.,
PRID prefix values are illegal and MUST be rejected by a client).

5.2. ClientSI Request

The provisioning client request data will use same bindings
described above. The format for this data is encapsulated in
COPS Named ClientSI object as follows

::= <*( )>

5.3. Policy Provisioning Report

The COPS Named ClientSI object is used in the RPT message
conjunction with the accompanying COPS Report Type object
encapsulate COPS-PR report information from the PEP to the PDP
Report types can be 'Success' or 'Failure', indicating to the
that a particular set of provisioning policies has been
successfully or unsuccessfully installed/removed on the PEP,
'Accounting'.

5.3.1. Success and Failure Report-Type Data

Report-types can be 'Success' or 'Failure' indicating to the PDP
a particular set of provisioning policies has been
successfully or unsuccessfully installed/removed on the PEP.
provisioning report data consists of the bindings described above
global and specific error/warning information. Specific errors
associated with a particular instance. For a 'Success' Report-Type
a specific error is an indication of a warning related to a
policy that has been installed, but that is not fully
(e.g., its parameters have been approximated) as identified by
ErrorPRID object. For a 'Failure' Report-Type, this is an error
specific to a binding, again, identified by the ErrorPRID object
Specific errors may also include regular bindings

Chan, et al. Standards Track [Page 24]

RFC 3084 COPS-PR March 2001

carry additional information in a generic manner so that the
errors/warnings may be more verbosely described and associated
the erroneous ErrorPRID object

Global errors are not tied to a specific ErrorPRID. In a 'Success
RPT message, a global error is an indication of a general warning
the PEP level (e.g., memory low). In a 'Failure' RPT message,
is an indication of a general error at the PEP level (e.g.,
exhausted).

In the case of a 'Failure' Report-Type the PEP MUST report at
the first error and SHOULD report as many errors as possible.
this case the PEP MUST roll-back its configuration to the last
transaction before the erroneous Decision message was received

The format for this data is encapsulated in the COPS Named
object as follows

::= <[] *()>

::= *()

5.3.2. Accounting Report-Type Data

Additionally, reports can be used to carry accounting
when specifying the 'Accounting' Report-Type. This accounting
message will typically carry statistical or event information
to the installed configuration for use at the PDP. This
is encoded as one or more bindings that
describe the accounting information being reported from the PEP
the PDP

The format for this data is encapsulated in the COPS Named
object as follows

::= <*()>

NOTE: RFC 2748 defines an optional Accounting-Timer (AcctTimer
object for use in the COPS Client-Accept message.
accounting reports for COPS-PR clients are also obligated to be
by this timer. Periodic accounting reports SHOULD NOT be
by the PEP more frequently than the period specified by the
AcctTimer. Thus, the period between new accounting reports SHOULD
greater-than or equal-to the period specified (if specified) in
AcctTimer. If no AcctTimer object is specified by the PDP,
there are no constraints imposed on the PEP's accounting interval

Chan, et al. Standards Track [Page 25]

RFC 3084 COPS-PR March 2001

6. Common

This section describes, in general, typical exchanges between a
and Policy Provisioning COPS client

First, a TCP connection is established between the client and
and the PEP sends a Client-Open message specifying a COPS-
client-type (use of the ClientSI object within the Client-
message is currently undefined for COPS-PR clients). If the
supports the specified provisioning client-type, the PDP
with a Client-Accept (CAT) message. If the client-type is
supported, a Client-Close (CC) message is returned by the PDP to
PEP, possibly identifying an alternate server that is known
support the policy for the provisioning client-type specified

After receiving the CAT message, the PEP can send requests to
server. The REQ from a policy provisioning client contains a
'Configuration Request' context object and, optionally, any
named client specific information from the PEP. The
provided by the PEP should include available client resources (e.g.,
supported classes/attributes) and default policy
information as well as incarnation data on existing policy.
configuration request message from a provisioning client serves
purposes. First, it is a request to the PDP for any
configuration data which the PDP may currently have that is
for the PEP, such as access control filters, etc., given
information the PEP specified in its REQ. Also, the
request effectively opens a channel that will allow the PDP
asynchronously send policy data to the PEP, as the PDP decides
necessary, as long as the PEP keeps its request state open (i.e.,
long as the PEP does not send a DRQ with the request state's
Handle). This asynchronous data may be new policy data or an
to policy data sent previously. Any relevant changes to the PEP'
internal state can be communicated to the PDP by the PEP sending
updated REQ message. The PEP is free to send such updated
messages at any time after a CAT message to communicate changes
its local state

After the PEP sends a REQ, if the PDP has Policy Provisioning
configuration information for the client, that information
returned to the client in a DEC message containing the
Provisioning client policy data within the COPS Named Decision
object and specifying an "Install" Command-Code in the Decision
object. If no filters are defined, the DEC message will
specify that there are no filters using the "NULL Decision" Command
Code in the Decision Flags object. As the PEP MUST specify a
Handle in the request message, the PDP MUST process the Client
and copy it in the corresponding decision message. A DEC

Chan, et al. Standards Track [Page 26]

RFC 3084 COPS-PR March 2001

MUST be issued by the PDP with the Solicited Message Flag set in
COPS message header, regardless of whether or not the PDP has
configuration information for the PEP at the time of the request
This is to prevent the PEP from timing out the REQ and deleting
Client Handle

The PDP can then add new policy data or update/delete
configurations by sending subsequent unsolicited DEC message(s)
the PEP, with the same Client Handle. Previous
installed on the PEP are updated by the PDP by simply re-
the same instance of configuration information again (
overwriting the old data). The PEP is responsible for removing
Client handle when it is no longer needed, for example when
interface goes down, and informing the PDP that the Client Handle
to be deleted via the COPS DRQ message

For Policy Provisioning purposes, access state, and access
to the policy server can be initiated by other sources besides
PEP. Examples of other sources include attached users
network services via a web interface into a central
application, or H.323 servers requesting resources on behalf of
user for a video conferencing application. When such a request
accepted, the edge device affected by the decision (the point
the flow is to enter the network) needs to be informed of
decision. Since the PEP in the edge device did not initiate
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
containing Policy Provisioning Named Decision Data objects in
COPS Decision object as specified. Any updates to the
information, for example in the case of a policy change or call
down, is communicated to the PEP by subsequent unsolicited
messages containing the same Client Handle and the updated
Provisioning request state. Updates can specify that policy data
to be installed, deleted, or updated (re-installed).

PDPs may also command the PEP to open a new Request State or
an exiting one by issuing a decision with the Decision Flags object'
Request-State flag set. If the command-code is "install", then
PDP is commanding the PEP to create a new Request State,
therefore issue a new REQ message specifying a new Client Handle
otherwise issue a "Failure" RPT specifying the appropriate
condition. Each request state represents an independent
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
will be unaffected by the new request state as they are
(thus, no instances of configuration data within one Request

Chan, et al. Standards Track [Page 27]

RFC 3084 COPS-PR March 2001

can be affected by DECs for another Request State as identified
the Client Handle). If the command-code is "Remove", then the PDP
commanding the PEP to delete the existing Request-State specified
the DEC message's Client Handle, thereby causing the PEP to issue
DRQ message for this Handle

The PEP MUST acknowledge a DEC message and specify what action
taken by sending a RPT message with a "Success" or "Failure" Report
Type object with the Solicited Message Flag set in the COPS
header. This serves as an indication to the PDP that the
(e.g., H.323 server) can be notified whether the request has
accepted by the network or not. If the PEP needs to reject the
operation for any reason, a RPT message is sent with a Report-
with the value "Failure" and optionally a Client Specific
object specifying the policy data that was rejected. Under
solicited report failure conditions, the PEP MUST always rollback
its previously installed (good) state as if the DEC never occurred
The PDP is then free to modify its decision and try again

The PEP can report to the PDP the current status of any
request state when appropriate. This information is sent in
Report-State (RPT) message with the "Accounting" flag set.
request state that is being reported is identified via the
Client Handle in the report message

Finally, Client-Close (CC) messages are used to cancel
corresponding Client-Open message. The CC message informs the
side that the client-type specified is no longer supported

7. Fault

When communication is lost between PEP and PDP, the PEP attempts
re-establish the TCP connection with the PDP it was last
to. If that server cannot be reached, then the PEP attempts
connect to a secondary PDP, assumed to be manually configured (
otherwise known) at the PEP

When a connection is finally re-established with a PDP, the PEP
a OPN message with a object providing the address
the most recent PDP for which it is still caching decisions. If
decisions are being cached on the PEP (due to reboot or TTL
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
current state information (by issuing a COPS SSQ message). If,
re-connecting, the PDP does not request synchronization, the
can assume the server recognizes it and the current state at the
is correct, so a REQ message need not be sent. Still, any
changes which occurred at the PEP that the PEP could not

Chan, et al. Standards Track [Page 28]

RFC 3084 COPS-PR March 2001

to the PDP due to communication having been lost, MUST be reported
the PDP via the PEP sending an updated REQ message. Whenever re
synchronization is requested, the PEP MUST reissue any REQ
for all known Request-States and the PDP MUST issue DEC messages
delete either individual PRIDs or prefixes as appropriate to ensure
consistent known state at the PEP

While the PEP is disconnected from the PDP, the active request-
at the PEP is to be used for policy decisions. If the PEP
re-connect in some pre-specified period of time, all
Request-States are to be deleted and their associated
removed. The same holds true for the PDP; upon detecting a
TCP connection, the time-out timer is started for all Request-
associated with the PEP and these states are removed after
administratively specified period without a connection

8. Security

The COPS protocol [COPS], from which this document derives,
the mandatory security mechanisms that MUST be supported by all
implementations. These mandatory security mechanisms are used by
COPS protocol to transfer opaque information from PEP to PDP and
versa in an authenticated and secure manner. COPS for
Provisioning simply defines a structure for this opaque
already carried by the COPS protocol. As such, the
mechanisms described for the COPS protocol will also be deployed in
COPS-PR environment, thereby ensuring the integrity of the COPS-
information being communicated. Furthermore, in order to
describe a practical set of structured data for use with COPS-PR,
PIB (Policy Information Base) will likely be written in a
document. The authors of such a PIB document need to be aware of
security concerns associated with the specific data they
defined. These concerns MUST be fully specified in the
considerations section of the PIB document along with the
security mechanisms for transporting this newly defined data

9. IANA

COPS for Policy Provisioning follows the same IANA considerations
COPS objects as the base COPS protocol [COPS]. COPS-PR has
one additional Decision Flag value of 0x02, extending the COPS
protocol only by this one value. No new COPS Client- Types
defined by this document

COPS-PR also introduces a new object number space with each
being identified by its S-Num and S-Type value pair. These
are encapsulated within the existing COPS Named ClientSI or
Decision Data objects [COPS] and, therefore, do not conflict with

Chan, et al. Standards Track [Page 29]

RFC 3084 COPS-PR March 2001

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
as defined in [IANA]. These two numbers are always to be treated
a pair, with one or more S-Types defined per each S-Num.
document defines the S-Num values 1-6 and the S-Type 1 for each
these six values (note that the S-Type value of 2 is reserved
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.

Likewise, additional Global Provisioning error codes and Class
Specific Provisioning error codes defined for COPS-PR can only
added with IETF Consensus. This document defines the
Provisioning error code values 1-11 in section 4.4 for the
Provisioning Error Object (GPERR). This document also defines
Class-Specific error code values 1-13 in section 4.5 for the
Provisioning Error Object (CPERR).

10.

This document has been developed with active involvement from
number of sources. The authors would specifically like
acknowledge the valuable input given by Michael Fine, Scott Hahn,
Carol Bell

11.

[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.
A. Sastry, "The COPS (Common Open Policy Service
Protocol", RFC 2748, January 2000.

[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
for Policy Based Admission Control", RFC 2753,
2000.

[COPRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R.
A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.

[ASN1]