RE: Questions on framework-pib07

["Sahita, Ravi" <ravi.sahita@intel.com>]

I've tried to provide some clarification, 
Comments prefixed by Ravi.

Ravi

-----Original Message-----
From: NOISETTE Yoann FTRD/DMI/CAE
[mailto:yoann.noisette@rd.francetelecom.com]
Sent: Monday, February 04, 2002 5:07 AM
To: rap@ops.ietf.org
Subject: Questions on framework-pib07



I have some questions about the management of Role-Combinations as described
in §2.2 of the document "draft-ietf-rap-frameworkpib-07.txt". 

>>>>	At any later time, the PDP can update the Role-Combinations assigned
>>>>	to a specific interface, identified by IfIndex, or for an aggregate,
>>>>	identified by IfCapSetName, via an unsolicited decision to the PEP 
>>>>	on any open request handle. The PDP does this by sending updated 
>>>>	PRIs for the frwkIfRoleComboTable.

=> I suppose this update is done by the PDP for a given Client-Type, but I
think it would be good to give this precision in the text. 

Ravi> I agree, I'll add that clarification.

Moreover, the
fact that the PDP can proceed using "any open request handle" leads me to
ask/think :

1) this means to me that the update impacts all instances of PIB, as "any
one" can be chosen. Thus all instances of PIB have the same role combos
defined for the interfaces (for a given CT). Is that right ? Isn't it
possible to have different role combos for an interface in different
instances of PIB attached to different Handle on a given Client-Type ? To
rely on an simple example :
Suppose I have two instances of PIB which I activate at different times,
let's say, one for the days of work, one for the week-end. I could decide to
give the role "comptability" during the days of work and "none" during the
week end to a given interface which I don't want to be used "with
"comptability" configuration during the week end.

Ravi>Yoann, the draft doesnt mandate that, Note that it says in the 
same §2.2
  "If the PDP does not receive updated requests on some request handles,
   the PEP must not be sent decision updates for that frwkIfRoleCombo 
   updates, i.e., the PDP must have the previous request state that it 
   maintained for that request handle. "'
This should be probably clarified a little bit to say:
  "If the PDP does not receive updated requests on some request handles,
   the PEP must not be sent decision updates for the frwkIfRoleCombo
   updates for those request handles, i.e., the PDP must have the 
   previous request state that it maintained for that request handle. "' 
This allows implementations that want the behaviour you described, and
makes the behaviour unambigious for PDP implementations that dont receive
updated requests on all handles - is that helpful?.


2) should(n't) the PDP use the active handle to proceed  ? is it
implementation specific ?

Ravi>The PDP will always use the active handle to proceed, does
the draft say otherwise?


3) SHOULD or MUST (or ...) the frwkPibIncarnationId be changed by the PDP
when updating the Role-Combinations ??

Ravi>Since the roles can, theoritically, also be updated by the PEP
at a later time, we left the incarnation table to be an indication
of the installed configuration ie the install tables.


Following in §2.2 :
>>>>	When the Interface Role Combination associations are updated by the 
>>>>	PDP, the PEP SHOULD send updated ĉfull stateĈ requests for all open 
>>>> 	contexts (request handles).

=> this sentence reenforces the idea I exposed above in 1)... 
Therefore, the PEP will modify the required role combinations in all the
instances of PIB attached to the different existing contexts (handles).
Isn't it a bit contradictory with the settlement in §2.4 " [COPS-PR]
supports multiple, disjoint, independent instances of the PIB to represent
multiple instances of configured policy.". I see the same kind of
contradiction with the PEP changing the attribute frwkPibIncarnationActive
when necessary (§2.4), the contradiction coming on the word "independent"...

Ravi> Note that we used the word SHOULD and not MUST when we specified
that the PEP should send updated full state requests for all open handles,
we did this since we felt this makes PDP implementations less complex, but,
yes like you pointed it - it may be required in some scenarios.


Let's look rapidly at the way to proceed :
a) when the PEP receives a Role Combination update from the PDP, it passes
this update on all the contexts (request handles) for the considered
Client-type. Then it sends a success report.
b) sending updated full state request is only SHOULD, therefore, if we admit
the Roles-Combinations of the interfaces in the different PIB instances are
the same, I see two possible inconsistencies :
	* the update has been done on the PEP's side, but if no full-state
request is sent afterwards, the PDP doesn't have the updated
Role-combinations in its own instances (cf. §2.2 "the PDP must have the
previous request state that it maintained for that request handle").
	* if for only some contexts, the PEP has sent updated full-state
request, then on the PDP's side, some context are updated, others  are not,
leading to have two different sets of Role-combinations at the same time on
different contexts... which is contradictory to the hypothesis stated in b)
above...

Ravi>So, I hope the above clarifications resolve this - that if the PEP
does not send updated requests on a subset of the handles, it must 
expect updates only on that subset; and the PDP must not expect 
updated requests on any handles other that the one it sent the decision
on, and if it does get updated requests for other handles, it must honor
them with a decision.


Please correct me if I'm wrong... If not, this means that the document
contains two possible inconsistencies, which could be avoided, for instance
by simply having the PDP update the different contexts on its side once it
has received the success report from the PEP...

Finally, some typos :

* page 23 : fwrPibIncarnationFullState : "It does not have any meaning when
sent from the PDP to the PEP" (instead of PDP in the text)
* page 23 : fwrPibIncarnationFullState : "see section 2.3 for details..."
(instead of section 3.3 in the text)

Ravi> Thanks for pointing these out, I'll address them in the IESG version.

Ravi>Thanks for the thorough review..
Ravi

Thanks for your replies.

Yoann Noisette