Subject: [midcom] Latest requirements bullets resolved

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Sep 2001 08:41:02 -0400

R1a: keep
R10: fix up terminology, delete last sentence
R13: delete
R14: delete

Melinda

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

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 Sep 2001 09:35:22 -0400

>R10: fix up terminology, delete last sentence

Hi Melinda,
Can you please clarify how the terminology is to be fixed?  I presume you
mean clarify the terms "Session creation, session termination".  However, I
saw 2 different understandings of what this is about during the discussion
last week.    Are we fixing it to clarify that these refer to the/a midcom
session (I hope not) or to clarify that they refer to application sessions
(microflows?) through  the middlebox?
Thanks, Mark

---

From: Scott Brim <[email-masked]>
Date: Mon, 24 Sep 2001 10:09:33 -0400

> (microflows?) through  the middlebox?

How could a middlebox know anything about application sessions being
created or terminating?  The middlebox has no application intelligence
anymore.  Request for installation of a ruleset cannot be assumed to
imply anything at a higher layer.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Sep 2001 10:23:55 -0400

At 09:35 AM 9/24/01 -0400, Mark Duffy wrote:
>Are we fixing it to clarify that these refer to the/a midcom

Application sessions and "microflows" (still don't like that
term for our purposes) aren't the same thing.  We're trying
to get application involvement out of middleboxes.  Taking off
the chair hat for a moment, the way I see it the middlebox should
really only be notifying agents of events which affect that 
particular agent, whether it's a protocol failure of some sort,
reboot, etc.  I don't think that any notion of "session" we 
could come up with would be something that the middlebox ought
to tell the agent about.  My preference would be to drop the
two "session" events entirely and reorganize the sentence so
that it make it clearer that the protocol must allow the
middlebox to notify the agent of significant events, such as ...
Right now it's a little too much like an enumeration of events.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 Sep 2001 10:52:11 -0400

>imply anything at a higher layer.

While the middlebox should no longer need "application intelligence", my
understanding is that it should still have "transport layer intelligence".
E.g. it should be able to detect close of tcp sessions, detect which
direction the connection is opened in, etc.  And, probably it should be
able to tell an agent that a ruleset has "expired" since the relevant
transport connection has closed.  

If we instead interpret the language of R10 as referring to *midcom*
sessions, a number of questions arise:
  Does the middlebox notify agents about sessions it has with other agents?
 I should think not.  My understanding is that that would be out of scope.
  Does the middlebox notify an agent that its own session has been created
or terminated?  What would be the meaning of that?  I understand this
requirement (R10) to be about asynchronous notifications.  I think other
requirements (e.g R23, R34, R1a) cover the establishment and maintainance
of the midcom agent between an agent and middlebox and presumably that
mechanism is such that both ends can determine whether the session is there
or not.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 Sep 2001 11:02:23 -0400

>Right now it's a little too much like an enumeration of events.

OK.  How about just dropping R10 entirely and we can cover this with R32,
or some evolution of R32.  ("R32: The protocol MUST support unsolicited
messages, for event reporting and propagation of alarms.")

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 24 Sep 2001 12:02:21 -0400

In that particular requirement (R10), I am fairly sure that the term session
was being used in its NAT context where is really does mean "flow" (or
"microflow") and not "application session". In any event, the requirement
that I have (and I'm sure others share this) is that the protocol include a
means for the middlebox to notify the midcom agents when particular events
relative to a ruleset occur. This includes things like timeout and
termination.

(-:bob

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 24 Sep 2001 12:29:32 -0400

On Mon, Sep 24, 2001 12:02:21PM -0400, Bob Penfield allegedly wrote:
> "microflow") and not "application session". 

In that case let's delete it.

> In any event, the requirement

You want to know when a ruleset timer expires?  But you're the one who
set it.  What is 'termination'?

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Sep 2001 12:36:26 -0400

>messages, for event reporting and propagation of alarms.")

I'm always delighted to have a concrete proposal and I like this
one, with the caveat that R32 isn't yet accepted and that we should
get some text in place for R32.  We need to be sure that the intended
requirement is covered.

If someone has some proposed text to cover this, please post it.

Thanks,

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 24 Sep 2001 13:15:32 -0400

As Mark stated, if a particular type of middlebox is "aware" of a TCP
connection being terminated, it could tell the midcom agent.

As far as the ruleset timer, why should I time the ruleset in the midcom
agent if the middlebox is doing it for me? The midcom agent needs the
middlebox to tell it when the rule has expired so that it can take care of
the application state.

For VOIP with SIP, you might have an "inactivity timer" to solve the so
called "Lost BYE" problem. If the middlebox is capable of detecting that no
more packets for a given ruleset are traversing the middlebox for some
specified period of time, it could tell the midcom agent which could then
terminate the application session.

There will likely be a variety of events that occur in the middlebox that
the midcom agent wants to know about. If this is covered by R32, then we can
delete R10.

(-:bob

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

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 Sep 2001 14:03:51 -0400

>If someone has some proposed text to cover this, please post it.

Old R32: The protocol MUST support unsolicited messages, for event
reporting and propagation of alarms.

Proposed R32: The protocol MUST support unsolicited messages from middlebox
to agent, for reporting conditions detected asynchronously at the middlebox.