Subject: RE: [midcom] Back at it

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 20 Sep 2001 14:43:53 -0500

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Thursday, September 20, 2001 10:32 AM
> To: [email-masked]
> Subject: [midcom] Back at it
> 
> 
> Let's get back to work on finishing up the requirements,
> particularly now that we've got basic agreement on terminology.
> Today's items:
> 
> R1a: The MIDCOM protocol must enable a MIDCOM agent requiring
>     the services of a middlebox to establish an authorized
>     association between itself and the middlebox.
> 
> Proposal: keep

OK

> 
> R10: A middlebox must be able to notify a midcom agent of
>     the following events: Session creation, session termination,
>     MIDCOM protocol failure, middlebox function failure, or any
>     other significant event.  Independently, ICMP error codes
>     can be useful to notify transport layer failures to the agents.
> 
> Proposal: keep, align terminology, delete last sentence (mechanism
> is out of scope)

Need to define "Session". Also, I assume that this means asynchronous
notification of certain events as they occur at the MB. If "Session" here
implies a ruleset, then they'll be created & destroyed at the command of the
MA, & they don't need to be notified. The only exception to this is when the
timer associated with the ruleset expires (which may terminate the ruleset)
- this will need asynchronous notification to the MA.

I agree that the last sentence be deleted.

> 
> R13: Agent hosting entity (whatever that is) must be identified in
>     the midcom protocol.
> 
> Proposal: delete, unless this is intended to say more than the agent
> must be identified.  Otherwise I think it's self-evident (we've got
> authentication/authorization requirements - identity is implicit in
> those).

Agreed.

> 
> R14: Once a connection is established between a middlebox and a MIDCOM
> agent, that connection should be usable with multiple instances of
> the application(s), as appropriate.
> 
> Proposal: if we're going to keep this we need to 1) align the 
> language,
> and 2) clarify the text quite a bit.  I think that this is intended to
> say that the midcom protocol should be able to support multiplexing
> requests from different applications and multiple requests 
> from the same
> application across a single midcom session, yes?

 The session between the MA and the MB should be transparent to the end
applications, which is obvious. Not sure whether this requirement tries to
convey anything else. If not, delete.

Sanjoy