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

From: Ed Ellesson <[email-masked]>
Date: Tue, 18 May 1999 09:46:40 -0400

Hello, 

You should be seeing an I-D soon, which updates the core policy schema
draft to -03.  We should be able to get this to a publically available site
today, just in case it takes a few days to get into the IETF repository.  

We need to let everyone know that this is still a work in progress.  There
is still contention among the contributors to the I-D, on such topics as
naming, using auxilliary classes to the extent that the new draft uses
them, and the new DIT navigation techniques that are in the draft, along
with the new object classes to facilitate these functions.  The content of
the draft is not meant to represent the consensus of the contributors, but
rather is meant to document a consistent set of approaches that needs
further debate to reach a consensus in this working group.  We can't have
the necessary discussion unless there is a proposal on the table, so this
I-D is meant to provide that.  

We are expecting spirited discussion on these and other topics, on this
list and at the interim meeting in Ft. Collins. 

I'll be sending out more info on the Ft. Collins meeting today.  Look for a
note about a URL for the draft today as well.  

John and Ed

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115

---

From: Andrew Smith <[email-masked]>
Date: Tue, 18 May 1999 10:14:09 -0700

Glenn,

I think that such a policy architecture/framework document goes hand-in-hand
with the schema draft. In fact, as I've said before, I think it actually
ought to predate any schema standards: if we cannot describe what we are
doing in words and ASCII pictures, without reference to specific schemas,
then I think we will have failed. 

I'm really not interested in travelling all the way to Colorado to discuss
the details of schemas (surely that is a job for the mailing list, no? And
if people aren't that interested in resolving these details on the mailing
list then I guess they don't see much urgency in completing this task so why
the need for an interim meeting .... hmmm). But I *am* interested in getting
a common IETF architecture for this policy stuff documented. There are
several other standardisation efforts that are dependent on (and waiting
for) such a common architectural document.

I'd encourage you to, with John-and-Ed's blessing of course, retitle your
draft as draft-ietf-policy-xxxxx and to gather in all the other
architectural material and opinions that have been presented to the WG in
drafts, presentations and mail messages (Silvano Gai, David Black, Keith
McCloghrie, Bob Moore, Evan McGinnis, David Blight, Hugh Mahon etc..). As
with the schema draft, if there are still differing opinions then these can
be enumerated in a single draft - this is much easier to comprehend that
having multiple separate private-author drafts and we'd all be eternally
grateful to you for performing this task. I don't think we'll make much
progress on the architectural side without such a unified draft. Let me know
if you need some help with this.

My $.02

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

> -----Original Message-----
> From: Glenn Waters [mailto:[email-masked]]
> Sent: Tuesday, May 18, 1999 8:47 AM
> To: freichmeyer; [email-masked]
> Cc: Ed Ellesson
> Subject: RE: New Schema I-D Requested to be Posted to IETF Repository
> 
> 
> i am editing a new draft that should be available today.  it 
> is basically
> the same as draft-waters-policy-arch-00.txt with an additional picture
> showing an optional communication path for tranmitting policy 
> information
> within a system.  (the picture is identical to the one 
> presented at the
> minneapolis ietf).
> 
> like the schema draft the architecture draft is meant to get 
> a document out.
> there are still some issues that need to be discussed and 
> agreed upon --
> although there has been no discussion of the architecture 
> work on the list
> so how many issues can there really be :).
> 
> /gww
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of freichmeyer
> > Sent: Tuesday, May 18, 1999 11:00
> > To: Ed Ellesson; [email-masked]
> > Subject: Re: New Schema I-D Requested to be Posted to IETF 
> Repository
> >
> >
> > Is the interim meeting to discuss the architecture as well? 
> Is there a
> > new "combined" architecture draft, or is anyine woking on 
> one? How do
> > we get all the co-authors of the original drafts involved 
> in that process?
> >
> > Thanks,
> > -Fran
> >
> > At 09:46 AM 5/18/99 -0400, Ed Ellesson wrote:
> > >Hello,
> > >
> > ----
> > Francis Reichmeyer
> > Bay Architecture Lab
> > 978-916-3352
> > [email-masked]
> >
> >
>

---

From: Andrew Smith <[email-masked]>
Date: Tue, 18 May 1999 13:31:55 -0700

