Subject: [midcom] Framework section 4

From: [email-masked]
Date: Wed, 1 Aug 2001 09:07:49 +0100

Hi,

I have been looking at some of the text in section 4 of the 03 framework
draft. The Third paragraph seems to embed quit a few assumptions as a
requirement. 

1. I don't think this actually adds any value to the framework as it relates
to pure protocol behaviour and should be deleted from this document.
2. Debate the requirements and document them in the requirements document
(actually these are kind of already there but we have not debated the
concensus on them I don't believe).

regards

Richard

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 1 Aug 2001 09:10:49 -0400

> concensus on them I don't believe).

Richard, could you be more specific?  I think it's reasonable to
describe use of the midcom protocol in the framework.  Let's see, the
implicit requirements I can find which might be contentious are:

- "The MIDCOM protocol will consist of a connection setup phase,
  run-time connection phase and a connection termination phase." There's
  an assumption of "connectedness" underlying all of this which I
  believe we have moved away from.  I don't know what "connection" is
  intended to mean here.  The requirement to be debated would be
  something like: "While an agent is registered with a middlebox, both
  will maintain a 'connected' state by periodically ensuring the other's
  well-being."  No?

- "Midcom is a peer-to-peer protocol. As such, either the agent or the
  middlebox may choose to initiate the connection."  I don't think this
  is really contentious but it would be nice to list it in the
  requirements and get explicit agreement on it.

Assumptions which are NOT contentious (imho):

- Functions in the same device don't have to communicate by IP.  That's
  true (they can also play pennywhistles), and it doesn't matter, it's
  completely out of our scope (which is okay when setting context).

- "Connection setup must be preceded by registration of the MIDCOM agent
  with either the middlebox or the Policy Server."  I suspect
  "registration" has two different meanings here, since "registration"
  with a policy server produces different results from "registration"
  with a middlebox.  However I think this is reasonable.  If a policy
  server is involved at all, then there may be some means -- out of
  scope for midcom -- by which an agent makes itself known to the policy
  server, and the policy server tells the middlebox about it.  I think
  it's reasonable to let the middlebox initiate communication with an
  agent.

- "A MIDCOM session may be terminated by either of the parties.  A
  MIDCOM session termination may also be triggered by one of (a) the
  middlebox or the agent going out of service and not being available
  for further MIDCOM operations, or (b) policy server notifying the
  middlebox that a particular MIDCOM agent is no longer authorized."

- "The MIDCOM framework is designed to be extensible to support
  deployment of other services as well."

..Scott