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

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 20 Jun 2001 12:01:33 -0700

Melinda,

Perhaps I'm not alone in having trouble understanding this important
posting which you've just sent. I'd really appreciate you clarifying
your points further, so that I could more adequately understand what
you are saying. Please note that the following are real questions/
confusion on my part, not polemics:

I had thought that what we were doing with the framework and the
scenarios documents are providing the scoping and requirements of the
forthcoming Midcom protocol. If so, why are we mentioning diversion
functions if it is "so far out of charter that I'm not sure why the 
question was raised"? How can we provide "protocol support" for 
"diversion information element/AVP/whatever" without specifying 
mechanisms? If we are going to open a can of worms, we certainly
need to provide constraints so that implementers know what to do with
those worms. But more fundamentally, WHAT ARE WE TRYING TO DO with
the frameworks draft? Have we not strayed tremendously far from our
charter for that draft in the OOP parts of the current version? (The 
last sentence sounds like a polemic but it isn't intended to be 
one: I'm truly confused in understanding what you are thinking.)

--Eric

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 11:36 AM
To: Bob Penfield
Cc: [email-masked]
Subject: Re: [midcom] Straw poll - results so far 

> 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.

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

_______________________________________________
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: "Melinda Shore" <[email-masked]>
Date: Wed, 20 Jun 2001 15:21:21 -0400

> forthcoming Midcom protocol. 

We have two deliverables:  1) a framework document, which
lays out the rationale, use cases, and network framework, and
2) a document describing the protocol requirements.  The
scenarios document is not a deliverable.  (The new draft of
the requirements document will appear on the website in the
next day or so - it's in the hands of [email-masked]
and just needs to clear the queue.)

> If so, why are we mentioning diversion
> question was raised"? 

That's an obvious question.  Packet diversion was
never mentioned during the chartering process and it's
my PERSONAL suspicion that it never would have been
accepted by the Greater Powers if it had been.  The
charter that was approved is quite clear about what
we're working on and what we're responsible for delivering
(and, not so incidentally, WHEN we're supposed to
deliver it).  

We are absolutely not authorized to go ahead and invent 
a packet diversion transport protocol, nor are we chartered 
to develop a framework or requirements for it.  Stuff that 
goes in the midcom protocol: in scope.  Stuff that requires 
inventing a new protocol that was never discussed during the 
chartering process:  out of scope.

Melinda