Subject: Re: [midcom] Filtering rules

From: Scott Bradner <[email-masked]>
Date: Tue, 14 Aug 2001 08:15:37 -0400 (EDT)

> I would appreciate some guidance in this matter from the ADs. If we can
> not specify in enough detail WHAT we want to filter/transform etc on.
> Selecting a protocol will be impossible and we will need to go through
> another (semi) requirements round to get additional information. 

I see no need to spend time at this point figuring out all possible filters
I would like the WG to define a basic 'punch a pinhole' function for
a single stream and identify the stream in the simplest possible way.
i.e. 5-tuples

this should be sufficient to get something that will work - when that
is done we can worry about creating the filter language from hell if
that is what the Internet community feels it needs.

also - I see no reason that the midcom protocol needs to change just
because of a change in filter rules - any such rules should be
sent in a chunk to the midcom box which can then say 'can not do' if
it does not know how to do what has been asked 

Scott (the AD in question)

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

---

From: Paul Sijben <[email-masked]>
Date: Tue, 14 Aug 2001 14:22:26 +0200

Scott,

> it does not know how to do what has been asked

I can agree with you there if we were to create a _new_ protocol. Yet we
are supposed to _select_ one that exists when the requirements are done.
So the power we may seek in the filtering may guide our protocol choice.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2001 08:34:48 -0400

>So the power we may seek in the filtering may guide our protocol choice.

!!!  I certainly hope not.  The protocol will be a transport for
whatever we say it's going to transport, and there's absolutely
no dependency whatsoever on the details of the filter specification.  
I don't see a need to specify a filter spec at all at this time -
I do think it's sufficient to say that the protocol must be
capable of transporting filter specifications from the agent to
the middlebox.  

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 14 Aug 2001 10:18:08 -0500 (CDT)

> a single stream and identify the stream in the simplest possible way.

	I agree whole heartedly. I cannot tell you the horror I felt,
as a packet filtering designer and implementor these last 8-9 years,
at the idea of taking some nasty packet filtering description in
tcpdump format or whatever other hellish thing got invented, and
compiling that into my own thing.

	Anyways, it's a layering violation, and a pretty severe one,
and one that doesn't need to get done. A SIP proxy doesn't have any
business knowing what RTP packets look like inside.

	I was actually girding my loins for a much longer and more
boring missive on exactly this issue.

> that is what the Internet community feels it needs.

	How do you feel about extending the 5-tuple to include an
arbitrary cookie like 'RTP' which the middlebox can ignore? Obviously
there's a namespace management issue here. Is the IETF already managing
such a namespace? Certainly anything more complex strikes me as a frob
nobody will ever implement.

---

From: Paul Sijben <[email-masked]>
Date: Wed, 15 Aug 2001 10:31:39 +0200

Scott,

after having slept a night over this issue. I believe you are right. Just
the 5-tuple will do nicely for anything we may come up with at the moment
and it will not unduly inconvenience us when selecting a protocol.

paul