Subject: rap-frwk-pib Multi PIB Instances

From: "Rawlins, Diana" <[email-masked]>
Date: Wed, 08 Aug 2001 12:34:17 +0000

In the Framework Policy Information Base, I 
think some changes to the wording would help
to avoid some confusion about the 
configuration of multiple request state 
contexts.
 
In Section 3.2 Multiple PIB Instances

Add to the following paragraph:

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]. A PEP must open only a single 
"request-state" for configuration for a given
subject-category (client type). Any additional
"request-states" at the PEP must be initiated
by the PDP. 

The following 3 sentences:

Note that in the event that a PEP has an 
interface capability change such as a card hot
swap, a subsequent request is issued to the 
PDP containing its revised capabilities. A 
request for re-configuration is issued for all 
request state contexts, both for the active 
context as well as any inactive contexts. This
 is to ensure that when an inactive context is
activated its been pre-configured with 
policies compatible with the PEP current 
capabilities.

In the same Section 3.2 

Replace the following wording: 

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.

With the following suggested wording:

To facilitate this selection, the Framework PIB
supports the attribute frwkPibIncarnationActive
that denotes the PIB instance as being active.

-Diana

---

From: MORAND Pierrick FTRD/DMI/CAE <[email-masked]>
Date: Thu, 9 Aug 2001 09:31:13 +0200

Additional comment at the end of the original message .
Pierrick

-----Message d'origine-----
De : Rawlins, Diana [mailto:[email-masked]]
Envoyé : mercredi 8 août 2001 14:34
À : [email-masked]'
Objet : rap-frwk-pib Multi PIB Instances

In the same Section 3.2 

[Comment PMo >>] Concerning this later point the text (page 17) indicates
that the PEP is responsible for re-setting the attribute to ensure that the
fwrkPibIncarnationActive attribute is "false" in all other contexts. What
about the PDP behavior ? Shall it clear the fwrkPibIncarnationActive
attribute of the previous active request-context before it sends its
decision or shall it wait for the report to do it ?  Or, when clearing this
attribute on the previous active context shall the PEP also issue an updated
request for that previous request context to update the PIB incarnation
entry at PDP side ?

-Diana