Mark,

I'm not clear on what you are arguing for here: you seem to contradict
yourself by saying on the one hand that the WG should "examine our progress
toward the working group's first tangible and truly useful deliverable - a
schema for the administration of QoS policy" and on the other "We need to
sit down and develop real-life examples of policy [...] before we get to[o]
wrapped up in detailed architectural models, schemas and languages.". Are
you suggesting that we need to come up with a more detailed problem/goals
statement at this point, before progressing on models and schemas?

It's still unclear to me how we can document solutions for any of this
problem space without a clear architectural model of how we think it fits
together. In my mind at least, schema definition is diving down far deeper
than architectural models.

Andrew
Software Architect

> From: Stevens, Mark [mailto:[email-masked]]
> Sent: Tuesday, May 18, 1999 1:21 PM
> To: 'Andrew Smith'; 'Glenn Waters'; [email-masked]
> Before we start a deep dive into architecture, we should examine our
> progress toward the working group's first tangible and truly useful
> deliverable - a schema for the administration of QoS policy. 
> Early focus on
> definition languages, core schemas, and architectural models 
> has skewed our
> course. As a result, we have avoided the most basic and ironically,
> difficult questions. Specifically, the working group has 
> failed to develop a
> definition of the term policy and give specific examples.  We 
> have all heard
> people say, "Engineers get bronze service, but John the 
> engineer gets gold
> service" when giving an example of policy, but this expression is too
> nebulous to be useful, particularly in the context of RSVP. 
> 
> We need to sit down and develop real-life examples of policy, 
> particularly
> policies that could be used to respond to RAP admission 
> requests, before we
> get to wrapped up in detailed architectural models, schemas 
> and languages.
> Without a common notion of the policies we want to implement, 
> we can only
> dance around a solution. The solution cannot be derived from 
> the structure
> of an implementation. It must be discerned from an 
> understanding of the
> problem itself. We must ask ourselves, "What are the specific 
> policies that
> we want to express?" Only then can we answer the questions of 
> how best to
> structure their storage and implement their execution.
> 
> Mark Stevens
> Lucent Technologies, 300 Baker Avenue, Concord, MA 01742
> Voice/fax: 978 287 9102
> 
> > From:	Andrew Smith [SMTP:[email-masked]]
> > Sent:	Tuesday, May 18, 1999 1:14 PM
> > To:	'Glenn Waters'; [email-masked]
> > list then I guess they don't see much urgency in completing 
> this task so
> > why
> > with the schema draft, if there are still differing 
> opinions then these
> > can
> > progress on the architectural side without such a unified 
> draft. Let me
> > know

---

From: Shai Herzog <[email-masked]>
Date: Wed, 19 May 1999 11:48:19 -0400

I fully agree.

If my memory serves me right, we have gone through one interim meeting
where the architecture was put aside and "progress" was declared only
the core schema. At the MN IETF, we figured that we can't make progress
w/o the architecture being done and agreed upon.

There is a reason why architectural document usually precede detailed ones
(or at least come in parallel).  I suspect that the core schema wouldn't 
get us far, on it's own. The lack of clear architectural documents would
probably come to haunt us again when we try to move from core schema to
QoS schema. (or other schemas). 

Furthermore, I don't really think that maintaining one of the proposed
architecture document and changing a picture is good enough to create
a consensus architecture. I suspect that this must be a collaborative
work of the authors of both drafts to come up with something we can
all live with. If we can't accomplish that, I don't see how we can move
forward w/o bumping into this thing again and again.

Shai

>> > Bay Architecture Lab

__________________________________________________________
Shai Herzog                  Founder & CTO, IPHighway Inc.         
Cell: (408) 390-3045       http://www.iphighway.com/herzog           
Tel : (201) 585-0800                  Fax : (212) 656-1006

---

From: "Stevens, Mark" <[email-masked]>
Date: Wed, 19 May 1999 12:25:05 -0400

