Subject: RE: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 10 May 2001 10:13:52 -0700

Eliot,

I had not considered this alternative. If I understand you correctly,
you are considering a system where the communications solely are:

requester ====> Middlebox
(Optional:  Middlebox ====> PDP followed by Middlebox <==== PDP)

If this is accurate, then how will the application or 
individual who made the original request know whether or not it
was granted? This is a very important issue for us end users. 

Please picture the following scenario: you are I are trying 
to set up a conference between our two organizations. Let's 
say we are going to use NetMeeting or some other H.323 technology. 
My system makes a request to our firewall and your system makes a 
request to yours -- or maybe mine makes the request to both -- it simply 
doesn't matter for this example. Anyway, we human beings have done all we can 
do and we try to start the session only to find that we fail to obtain an end-to-end
connection. In my approach we know why the connection failed because the Middlebox
has told us the status of our request. How does one know that in your approach? 
Specifically, what do you and I do next to establish our session, given the approach 
you are considering?

--Eric

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 9:51 AM
To: Fleischman, Eric W
Cc: [email-masked]'; [email-masked]'
Subject: Re: [midcom] Comments on draft-ietf-midcom-scenarios-01.txt

I have a goal of no negotiations in the classic sense, just as we pretty
much avoided it with EHLO.  Back and forth as you describe has performance
implications.
--
Eliot Lear
[email-masked]

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 May 2001 15:30:00 -0700

Hi Erik,

I'm not proposing NO feedback to the client.  I would, however, like the
client to make known all that is necessary on the first pass, or in the
absolutely worst case, the second pass.  

In other words:

client -> middlebox with request and that code frag I sent earlier. 
middlebox -> client with response, possibly including a valid ip address
it will be using.

What I want to avoid is this:

client -> middlebox (request)
middlebox -> client (i need username, application name)
client -> middlebox (username lear, application name netscape)
middlebox -> client (i need src,dst,proto)
client -> middlebox (src=10.1.33.23,4323,dst=128.33.239,110,TCP)
middlebox -> client (i need duration)
client -> middlebox (duration=1h)

user to both ends: (i need a coffee)

this is the sort of chit chat i want to avoid.
--
Eliot Lear
[email-masked]