Subject: Re: [midcom] Filtering rules

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 17 Aug 2001 00:06:15 +0100

I think that the following statement could buy peace on earth:

The agent requires the Middle Box to provide services over a stream or
several streams (open pinhole, provide a BIND ...), therefore the MB needs
to have a proper matching (or filtering expression) to identify the
stream(s) on which it will apply the requested service.

Comments?

Cedric

-----Original Message-----
From: Paul Sijben [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 10:32 AM
To: Scott Bradner; [email-masked]; [email-masked]
Subject: Re: [midcom] Filtering rules

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

Paul Sijben wrote:
> 
> Scott,
> 
> > 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
> 
> 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
> 
> Scott Bradner wrote:
> >
> > > 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)
> 
> --
> Paul Sijben              Tel:+31 356874774
> Lucent Technologies      Fax:+31 356875954
> Forward Looking Work
> Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom

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

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