> First, we considered defining a language, then we considered defining an
> architectural model for an implementation, and of late, we have focused on
> a generalized schema for storing expressions of policy. Each time we
> avoided the step of defining the problem itself. We have shyly backed away
> from defining specific policies. We have only vaguely described them as a
> list of "if-then" expressions.  We need to scope the problem by coming up
> with a list of exemplary policies. We need to define the things that
> appear after the "if" and "then." With a better understanding of the
> specific conditions and actions, we can begin to develop a schema for
> storage and develop an understanding of the constraints imposed by various
> architectural approaches to implementation. 
> 
> Indeed a more detailed problem and goals statement may be in order. I
> believe that we are not moving toward our first tangible goal as stated in
> the charter and it may be due to the wording of the numbered objectives
> listed in the charter. They seem to outline an approach to solving the
> policy problem, but they do not clearly define the problem space itself.
> As a result, they have effectively focused the working group's effort on
> the periphery of an unbounded problem. To implement a uniform policy in a
> network, we need to agree upon a way to store policy expressions of a
> repository, but before we can agree on a way to store these expressions,
> we must agree on what they look like to begin with.
> 
> I do not see how the introduction of an architectural model will move us
> toward a solution when we have not defined specific examples of the kinds
> of policies that we want to be able to implement in a network. Nor, do I
> see how the core policy schema or an architectural model can be tested,
> even by way of mental exercise, without clear and agreed upon definitions
> of specific policies.
> 
> Mark Stevens
> Sent:	Tuesday, May 18, 1999 4:32 PM
> To:	'Stevens, Mark'; [email-masked]

---

From: "Stevens, Mark" <[email-masked]>
Date: Wed, 19 May 1999 12:39:46 -0400

---

From: "Durham, David" <[email-masked]>
Date: Mon, 24 May 1999 17:32:36 -0700

Hi Raju,

I am glad we are spiritually aligned:) I'm sorry I brought up
schema issues since we are (as everyone seems to be agreeing)
putting the horse before the carriage (schema before 
architecture).

My point with the LDAPized core schema is that there needs to be
more thought as to the structure. Groups can contain groups, and
the draft states that cycles are not allowed, but the schema does
nothing to prevent them. So one console can be editing:

Group A contains:
	Group B
	Group C (just added)

While another

Group C contains
	Group D
	Group A (just added)

In practice, such alterations will be very difficult to detect/
prevent leading to a corrupted database. This
could be fixed if there were real structural constraints, such
as only one or a fixed number of levels of groups. These different 
levels of groups could structurally constrain the other kinds they 
can contain, making cyclic-references impossible.

Example:

Categorical groups (CG) can contain Organizational groups (OG)
Organizational groups can contain Sub-groups (SG) which contain
the actual rules/elements.

CG 1:
	OG 1
	OG 2
OG1:
	SG 1
	SG 2
OG2:
	SG 3

Stronger structural enhancements will also help where lack of
atomic transactions will cause problems. Corruption of policies
is a hazardous issue in general, but is more serious when 
elements are ANDed than ORed. For example:

* If (srcuser==Jay && srcaddr==128.132.32.3) then give traffic
 high priority

is potentially more dangerous to get wrong in two transactions than

* If (srcuser==Jay || srcaddr==128.132.32.3) then give traffic
 high priority.

In the first case, if Jay gets set by a console and then the 
host address is specified, a client getting the policy at the
wrong moment will be enforcing the wrong policy. I only wanted
Jay's traffic to get high priority if he is using the host 
128.132.32.3! This would be even worse if it were a security
policy.

In the second case, the incomplete rule will still give the correct
result for Jay or 128.132.32.3, so the client was never actually
enforcing the "wrong" policy... Eventually, it will retrieve the
complete policy. Allowing only DNF style policies with one level
of conditions could force the ANDed statements to be within
the context of a single attribute update.

As yet another gripe, I believe that the associations between 
actions and conditions is too weak. Some actions may only
correspond to specific conditions. I don't see this fact
coming out of the core schema. Conditions should be grouped
together with respect to only the actions that apply. 

Example:

* If (featherColor==Red && beakShape==Oval) 
	then feed bird seed.
vs.
	then feed elephant grass

The first makes sense, the second does not. Allowing arbitrary
associations between actions and condition groups will lead to
strange statement possibilities as these. I believe it is the
task of the schema to be structured so that such ridiculous
things simply cannot be stated. This can be enforced structurally
or simply loosely as additional attributes that specify things
such as "actions of type A relate to conditions of type B & C".

