Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: John LaCour <[email-masked]>
Date: Fri, 12 Apr 2002 12:54:17 -0700

How a middlebox resolves potential rule conflicts
and rule precedence should be left up to middlebox
implementors and is not something that the protocol
needs to be capable of expressing.

The middlebox will need to have it's own authorization 
and precedence model which resolves these issues not just 
between competing midcom agents but also for things like:

- application layer gateways
- automated responses due to some event detected by the middlebox
- scheduled policies
- competing management entities

Solving the problem for competing midcom-agents, if you can
do that, doesn't solve the whole problem anyway.

The protocol need only to be able to express the request
and the result.

-John

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Apr 2002 14:26:25 -0700

> needs to be capable of expressing.

<SNIP>
> The protocol need only to be able to express the request

What "the result" means here seems to me critical to determining
whether or not John's prefered approach (implementation-specific rule
conflict resolution) can meet Scott's test of deterministic behavior.
The automated teller message of "your envelope has been accepted" is a
classic case of the result code crafted not to promise much
(especially not that the money will show up in your account.)  A
result like "rule accepted into set" without an evaluation of whether
or not it is in force results in the same unsatisfactory result (can I
use the pinhole?  can I spend the money?).

				regards,
					Ted Hardie