Subject: RE: Questions on framework-pib07

From: NOISETTE Yoann FTRD/DMI/CAE <[email-masked]>
Date: Wed, 13 Mar 2002 11:32:45 +0100

Hi all,

The frameworkpib-07 draft has been submitted on january 31st. 

A while back I sent an email to the list asking some questions about the
management of Role-Combinations (this mail is included below).
I haven't seen any response to these questions, neither have I seen any
comments on the new draft. Though many interesting features and corrections
have been introduced through the last versions, I think some have to be
clearer explained (leading me, for instance, to require clarifications on
the points tackled in my former email). 

Thanks for your replies.

Yoann

-----Message d'origine-----
De : NOISETTE Yoann FTRD/DMI/CAE
[mailto:[email-masked]]
Envoyé : lundi 4 février 2002 14:07
À : [email-masked]
Objet : 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. 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.

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

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

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"...

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...

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)

Thanks for your replies.

Yoann Noisette

---

From: "Sahita, Ravi" <[email-masked]>
Date: Tue, 19 Mar 2002 13:46:46 -0800

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

Ravi

-----Original Message-----
From: NOISETTE Yoann FTRD/DMI/CAE
[mailto:[email-masked]]
Sent: Monday, February 04, 2002 5:07 AM
To: [email-masked]
Subject: Questions on framework-pib07

=> 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

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?.

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

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.

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.

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.

Finally, some typos :

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

---

From: NOISETTE Yoann FTRD/DMI/CAE <[email-masked]>
Date: Thu, 21 Mar 2002 11:24:30 +0100

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:[email-masked]]
Envoyé : mardi 19 mars 2002 22:47
À : 'NOISETTE Yoann FTRD/DMI/CAE'
Cc : [email-masked]'
Objet : RE: Questions on framework-pib07

Ravi

-----Original Message-----

Moreover, the

Finally, some typos :

Thanks for your replies.

Yoann Noisette