[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [BEHAVE] RE: Firewall control



 
 > <Hannes.Tschofenig@gmx.net> wrote:
 > > Another one would be: "Why do the IPv4 solutions don't 
 > work given that they
 > > are designed with extensibility in mind?"
 > 
 > The only work I saw the Soliman draft reference was NSIS, which
 > uses a different signaling model.  There's been a lot more work
 > done closer to the client-server model, which is what they're
 > proposing also, and I gather that they're not familiar with it.

=> I would appreciate a link to something that I can read about similar
proposals in this area. I'm aware of James' work and probably should have
added it to the references but unintentionally didn't. 

 > 
 > I think that you're closer to right about what the real question
 > is.  Nearly any solution to any problem introduces new problems,
 > and I think in general the new problems introduced by both path-
 > coupled and path-decoupled middlebox signaling are sufficiently
 > intractible that we either end up resisting doing them at all or
 > choose instead to go with a bunch of hacked-up messy stuff that's
 > very situational.  

=> I find it difficult to discuss a wide range of problems in different
deployments on such generic level. Of course every solution introduces new
problems but that is never a reason to dismiss a solution IMHO. There is
also a wide range of firewall deployment scenarios as you know and while I
can think of some that don't need this approach, others definitely do. 

So I agree with one aspect of Hannes question, which is: what was the
problem with other proposals. Lets discuss that. The first part of the
question is not really useful because it doesn't tell us what those
solutions are that we're supposed to compare with. 

Hesham

 > 
 > I realize that the IETF doesn't do architecture but it seems to
 > me that somehow this bigger question needs to be handled before
 > putting effort into a different version of the same old thing.
 > 
 > Melinda
 >