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

From: "Raju Rajan" <[email-masked]>
Date: Tue, 1 Jun 1999 09:54:44 -0400

----- Original Message -----
From: Durham, David <[email-masked]>
To: 'Raju Rajan' <[email-masked]>; <[email-masked]>
Sent: Friday, May 28, 1999 8:32 PM
Subject: RE: New Schema I-D Requested to be Posted to IETF Repository

Hi David,

 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?

raju

> Hi Raju,
>
> > I dont still see why the issues you raise are couched (I'm referring to
> > the
> > earlier email) as "auxiliary class issues".
> >
> [[Dave]]  My dispute here is with section 5.3 "Flexibility
> Gained though Auxiliary Classes" and was relevant to my
> second example. I agree that auxiliary vs. structural classes
> is not the debate, it just depends on how they are used within
> the overall structure of the DIT. Let's see...
>
> > Your second example (below) is somewhat puzzling to me. Are you
suggesting
> > that a device ("console") will act on the policy before it retrieves a
> > full
> > LDAP object? Unless I misunderstand, this sounds more like a terrible
> > client
> > implementation (so sue me!) than an LDAP problem :)
> >
> [[Dave]]  Getting the full LDAP object is not the problem, it
> is the solution. My complaint is that when you go beyond a single
> LDAP entry to express a policy, then you are effectively opening
> up LDAP's non-transactional Achilles heel. Keeping all ANDed
> conditions within a single entry will help prevent clients from
> retrieving incomplete (=incorrect) policies. Attaching conditions
> as separate sibling entries to a policy rule implies that a client
> can retrieve a portion of the DIT that a console is in the process
> of editing. Rules need to be built from the conditions and actions
> up, or entries need to contain all attributes applicable to a rule,
> so that PDPs do not get incorrect policies. Basically, the core
> schema should be designed to take advantage of atomic transactions
> within an entry where LDAP does have limited transactional support.
> The DNF form of complex policy rules violates this principle as
> do simple policy rules (and correct me if I am wrong) where
> conditions and actions are attached as sibling entries.
>
> I have a host of other transactional issues with using auxiliary
> attachments as labels which will have to be edited across DNs all
> the while PDPs (and other consoles) are potentially querying
> (and editing) the DIT!
>

---

From: Ping Pan <[email-masked]>
Date: Tue, 01 Jun 1999 11:31:59 -0400

Raju,

I agree with you that PDP's should try to do as much decision process as
possible. On the other hand, I'm not sure if a PDP can get ALL the rules
relevant to each PEP. 

For example, an edge router supports both classical RSVP and RSVP
extension for LSP establishment. On the router, one PDP is set for local
user's RSVP admission control, and another PDP is used for RSVP LSP
management with the ISP's. By the way, two PDP's belong to two separate
organizations. In this case, the PEP simply sends all received policy
information up to the corresponding PDP's and makes the final decision
(e.g., over-riding) locally.

Make sense?

I'm afraid that the concept of having one centralized PDP for each PEP
may constraint us for future services.

P.S.: Decision making on everything is centralized in SNA model. As a
result, it's rigid and slow. Let's avoid centralized model here, please.
;-)

Regards,

- Ping

---

From: "Raju Rajan" <[email-masked]>
Date: Tue, 1 Jun 1999 12:16:20 -0400

> possible. On the other hand, I'm not sure if a PDP can get ALL the rules

Thanks Ping. I just meant as many rules as it would normally get; I did not
intend to say that all the rules for one PEP must go to one PDP thus ruling
out distributed implementations. But even in a multi-PDP per PEP
environment, each PDP should get all the rules that it normally
would/should/must/may get before making starting to make decisions.

raju