Framework PIB clarifications

[NOISETTE Yoann FTRD/DMI/CAE <yoann.noisette@rd.francetelecom.fr>]

We are currently working on a project making use of COPS-PR for provisioning
purposes. As far as the Framework PIB is concerned, we have some questions
to which we would like to draw the RAP list attention. Thanks in advance for
your replies.

1)	This point has already been asked by Man Li, with no answer. 
In the Interface Capability Set Table, the attribute frwkIfCapSetCapability
specifies the capability PRC instance for the interface. This PRC instance
is normally defined in other PIBs, like it is the case for the DiffServ PIB
for example.
We are working with the IPSec PIB, which doesn't contain any Capability
Table. So my question is, what value must we give to frwkIfCapSetCapability,
in so far as we don't have any capability table we can refer to in the IPSec
PIB??

2)	We have the same question regarding the attribute
frwIfCapSetRoleComboName. If we consider the IPSec PIB again, the PEP won't
notify the PDP with any Capability Set instance since there is no Capability
Table we can refer to. Thus, we wouldn't have any value for
frwIfCapSetRoleComboName. What value should we use then?? 

3)	What is the reason to use the frwIfCapSetName? Indeed the same
frwIfCapSetRoleComboRoles can be used to refer to many frwIfCapSetName which
themselves refer to a frwkIfCapSetCapability. What is the aim of such an
organisation? Why not frwIfCapSetRoleComboRoles refers directly to
frwkIfCapSetCapability? 

4)	As we understand it, there is an instance of PIB Framework
associated with each Request. Therefore, the Framework PIB is pushed by the
PEP for each Request it opens. However, most of the information is only
"notify", we are wondering why it should proceed so, since once the PDP has
the device description (roles, limitations, identification...), it can use
it for all following Request-States, within the context of a given
Client-Type of course. 
After the initial Request, only the PIB Incarnation Table and the possible
Filter Tables would have to be sent. The PDP would only have to complete
with the other information it already has. 
Or is there a good reason for sending the complete Framework PIB each time
(leading however to generate more traffic, consume memory and persistent
storage)?

5)	In the context of many Requests being opened for a same Client-Type,
how is handled the activation/deactivation of a PIB thanks to the
frwkPibIncarnationActive object ? For instance, I have a PEP and a PDP with
two Requests and the associated PIBs, PIB 1 active and PIB 2 not active:
a.	First scenario:  the PDP sets the frwkPibIncarnationActive object to
false for PIB 1 and then sets frwkPibIncarnationActive to true for PIB 2.
What happens during the short period of time when there is no active PIB??
Which policies are used by the PEP? 
b.	Second scenario: the PDP sets the frwkPibIncarnationActive object to
true for PIB 2. Then we have two active PIBs at the same time. Does the PDP
sets the frwkPibIncarnationActive to false on PIB 1, but what happens during
the period when there are two active PIBs ? Or does the PEP sets itself the
frwkPibIncarnationActive object to false for PIB 1, and notifies the PDP of
the change?

Thanks for the replies.

Yoann