Subject: [midcom] New requirement bullets for decision

From: Melinda Shore <[email-masked]>
Date: Tue, 02 Oct 2001 15:04:54 -0400

Now under consideration:

R46: The Midcom Protocol MUST support the concept of an aggregated
        Pinhole-Descriptor comprising a multiple of individual flows to
        be treated as an aggregate.

Proposal: keep

R47: When accepting a request for a pin-hole, the Middlebox MUST be
        able to provide the MIDCOM Agent with information that may be
        used to identify the resource in subsequent operations.

Proposal: clean up the language and keep.  Need to change "accepting
a request for a pin-hole" and "resource."

R60: An operation is needed to enable a MIDCOM Agent to request that
        a Middlebox maintain (refresh) an established Pin-Hole over
        which the Agent has ownership.

Choose between two options: 1) accept this, or 2) instead create a
requirement for idempotent operations which can create new thing-on-
the-box or extend the lifetime of an existing thing-on-the-box.

Melinda

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Oct 2001 16:15:23 -0400

>         be treated as an aggregate.

OK, but suggest the following wording:

"The protocol MUST support the concept of a ruleset group comprising a
multiple of individual rulesets to be treated as an aggregate."

The idea is to associate together a bunch of rulesets that form some sort of
application level session. For example, all the RTP flows for a SIP session.

Do we need to explicitly say that this should not preclude the agent from
issuing requests that effect individual rulesets or the group as a whole?

> a request for a pin-hole" and "resource."
OK. Suggest:

"The protocol MUST allow the middlebox to provide information to the midcom
agent for an installed ruleset (or ruleset group) that may be used to
identify the ruleset (or ruleset group) in subsequent operations."

The idea is to allow the middlebox to allocate some sort of identifier that
could be used in subsequent requests instead of having to use the 5-tuple+.

> the-box or extend the lifetime of an existing thing-on-the-box.

Option 2. Suggest:

"The protocol MUST allow the midcom agent to extend the lifetime of an
existing ruleset that otherwise would be deleted by the middlebox."

This could be done by having the midcom agent 1) re-issue the whole request
in the same manner that the SIP session timer is adjusted by issusing a
re-INVITE, OR 2) issue a request that identifies the ruleset and specifies
the specific attribute(s) to be changed (the timer) like the Megaco Modify
command does. The requirements should not dicate/proscribe a choice.

---

From: Scott Brim <[email-masked]>
Date: Tue, 2 Oct 2001 17:10:12 -0400

> application level session. For example, all the RTP flows for a SIP session.

This is a lot better than the original.  

> issuing requests that effect individual rulesets or the group as a whole?

I'd leave it without the extra comment.

> identify the ruleset (or ruleset group) in subsequent operations."

What's the goal?  The easiest way to identify a ruleset or a ruleset
group is to state it again.  What exactly are you trying to do that
brings out this requirement?

> command does. The requirements should not dicate/proscribe a choice.

OK.

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Oct 2001 18:17:50 -0400

"Scott Brim" <[email-masked]> wrote:
<snip>
> brings out this requirement?
The idea is that the middlebox could assign an ID that could be used in
subsequent requests to refer to the ruleset (or group). It decreases the
verbosity of the protocol. Otherwise you would have to specify the whole
5-tuple every time. Also, if parts of the 5-tuple change as a result of the
request, do you use the original one or the modified one? For example, if
I'm requesting a NAT for an RTP flow for SIP/H.323 the ruleset request will
look something like this:

filter: source=*:*,dest=<pick-one>:<pick-one>,transport=UDP
action: forward-to-dest=10.0.0.7:47210

If the middlebox collapses from a cone-NAT to a symmetric-NAT based on the
first packet, the "source" in the 5-tuple changes, and the midcom agent does
not necessarily find out what it is.

Which is a better "key" for the ruleset? One that is allocated when the
ruleset is created and remains constant or one the changes over the life of
the ruleset?

(-:bob

---

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Oct 2001 23:54:03 -0400

>application level session. For example, all the RTP flows for a SIP session.

If in fact this is a requirement, I like Bob's statement of it above.
I would however make the observation that if there is such a requirement,
then there must be a way to name the ruleset group in the midcom protocol.
_Perhaps_ that can be based on naming a ruleset in the group and indicating
a reference as being to the entire group containing thet ruleset rather
than to the individual rule.  However, I would not be surprised if the
protocol ended up with some other identifier assigned to the group itself.
Which sounds to me to be pretty closely related to what R47 is about.  If
we have the MB assigning handles for ruleset groups, it may as well assign
them for individual rulesets as well.