Subject: RE: [midcom] Framework last call -- level of middlebox intellig ence

From: [email-masked]
Date: Mon, 30 Jul 2001 17:01:27 +0100

Sounds like straying into the details of the requirements document. I
suggest we put this text there and not in the Framework document.

regards

Richard

> -----Original Message-----
> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: 30 July 2001 16:22
> To: Melinda Shore; Mark Duffy; [email-masked]
> Subject: Re: [midcom] Framework last call -- level of middlebox
> intelligence
> 
> 
> As such, middleboxes that understand the transporty headers
> (ex: TCP, UDP and SCTP?) has been the focus of this WG. 
> I can certainly state this in the document. Anything beyond
> the transport headers will be assumed to require 
> application-specific intelligence. Thanks.
> 
> cheers,
> suresh
> 
> --- Melinda Shore <[email-masked]> wrote:
> > At 04:53 PM 7/23/01 -0400, Mark Duffy wrote:
> > >Why am I looking for this?  Because without stating this 
> we in fact have
> > >very little.  It doesn't mean much to say midcom allows moving the
> > >"application" intelligence from the middlebox to the 
> midcom agent if one
> > >does not define where the "applications" begin.  No?
> > 
> > That's an excellent point.  We (the collective "we" - there's
> > certainly been some disagreement, however) have been assuming 
> > that we're dealing with transport-layer middleboxes and there
> > seems to be some consensus around having us not skip past the
> > transport (TCP, UDP, SCTP) headers.  We must stay mindful, 
> > however, of the possibility that either future iterations or
> > vendor-proprietary extensions will want to go deeper into the
> > packet, and must therefore require that the protocol be
> > sufficiently expressive to allow something beyond {address,
> > port, proto}.
> > 
> > Melinda
> > 
> > 
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> 
> =====
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with 
> Yahoo! Messenger
> http://phonecard.yahoo.com/
> 
> _______________________________________________
> 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: Scott Brim <[email-masked]>
Date: Mon, 30 Jul 2001 12:24:29 -0400

We continue to run into this issue of how much "framework" to put in
requirements draft, and how much "requirement" to put in the framework
draft.  The process is iterative -- each builds on the other.
Requirements are the most sensitive, I think.  Therefore I suggest that
any time the framework editors want to make an assumption about any
requirement in the framework draft, they put it in with something which
clearly marks it as an assumption (e.g. ">>ASSUMPTION<<"), and ask
explicitly on the list and get consensus on it.  When the requirements
draft editors feel a need for context, I suggest that that context be
added, but that it be moved to the framework draft as soon as possible.
My ideal would be for the requirements editors to feel comfortable just
referring to the framework for all context, and for every assumption in
the framework draft to be brought out explicitly in the requirements.

In this particular case, I believe we already have consensus that
middlebox packet manipulation will stick to the transport layer headers
and below (I mean, what's the point of this WG otherwise?).  Therefore
the next step is for that statement to go into the framework draft.  Lo
and behold, we have: "However the Middlebox must not alter packet
information unless it appears in the packet header. This is to ensure
that there is an appropriate separation of concerns between the MIDCOM
Agent and the Middlebox."  All we have to do is get explicit agreement
on what "packet header" means, perhaps tweak the text, and we have
alignment.

I think "packet header" should be changed to "IP and transport headers".
Secondarily, I would also like to see this requirement made more
visible.

imho ... Scott