-----Original Message-----
From: Kulkarni, Amol [mailto:amol.kulkarni@intel.com]
Sent: Tuesday, April 24, 2001 9:53 AM
To: 'Iliff, Tina'; 'rap@ops.ietf.org'
Subject: RE: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification NeededTina,It is my understanding that whenever a PEP receives a decision from a PDP activating a particular PIB instance, the PEP is responsible for de-activating the previously active PIB instance installed on it.Amol-----Original Message-----
From: Iliff, Tina [mailto:Tina.Iliff@WCOM.Com]
Sent: Tuesday, April 24, 2001 6:38 AM
To: 'rap@ops.ietf.org'
Subject: FW: framework-pib-04: Pib Incarnations "Activation" and "De-acti vation" Clarification Needed
Tina Iliff
MCIWorldCom ENSD
(972)729-1620
-----Original Message-----
From: Iliff, Tina
Sent: Tuesday, April 17, 2001 5:43 PM
To: 'rap@ops.ietf.org'
Subject: framework-pib-04: Pib Incarnations "Activation" and "De-activation" Clarification NeededAll,
One item in the framework-pib-04 draft seems a little ambiguous to me. Please let me know if I am missing something. Specifically, how should one interpret the below RFC 3084 excerpts regarding Pib Incarnations: Specifically, based on this excerpt which endpoint (PEP or PDP) is responsible for setting a Pib Incarnation to "inactive"; i.e. setting its Active attribute to 'False'? It explicitly states that the PDP is responsible for selecting the Active incarnation. My interpretation is that all policy will be sent and indicated as inactive, then the PDP will send just a frwkPibIncarnation instance to "activate" one incarnation identified by its Id. However, who is responsible for "de-activating" currently installed "activated" policy when a new incarnation is sent by the PDP with the Active attribute set to 'True'?
Also, please let me know if I am interpreting words incorrectly.
Multiple PIB Instances
[COPS-PR] supports multiple, disjoint, independent instances of the
PIB to represent multiple instances of configured policy. The
intent is to allow for the pre-provisioning of policy that can then
be made active by a single, short decision from the PDP.
A COPS context can be defined as an independent COPS request state
for a particular subject category (client-type).
With the COPS-PR protocol, each of these states is identified by a
unique client handle. The creation and deletion of these PIB
instances is controlled by the PDP as described in [COPS-PR].
Although many PIB instances may be configured on a device (the
maximum number of these instances being determined by the device
itself) only one of them can be active at any given time, the active
one being selected by the PDP. To facilitate this selection, the
Framework PIB supports an attribute to make a PIB instance the
active one and, similarly, to report the active PIB instance to the
PDP in a COPS request message. This attribute is in the Incarnation
Table described below.
Setting the attribute frwkPibIncarnationActive to 'true' in one PIB
instance MUST ensure that the attribute is 'false' in all other
contexts.frwkPibIncarnationActive OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"If this attribute is set to TRUE, then the PIB instance
to which this PRI belongs becomes the active PIB instance.
The previous active instance MUST become inactive and the
frwkPibIncarnationActive attribute in that PIB instance
MUST be set to false."
Regards,
Tina Iliff