Subject: [midcom] Trying to bring this to closure ...

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Aug 2001 09:10:53 -0400

We need to try to find some middle ground on this filter
rule problem.  Scott proposed that we leave it at the oft-
mentioned 5-tuple.  Would it be sufficient to say that the
midcom protocol must be able to carry filtering rules,
including but not limited to the 5-tuple, from the midcom
agent to the middlebox?  

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 17 Aug 2001 09:48:46 -0400

> including but not limited to the 5-tuple, from the midcom

Exact agreement.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 17 Aug 2001 10:36:18 -0400

>including but not limited to the 5-tuple, from the midcom

I could be happy with that.
Even more so if it went on to say that the criteria filtered on must be
readily extensible.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Aug 2001 10:02:00 -0500

What he said

   Brian

---

From: Scott Brim <[email-masked]>
Date: Fri, 17 Aug 2001 11:26:06 -0400

> Even more so if it went on to say that the criteria filtered on must be

These aren't going away, and express the requirement better by
themselves than they would if bundled with the tuple (minimum
requirement):

   R2: The syntax and semantics of the Midcom Protocol MUST be
       extensible to allow the requirements of future applications to be
       adopted.

   R41: The MIDCOM Protocol MUST contain version inter-working
        capabilities to enable subsequent extensions to support
        different types of Middlebox and future requirements of
        applications not considered at this stage.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 17 Aug 2001 10:25:58 -0500

I think that for the filters being requested 5-tuple should be sufficient
(as it is currently).

I also believe that the agent would be requesting a filter from the
middlebox based on application signaling (in the case of SIP and SDP).

It would not necessarily be carrying a filter rule, rather requesting a
filter be defined. In the case of SIP/RTP it may also request a precedence
be applied to the filter if the middlebox is capable of this level of packet
filtering.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Melinda Shore
> Sent: Friday, August 17, 2001 8:11 AM
> To: [email-masked]
> Subject: [midcom] Trying to bring this to closure ...
>
>

---

From: Mark Duffy <[email-masked]>
Date: Fri, 17 Aug 2001 11:39:05 -0400

Hi Scott, 
I was well aware of R2 when I proposed the statement below, and I proposed
it anyway because it made a clear requirement that extensibilty was
required *in this specific area*  as well as just in general.  That said,
as I stated earlier I can be satisfied with what Melinda proposed (without
the additional extensibility clause).
-Mark

P.S. We've been having this discussion using the term "filtering rules".  I
am presuming that term is subject to revision according to the terminology
being selected?