Subject: Not an architecture draft

From: [email-masked]
Date: Tue, 2 Mar 1999 15:54:14 -0800

(See attached file: blockitecture.pdf)

So I've obviously missed the deadline for submitting a formal proposal,
but I at least wanted to followup from the Raleigh meeting with  some views
from some internal 3Com discussions that describe, in rough terms, what
we want to build.

I've attached a coarse blockitecture that describes some of the scenarios
we want to support within our devices and software.

I've placed the usual PEP & PDPs on the diagram, but we want to have the
flexibility to arrange these in one of several configurations.
For the purposes of illustration, I've introduced a new term here, policy
execution point (PXP) to call out the conceptual difference between
the entity that 'programs' the policy into a device, and the logic that
actually executes that behavior.  My point in this is that the execution point
may be the entity that dictates whether or not a policy can be actually be
instantiated, not the thing that programs it (what others have termed the proxy)

We want to build 3 sorts of devices:

1) A device with only an execution point, programmed by an enforcement
engine.  The enforcement engine, in turn is controlled by a decision point.
For example: The decision and enforcement points might carry on
a COPS conversation, but the device may only have a CLI
associated with it.

2) A device with an on-board enforcement engine that is capable of
carrying on conversations with the PDP.
For example: A COPS client on board a switch
There's an additional requirement here, however, in that the enforcement
engine may require some additional 'contextual' information from
the directory itself, but it may be something such as organizational
structure, and not policy.

3) A device with a co-located decision and enforcement point.
For example: a device with an LDAP client on board, and the
associated logic capable of downloading policies, interpreting
them, and using its internal enforcement mechanism to carry out
the intentions of the policy.

In each of these scenarios, the PDP's can be controlled and monitored
through things like IIOP or SNMP.  PDPs can use these same mechanisms
for signalling back to the policy tools.

So, as long as the defining infrastructure allows for each of these cases,
we're going to be happy.

However, I do have some concerns over trying to standardize too much.
If we put on the 'master architecture' that we've got conflict detection
engines,
message passing engines, etc, does that mean we intend to standardize
or define those at any depth?

-Evan-