Subject: RE: [midcom] More bullets

From: "Christian Huitema" <[email-masked]>
Date: Thu, 27 Sep 2001 13:41:20 -0700

> On Thu, Sep 27, 2001 03:43:54PM -0400, Melinda Shore allegedly wrote:
> > 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.
> 
> 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.

Second that. We have no intent of exposing a function decomposition in
the protocol, let alone imposing it. Drop R15.

-- Christian Huitema

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

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 27 Sep 2001 13:42:26 -0700

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

Yes.

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

Yes.

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

Yes.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 27 Sep 2001 17:44:13 -0700

> Ok how about:
> 
> The protocol MUST support the ability of an agent to use one
> MIDCOM session to install different types of rulesets in the
> same middlebox.

I would be even more specific. "When a middlebox performs both a NAT and
a firewall function, it should be possible to specify firewall traversal
rules and document mappings in a single ruleset."

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 28 Sep 2001 08:19:50 -0700

> > "different types of rulesets" conveyed over one Midcom 
> session is not the
> > same thing as different types of action specs conveyed in 
> the same ruleset.
> >  Lets be clear about which or both of those we want.  
> Personally, I think
> > the first should be a requirement; I'm not so sure about the second.
> > 
> > Also, let's not specifically limit this to NAT, FW type 
> middlebox functions.

The point is not to limit this to NAT, FW, but to make sure that NAT &
FW are well covered. After all, this *is* the priority of this working
group.

-- Christian Huitema