Ravi,
thanks for the clarifications you gave to me on these questions... I still however need some more ;-)
1- concerning the handle to be used by the PDP to update role combos, you say "Ravi>The PDP will always use the active handle to proceed, does the draft say otherwise?"
No, the draft doesn't say otherwise, but it does say enough IMO. It just says "on any open request handle"... Perhaps would it be clearer for guys like me if the following was added: "The request handle used by the PDP for the Role-Combinations update MUST be the active one when the PDP proceeds". Though I agree now this is implicit, I think this would help comprehension.
2- Ravi>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?.
Yoann> So the Role Combos update is potentially applicable to all Request handles. If the PEP doesn't send updated request on some handles the PEP and the PDP keep the previous request state for these handles, OK. But if I quote another part of §2.2
"If the role-combination updates were sent by the PDP, the
PEP SHOULD send these updated requests only if it can process the
unsolicited decision containing the frwkIfRoleCombo PRIs
successfully and it MUST do so after sending the success report for
the unsolicited decision. If the PEP failed to process the decision
(i.e., the frwkIfRoleCombo PRIs) it MUST only send a failure report
to the PDP."
Yoann> What criteria are used by the PEP to choose to update one handle and not another one (implementation specific ??) Wouldn't it be simpler if the update decision was only applied on the active handle ?
If after receiving the decision from the PDP, the PEP updates the Role Combos for another handle (another than the active one) and doesn't send any updated request for this (as it is only SHOULD), how does the PDP knows this particular handle has been updated ? I think if the PEP updates another handle, the PEP MUST send an updated request.
3- 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 (Yoann> sorry, I don't see your point here...)
; 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. (Yoann> agree)
Thanks for your feedback on these question. Sorry if I'm a bit slow in understanding points that are perhaps obvious...
Yoann
-----Message d'origine-----
De : Sahita, Ravi [mailto:ravi.sahita@intel.com]
Envoyé : mardi 19 mars 2002 22:47
À : 'NOISETTE Yoann FTRD/DMI/CAE'
Cc : 'rap@ops.ietf.org'
Objet : RE: Questions on framework-pib07
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