Subject: [midcom] More bullets

From: Melinda Shore <[email-masked]>
Date: Thu, 27 Sep 2001 15:43:54 -0400

R15: A Midcom agent ought to be able to have a single MIDCOM
        connection with a middlebox and use the MIDCOM interface on the
        middlebox to interface with different middlebox functions on the
        same middlebox interface.

I'd like to drop the trailing "interface" on this one and propose
keeping this.

R44: The protocol MUST permit the expression of direction to be
        associated with a pin-hole.  The direction MUST be specified in
        terms that apply to external view of the Middlebox.  This
        directionality shall be expressed as 'in', 'out' or 'loopback'
        (meaning both 'in' and 'out' of the same side of the same
        Middlebox realm).

The proposal is to drop this: we've already accepted R82, which gives
broad leeway in descriptions of filtering rules.

R74: A Midcom Agent MUST be able to discover what resources are
        available on a middlebox.

Proposal: drop.  We've already discussed meaningful error messages.

R68: The Midcom Protocol MUST allow for preservation of the control
        messages once the association has been established.

Proposal: drop.

Once we get these settled we'll tackle semantics.

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 27 Sep 2001 16:18:18 -0400

> I'd like to drop the trailing "interface" on this one and propose

What other functions would an agent use the midcom protocol for, besides
the one (managing rulesets) which we've already covered in other
requirements?  Why would the midcom protocol be a better way to get at
those functions than some other existing protocol?  I think it's better
to drop this entirely until we know specifically what the need is.
Whatever the midcom protocol ends up doing, it will be exactly what
needs to be done and no more.  I'd leave this up to the next WG.

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 27 Sep 2001 17:03:50 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "midcom" <[email-masked]>
Sent: Thursday, September 27, 2001 3:43 PM
Subject: [midcom] More bullets

> I'd like to drop the trailing "interface" on this one and propose

I believe what this is saying is that we don't want to have to establish
separate midcom sessions to access different middlebox functions (e.g. one
for NAT and one for firewall). I think this even extends to the ruleset in
that we don't want to be forced to make seperate rulesets to establish a
firewall pin-hole and a NAT binding for the same flow.

Anyway, this needs to be re-worded to align it with the current terminology.
I suggest:

"A midcom agent ought be able to use a single midcom session with a
middlebox to access different middlebox functions"

OR

"A midcom agent ought to be able to access different middlebox functions
using a single midcom session with the middlebox"

> broad leeway in descriptions of filtering rules.

I agree.

> Proposal: drop.  We've already discussed meaningful error messages.

I agree.

>         messages once the association has been established.

I agree.