Subject: RE: [midcom] Straw poll - results so far

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 20 Jun 2001 10:23:52 -0700

This either-or winners-losers alternative is not going to 
satisfy the WG. I perceive that feelings about OOP Agents
are very strong on both sides and this decision is only 
going to alienate participants (e.g., I deeply believe that 
OOP Agents are unacceptably dangerous and I've seen nothing 
to make me think otherwise. I firmly intend to bring out my 
objections again once last-call comes and I'm 
sure that I will have allies in the security community.
We'll thus be right back to where we are now once 
that happens). I reiterate therefore that a compromise is 
needed if the group isn't going to divide over this issue. 
Let me re-state my proposed compromise. Please try it on for 
size, and then come up with another version that would best 
satisfy all:

1) The framework document primarily deals with In-Path 
Agents -- i.e., restricts itself to the scenarios identified 
by Christian Huitema's Scenarios draft, which I believe is 
the charter of both the FW document and this WG. In-Path 
Agents will thus comprise the vast majority of the material 
within the frameworks document.
2) However, the framework document should explicitly mention 
that OOP agents are an implementation possibility and that 
the following benefits accrue by including OOP agents 
(an enumeration can then be made by the OOP advocates).
3) However, should OOP agents be implemented, those OOP 
agents should be implemented to appear to be MIDCOM Agents 
resident on end systems (and, by implication, their 
implementation is accomplished via proprietary/vendor-
specific methods rather than something specifically detailed
by the Midcom WG).

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 10:00 AM
To: Keith Moore
Cc: [email-masked]
Subject: Re: [midcom] Straw poll - results so far 

> seems like if there's no consensus to include oop agents, they 
> should be omitted - rather than giving the impression that the
> group supports oop agents.  

I'd prefer to leave it to the judgment of the editor
unless he's obviously out in the weeds somewhere.  At
this point there's not agreement that he is.

Melinda

_______________________________________________
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: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 13:28:55 -0400

> (an enumeration can then be made by the OOP advocates).

if the framework document mentions OOP agents at all, it should 
try to summarize both pros and cons.  that would come as close
as possible to expressing the overall opinion of the group.

Keith

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 14:07:43 -0400

> as possible to expressing the overall opinion of the group.

To both of you: we're trying to do some engineering with this draft.
The pros and cons can go into an Analysis RFC.  All we want is a
framework.  I like Eric's compromise, but just a mention that such
things are possible, a brief description of how they would work, and any
required protocol extensions -- without any opinions about good and bad
-- would be plenty.  We have mechanisms for adding the pros and cons, or
for removing the text entirely, later on.

...Scott

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 20 Jun 2001 14:21:26 -0400

I find the proposal acceptable. But just to make sure I understand, the
MIDCOM protocol would not include support for any sort of "diversion" (like
tunneling), but would be extensible such that a proprietary extension could
be implemented to enable diversion to OOP agents.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "Melinda Shore" <[email-masked]>
Date: Wed, 20 Jun 2001 14:35:40 -0400

> be implemented to enable diversion to OOP agents.

The MOST we would be doing in terms of protocol support
would be including some sort of diversion information
element/AVP/whatever - the mechanism to transport diverted
packets from the middlebox to wherever is so far out of
charter that I'm not sure why the question was raised.  I
think that the question of whether or not diversion information
would be standardized or proprietary remains open - there
are people who feel strongly that we must provide that
facility and those who feel we must not.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Jun 2001 14:45:39 -0400

On Wed, Jun 20, 2001 at 02:21:26PM -0400, Bob Penfield wrote:
> tunneling), but would be extensible

The midcom protocol will be decided in Midcom 2.0, but it will certainly
be extensible anyway.  We're not as omniscient as we think we are, we
have to make it repairable.

> such that a proprietary

or standard

> extension could