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

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

I like your code fragment. It's the type of thing I was also envisioning. 

Concerning back and forth, here's what I was thinking:

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

That is, I was not envisioning the requester being able to "argue with" the Middlebox concerning the 
middlebox's decisions, but merely a establishing a request/reply protocol between them.

That's what I've been thinking. What have you been thinking?

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

Eric,

Thanks for your comments.  You raise a rather large concern, however.  How
much back and forth would you expect to have happen in the midcom
protocol?

Consider the following code-frag:

<open proto=TCP, from=(Internal,10.1.44.2,port=18294),
to=(external,128.33.28.12,port=110),
application=Netscape,duration=unknown,bandwidth=unknown,user=(lear,[credentials];
request=NAT>

Noting that some of this information will not always be available, what
would you like to receive?
--
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 09:50:48 -0700

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]