Furthermore, multiple kinds of actions that are grouped together
and associated with multiple kinds conditions further exasperates 
this problem!

...For starter's, I'll let someone shoot these down before I 
perform my next core dump:) Most of my issues could be 
easily addressed if we had a consistent architectural model...

- Dave

> From:	R. Rajan [SMTP:[email-masked]]
> Sent:	Wednesday, May 19, 1999 1:46 PM
> To:	Durham, David; [email-masked]
> Subject:	Re: New Schema I-D Requested to be Posted to IETF Repository
> 
> David,
> 
> I agree with the spirit of your message regarding the need for a coherent
> architecture, design, set of priorities and objectives. However, I am
> perplexed by your assertion that the use of auxiliary classes somehow
> exacerbates problems arising from LDAPs lack of atomic transactions.
> Perhaps
> you could explain how the former makes the latter worse? Thanks,
> 
> raju rajan
> 
> ----- Original Message -----
> From: Durham, David <[email-masked]>
> To: 'Shai Herzog' <[email-masked]>; Andrew Smith
> <[email-masked]>; 'Glenn Waters' <[email-masked]>;
> <[email-masked]>
> Sent: Wednesday, May 19, 1999 1:36 PM
> > I agree as well. Furthermore, the core schema discussion is
> > starting to deteriorate into a convoluted architecture
> > that cannot be consistently represented by all directory
> > implementations. The reason seems to be lack of a consistent
> > architecture picture that clearly states the role of the
> > directory. It's fine that different companies have directories
> > with differing capabilities. Nevertheless the we should
> > not specifically design for one over another!
> >
> > If anyone needs a reminder of what LDAP compliant directories
> > are and are not supposed to do, please see:
> >
> > http://www.data.com/issue/990207/ldap.html
> >
> > Heavy use of auxiliary classes is also a bad design choice
> > do to the fact LDAP lacks the notion of atomic transactions
> > across DNs. It seems like the proposed updates to the core
> > schema architecture will allow for database corruption, and
> > therefore a bad design given LDAP is the standard protocol
> > we should be using.
> >
> > -Dave
> >
> > > From: Shai Herzog [SMTP:[email-masked]]
> > > Sent: Wednesday, May 19, 1999 8:48 AM
> > > To: Andrew Smith; 'Glenn Waters'; [email-masked]
> > > >the details of schemas (surely that is a job for the mailing list,
> no?
> > > And
> > > >list then I guess they don't see much urgency in completing this task
> so
> > > why
> > > >architectural material and opinions that have been presented to the
> WG
> in
> > > >McCloghrie, Bob Moore, Evan McGinnis, David Blight, Hugh Mahon
> etc..).
> As
> > > >with the schema draft, if there are still differing opinions then
> these
> > > can
> > > >progress on the architectural side without such a unified draft. Let
> me
> > > know

---

From: [email-masked] (freichmeyer)
Date: Wed, 26 May 1999 01:52:15 -0400

Mark,

An architectural model, by itself, doesn't necessarily facilitate a
solution. However, the architectural draft(s) that were introduced
at and after the last interim meeting also included some description
on the abstraction of the complexities inherent in policy, at the 
various functional levels of the proposed architecture. One of the 
drafts also talked about concepts such as "roles" and how that might
fit into the abstraction. I think the two together - architectural
model and policy abstraction - can help us get to where you are 
suggesting we should be and I don't think you can separate them.

-Fran

