Subject: RE: [midcom] on "diversion"

From: "Anderson, Todd A" <[email-masked]>
Date: Tue, 27 Mar 2001 11:01:26 -0800

I have only been following the MIDCOM work recently so I don't know for 
sure whether interactions 2 and 3 have been declared "in scope" but it
seems like they haven't so I'd like to throw my 2 cents in.  From my
perspective, if I am a midcom client, I don't care about the architecture
of the middlebox.  If the middlebox has a separate application controller,
I don't want to be aware of that fact.  I want the firewall and
controller to behave as one virtual box.  Therefore, I think it is very
important to clearly separate interactions 1 and 4 from 2 and 3.  Having
said that, I am in favor of efforts in the 2-3 space such as OPES.  It
also seems like part of the ForCES work is in this same area.  I think I 
understand the motivation to get into this area though because whatever 
one carries in 1 and 4 also has to be respresented in 2 and 3.  However,
2 and 3 may be solved as part of a more general problem and I don't think
they should be addressed by this group.

Todd

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2001 10:19 AM
> To: Eliot Lear
> Cc: Randy Turner; [email-masked]
> Subject: Re: [midcom] on "diversion"
> 
> 
> This looks exactly like the OPES call-out model to me, except that 
> OPES is restricting the domain of discourse to HTTP and RTP based
> apps.
> 
>    Brian
> 
> Eliot Lear wrote:
> > 
> > To me, diversion means the following (the numbers next to the lines
> > indicate the data flow):
> > 
> >     __________
> >    |          |
> >    | External |
> >    |  Host    |
> >    |__________|
> >        v
> >        |
> >        |
> >        |1
> >        |
> >        |
> >     ___v______     2        ______________
> >    |          |>---------->|              |
> >    |  NAT /   |            |  Application |
> >    | Firewall |<----------<|  Controller  |
> >    |__________|    3       |______________|
> >        v
> >        |
> >        |
> >        |4
> >        |
> >        |
> >     ___v______
> >    |          |
> >    | Internal |
> >    |  Host    |
> >    |__________|
> > 
> > Although I indicate flow direction from external to internal, the
> > opposite flow direction would also be considered a diversion.
> > 
> > Note that (3) is optional.  It's quite possible that the
> > application controller could conceivably consume the flow in its
> > entirety (like in the case of a transparent cache).
> > 
> > Requiring this sort of capability, and even mentioning it, is
> > a rathole.  I'm not arguing that we should go out of our way to
> > prevent it, but let's not go out of our way to do that either.
> > 
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Program Director, Internet Standards & Technology, IBM 
> On assignment for IBM at http://www.iCAIR.org 
> Board Chairman, Internet Society http://www.isoc.org
> Non-IBM email: [email-masked]
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

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

---

From: [email-masked]
Date: Wed, 28 Mar 2001 15:10:07 -0700

While I agree that no protocol work in midcom should be done in support of
diversion, I'd like to second Scott Brim's earlier statement that we
shouldn't necessarily remove from the conceptual framework doc any and all
mention of the use of diversion, as I think it could provide valuable
context for understanding middlebox deployments.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 2:38 PM
To: Maciocco, Christian
Cc: [email-masked]
Subject: Re: [midcom] on "diversion"

Well, now.  It sounds like we have consensus.  Let's not do diversion 
and leave that for OPES (if anywhere).