Re: 'config' vs. 'policy'

Answers embedded ..

At 04:52 PM 6/12/2002, Michael Carr wrote:
>Apologize in advance if this question isn't appropriate for this list, but not sure who/where else to ask.

This list is probably as good as you get, since this WG established the
design team that wrote RFC 3198, which attempted to deal with your question.
Without claiming that the issue is clear, you might find some guidance there.

>I'm wrestling with trying to explain to developers the difference between a 'policy' (e.g., 'if packet_type = X, put it on queue Y') and other switch/router 'configuration' (e.g., ethernet interface 2 autosense = on).  What I have said thus far is that a policy is something that can be expressed in an "If condition then action" clause.  Also, I've made the bold statement that static policies are part of configuration, but not all configuration data is policy.

I don't recall any consensus that the distinction between policy and
configuration is the distinction between dynamic and static configuration.

> But then I hear high level "policies" in the storage networking space like "Minimum backup count for file X is 2".  To me this is configuration, not policy.

We included both statements of the goal state such as "voice traffic will
get less than 100 ms variation in delay across the network" and rules as
possible definitions of policy, but the framework settled on rules as the
way to represent policies in an information model. Without proof, we
concluded that statements of goals could be re-stated as rules.

>I guess I'm looking for a clearer definition.  Why does it matter?  When trying to design and build an extensible policy engine framework (side issue: does anyone already do this?), it helps to know the domain of the problem set first, and optimize for that domain.  Throwing things that aren't really policies into such an engine might lead to a suboptimal/inefficient design with respect to the ones that really are policies.

We would be gratified if our adventure in practical semantics actually
mattered for a system you developed.

John