At 11:36 AM 5/25/99 -0400, Stevens, Mark wrote:
>David:
>I don't know that all of the planets are aligned. While I understand the
>transactional and logical problems you outline, I do not see how an
>architectural model will facilitate a solution. Knowing that we have an
>entry console talking to directory, and a policy server talking to directory
>and a network device doesn't bring us any closer to understanding how to
>solve LDAP's lack of atomic transaction support, or how to eliminate cycles
>in the DIT, nor does it bring us closer to solving what I think is the real
>problem, which is expressing network policy in a common, standard format. An
>architectural model would merely speak to an method of implementation and
>implemetations can vary if the policy itself is expressed universally. A
>policy, to be of any value, should represent a business goal, the expression
>of which should not be too rigidly tied to a particular architecture or
>implementation. Architecture should be changeable like the underlying
>technology without severely impacting the expression of policy. Initially,
>the effectiveness of policy statements may be limited by underlying
>technology and architecture, but the current technology should not freeze
>the expression of policy itself.
>
>I think that we need to focus defining the contents of conditional
>expressions and begin to pay attention to defining actions as well. When we
>begin to define the terms of policy statements like "if ((bandwith consumed
>by HTTP traffic) < 15%) then admit a new HTTP flow at medium priority" we
>will be making progress. Terms that represent measurement like "HTTP
>bandwidth" and terms that represent packet treatment like "medium priority"
>need to be defined before we worry about the architecture in which to
>execute such policies and perhaps even the structures in which we store
>them.
>
>Mark Stevens
>> From:	Durham, David [SMTP:[email-masked]]
>> Sent:	Monday, May 24, 1999 8:33 PM
>> To:	'R. Rajan'; [email-masked]
----
Francis Reichmeyer
Bay Architecture Lab
978-916-3352

---

From: Ed Ellesson <[email-masked]>
Date: Wed, 26 May 1999 05:46:08 -0400

Fran, 

I don't think we need the architecture finalized in order to make progress
on the schema.  

The architecture is basically a block diagram that describes the building
blocks of a solution, along with a description of how the building blocks
communicate. In the IETF, it's an fyi thing, not a standards track thing,
because we don't want to dictate the building blocks that someone has to
implement, in order to be "standards-compliant".  However, the
architecture, along with other working group docs, does give meaning and
context to things like "policy repository" and PDP.  Without having final
agreement on the "fyi architecture", my sense is that we do, indeed, have
consensus on what a policy repository is.  We can review whether we do,
indeed, have that consensus, in further discussion on this list, and at the
interim meeting.  If we have consensus on that, then we can make progress
on the schema, because that is what goes into the repository, and that is
what we are standardizing (once we get there), regardless of whether or not
we have all the right angels dancing on the heads of the right pins in the
"fyi architecture".  

My opinion is that the disagreements on architecture are obscuring the fact
that there is common ground on the policy repository, and the "abstaction
level" of what goes into it.  I expect that we won't know for sure that
this is true, unless we dive into a specific example (QOS), asap.  However,
we need some level of stability on a consistent way to represent policy
schema, in order to have the QOS schema discussion.  

My suggestion is that we finish "a consistent core policy schema" (it won't
be the final one), to a sufficient level of stability that we can use it to
try to represent the QOS-specific example, and then see where it breaks and
then fix it, once we better understand the example.  That is a way to move
forward without throwing out all the good work we have already done to
date, with a way to validate it through the consensus process. 

Regards, 

Ed Ellesson

---

From: Andrew Smith <[email-masked]>
Date: Wed, 26 May 1999 10:43:04 -0700

Ed,

The block diagram may well be a "FYI thing" but the rest of us working
groups in this space have to fit into the diagram consistently. It has been
made very clear to us, procedurally, that this block diagram must be agreed
before we can proceed with work on e.g. device communication
protocols/formats.

So, concensus on the diagram does have an importance beyond its official
status as "FYI".

Regarding "a consistent core policy schema": I think a "policy framework" WG
last call at the appropriate time would be "a sufficient level of stability"
for the schema - I would caution against going the next step of *IETF* last
call (and PS RFC) before we have done sanity check of building a QoS schema
out of it and finding out where, if anywhere, it breaks. Unlike a MIB, for
example, the core schema is just a set of building blocks and is not a
self-standing specification.

Andrew
RAP WG co-chair

> From: Ed Ellesson [mailto:[email-masked]]
> Sent: Wednesday, May 26, 1999 2:46 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: sanjay <[email-masked]>
Date: Wed, 26 May 1999 14:11:10 -0400 (EDT)

And I would like to add the following to what has been discussed so far on this thread:
 1. Let us bear in mind that the mission of this group is not to collectively design
    a Policy Based Networking solution but to agree on a minimal set of specifications
    for storing, retrieving and interpreting policy information in a consistent way
    so that products from multiple vendors can inter-operate. 
 
 2. We cannot pretend that "policy based networking" is a mature field and that the first
    set of specs will be able to handle all conceivable policies right away. We got to
    start simple and evolve with implementation and operational experience. If the policy
    work focuses on standards that will facilitate creating and managing VPN services 
    (QoS + security using DiffServ, RSVP, IPSEC standards) it would gather a lot of
    momentum. If we don't make progress soon enough, customers will have to resign to 
    proprietary policy management solutions that will fall short of the desired goal.
 
 -Sanjay Kamat
 
