Subject: RE: New Schema I-D Requested to be Posted to IETF Repository

From: "Durham, David" <[email-masked]>
Date: Wed, 2 Jun 1999 17:00:38 -0700

Raju,

>  That a device (PDP) should try to enforce a policy rule until it fetches
> ALL the rules relevant to the PEP under consideration, is one of the
> primary
> processing rules that are implied by the semantics of the current schema.
> For instance, there could easily be (another) higher priority rule that
> overrules the one under consideration. So, not only must the PDP get each
> rule in its entireity befor acting, but it must get the entire rule
> database
> (i.e., the portion relevant to its operation). I definitely see a need for
> explicitly introducing this and other processing rules to clarify the
> "correct" interpretation and enforcement of the rules. (I suggested a some
> guidelines for this at the interim meeting.) Does this help with the
> second
> example?
> 
	[[Dave]]  No, I don't think this helps the second example.
	Remember, the directory will be queried by PDP's at the
	same time consoles will be updating/entering entries which
	only cumulatively specify "complete" policies. So, before
	we proceed, a few questions to make sure my understanding
	is in line with your own...

	1. How does the PDP know when the policies specified in the
	directory are complete (aka. have been completely entered)?

	2. Are actions and conditions "attached" to rules in the
	simple form as a list of attributes contained within a
	single rule entry (derived from PolicyRule) or are they 
	"attached" as individual children entries in the DIT
	to a parent rule entry (as implied by figure 5)?

	2.5. Ditto for groupings of conditions/actions.

	3. When using the auxiliary attachments to label policies
	or when using the keywords attribute, how does the PDP
	know when all the relevant portions of the DIT have been
	properly labeled?

	3.5. Can labels be updated? How will PDPs know when such
	label updates have completed?

	... For a few starter questions. Clearly, my view is that
	vendor specific policy rules and groups as well as 
	conditions/actions should be DERIVED from the core schema.
	The vendor specific rule objects will then specify what 
	attributes (conditions and actions) are allowed (MAY) and
	required (MUST) for a given derived rule class. Derived
	groups can also be defined to aggregate specific conditions
	or action attributes. In all cases, a single derived rule 
	entry should specify all the relevant attributes completely
	composing a rule, and a policy object should aggregate all 
	relevant rules, etc. via reference. As all the relevant 
	information for a given level in this hierarchy is contained 
	within an LDAP entry, and entry level transactions are 
	possible, many of the current transactional problems across 
	DNs can be avoided altogether. Furthermore, the need for 
	labels can be avoided if the schema is better organized so,
	for example, all DHCP related policy/condition/action 
	instances are organized under a common root entry.

	-Dave

---

From: "Raju Rajan" <[email-masked]>
Date: Thu, 3 Jun 1999 11:13:38 -0400

Hi Dave,

Comments inline.

> directory are complete (aka. have been completely entered)?

This is answered in the discussions surrounding the DIT and policy
retrieval. There are several mechanisms that are made available within LDAP
though I dont think any of them is mandatory at this point. To give you an
example the following could be the sequence of actions:

a) The network device (PEP/PXP) is configured with a root DN name (unique to
it, or to its group, or role, or organization, whatever).
b) The device communicates this DN to the policy server
c) The policy server (aggregating several such requests if need be) fetches
the specified DN object.
d) The DN object has the containedPolicyRule attribute with many values,
each the DN of a rule object relevant to the device.
e) The PDP/policy server fetches all these rules making sure that all the
references contained in the rule are fully "unwound". In other words, if you
fetch an IPSec action object and that further "points" to a proposal object,
then go and fetch the proposal object too (unless you got it before for some
other rule). Same for condition objects and other action objects
f) That's it. You're done.

Note: There are other grouping objects. See the core schema for more.
Note: The above is for illustration only. There are other ways of doing the
same.The point is that the schema provides the hooks, and not a method.

> to a parent rule entry (as implied by figure 5)?

The former, if I understand your question correctly.

> 2.5. Ditto for groupings of conditions/actions.

Ditto for groupings of conditions/actions.

> label updates have completed?

I'll leave the last question to better informed people.

Hope this helps

raju