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

From: "Tom-PT Taylor"<[email-masked]>
Date: Sun, 14 Apr 2002 10:53:41 -0400

Let me propose this to ensure determinsitic behaviour:

(1) The Middlebox must support a queue model of rules.

(2) New entries can be added either at the head of the queue (processed
first when looking for a match) or at the tail of a queue (processed last
when looking for a match).

(3) Existing entries can be deleted from anywhere in the queue.

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]]
Sent: Friday, April 12, 2002 5:26 PM
To: John LaCour
Cc: [email-masked]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

On Fri, Apr 12, 2002 at 12:54:17PM -0700, John LaCour wrote:
> 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.

<SNIP>
> The protocol need only to be able to express the request
> and the result.
> 
> -John

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

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

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 15 Apr 2002 09:59:42 -0400

> (3) Existing entries can be deleted from anywhere in the queue.

What is the engineering reason for this ordering?  I mean, yes, this
would make behavior deterministic, but does it make the middlebox do
what you want?