> 
> 
> 
> > 
> > Hi all,
> > 
> > The lack of consensus over "architecture/framework" is not merely on
> > technical or design issues. There are underlying disagreements over the role
> > of policy (should it be used to "program" the network or merely configure
> > protocols), what protocols should be addressed (DS, RSVP, IPSec, DHCP, HTTP
> > ???), and how far should the group go in its standardization efforts (schema
> > only?, PFDL?, server to server protocol?). These issues go directly to the
> > charter of the group, and are not resolvable based on an "architecture".
> > Anyone writing an architecture draft has to assume certain answers to the
> > above questions, and it is no surprise that different assumptions lead to
> > completely different designs.
> > 
> > I would urge the WG chairs to put out a new charter, with clearly stated
> > goals and meaningful timelines. And it would be so much nicer to have this
> > posted first on the mailing list, rather than have it sprung (even as a
> > pleasant surprise) on us at the interim meeting.
> > 
> > raju rajan
> > 
> > 
> > 
> 
>

---

From: "Durham, David" <[email-masked]>
Date: Wed, 26 May 1999 12:20:21 -0700

Ed,

If the architecture question can wait, why is there so much work 
going into the core schema so that it is "optimized" such that 
multiple queries/etc. need not be performed, etc. In the extreme,
these optimization tricks are causing the core schema
to be incompatible with some directory implementations!

Seems like the LDAP core schema work is assuming an architecture
and attempting to *FORCE* optimizations for it!!!

My take is that more efforts should be made to improve the design
of the current core schema (so that it is usable by multiple 
vendors, prevents illogical policies, fixes cyclic grouping issues, 
etc.) and less effort should be spent on obscure optimizations only 
required by some architectures.

-Dave

-----Original Message-----
From: Ed Ellesson [mailto:[email-masked]]
Sent: Wednesday, May 26, 1999 2:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: New Schema I-D Requested to be Posted to IETF Repository

Fran, 

Regards, 

Ed Ellesson

---

From: [email-masked] (freichmeyer)
Date: Wed, 26 May 1999 13:39:18 -0400

Ed,

>I don't think we need the architecture finalized in order to make progress

	I didn't mean to imply that we we need a *finalized* architecture
to make progress on the schema. My point was that the acrchitecture AND
abstraction (together) should help address the "what's a policy?" type
questions that have re-surfaced lately. And that, in turn, should help
determine the schema content.

>we have all the right angels dancing on the heads of the right pins in the

	Maybe. But I'm not sure just saying "we know what a repository is"
is enough to determine what goes in the repository, since what goes in
(and out) of the repository should, IMHO, depend on what is reading/writing
the repository. If this wasn't the case, the architecture discussion and
drafts would never have been started - the "architecture" could be a one
box diagram, labeled "repository". I feel the schema, architecture (including
text for discussion on things like "roles") AND abstraction need to progress
together.

-Fran

----
Francis Reichmeyer
Bay Architecture Lab
978-916-3352

---

From: "Durham, David" <[email-masked]>
Date: Fri, 28 May 1999 17:32:40 -0700

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!

> > the context of a single attribute update
> 
> Your gripe regarding the "weak link" between condition and action is well
> made.
> >Conditions should be grouped
> Sometimes, it's better to allow for the possibility of error or nonsense
> ("feed elephant grass") than being too restrictive about what people can
> say
> ("feed elephant brand grass seed"). I would be interested in seeing what
> proposal you have in this regard.
> 
	[[Dave]]  I certainly don't want to be too restrictive, but
	it seems that the semantics can be improved such that 
	illogical constructs cannot be made. I would suggest taking
	advantage of the DIT structure to root all policies under
	entries that determine what valid combinations may be made.
	Categories such as RSVP vs. DiffServ vs. IPSEC come to 
	mind. Categorical classes of rules can also be formed that 
	specify only the relevant conditions and actions directly
	as attributes...