Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 24 Sep 2002 11:16:57 -0400

This is the second note on draft-stiemerling-midcom-semantics-02.txt.  This
note discusses the role of policy groups (AKA session bundles).

The draft makes this statement about groups (sec. 2.3 third para): 

  "Group transactions are redundant in the sense that a transaction on a
   group can be replaced by the corresponding transaction on each member
   of a group (except for the GE transaction)."

The main part of this statement is consistent with the opinion ventured at
IETF 54, that a group is simply a shortcut for operating on multiple policy
rules at once.  In fact, the idea that a group should have a separate
lifetime of its own was disparaged.  Based on the IETF 54 discussion, the
following changes would be appropriate in
draft-stiemerling-midcom-semantics-02.txt:

Sec. 2.3 sixth para currently reads:

  "Each group that is not a default group has its individual lifetime.
   If the group lifetime expires, the group and all member policies will
   be deleted at the middlebox.  A group lifetime change (GLC)
   transaction may extend the lifetime of the group up to the limit
   specified at session setup, when the middlebox informs the agent
   about its capabilities. Also a GLC transaction may be used for
   deleting a group by requesting a lifetime of 0.  After a successful
   GLC transaction, all member policies have the same lifetime as the
   group.  Please note that by policy-specific transactions, the
   lifetime of an individual policy may be set to other values than the
   group lifetime, but an individual policy lifetime may never exceed
   the group lifetime."

This should instead become:

  "A group lifetime change (GLC) may extend the lifetime OF THE POLICY
   RULES IN THE GROUP up to the limit specified at session setup, when
   the middlebox informs the agent about its capabilities. Also a GLC
   transaction may be used for
   deleting a group by requesting a lifetime of 0.  After a successful
   GLC transaction, all member policies have the same lifetime as the
   group.  Please note that by policy-specific transactions, the
   lifetime of an individual policy may be set to other values than the
   group lifetime."

In the Group Establishment request, if the group lifetime parameter is
retained at all, it would be the default lifetime for new policy rules
assigned to the group if not stated explicitly in the request establishing
the policy rule.  I'm even less sure of the usefulness of this parameter in
the Group Establishment reply.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 25 Sep 2002 10:54:51 +0200

Tom,

I aggee to your arguments. When defining the semantics, we started
exactly like this following the discussion we had at the Yokohama
WG meeting:

    Basically, there is no need for a group timer.

And consequently there is no need to negotiate group lifetime when
creating a group, as you correctly state in your last paragraph.

However, reality prove to be more complicated than expected.
If you don'y use group timers, you need other means for deleting
groups.

For the semantics definition we considered four alternative choices
of group deletion:

  1. You don't care: a group once established lives forever.
     Please not that we support policies surviving an interruption
     of the session and hand-over from one session to another.
     In this context also groups should survive.
     But groups existing forever might not be a desirable choice,
     because group garbage might sum up at the middlebox.

  2. You request that a group is deleted if the number of member
     policies becomes 0. This implies the following semantical
     problems: When you delete a policy, you might also delete a
     group. This group deletion needs to be signaled to the agent
     (known and stable state!). So you would need either to reply
     on the policy deletion request with a group deletion reply
     or with a special policy deletion reply indicating that also
     the group was deleted. Both choices would conflict with the
     clean separation between group transactions and policy
     transactions we achieved.

  3. You explicitly add a group deletion transaction.

  4. You add a group timer to the group creation request and to
     its reply.

Because of the reasons given above, we first eliminated 1. and 2.
Then we had to decide between 3. and 4. Out of these, we
chose 4. for the following reasons:

  - It is less overhead adding an additional parameter to
    an existing transaction and to its reply than adding
    and entire transaction

  - Group timers are handled in exact analogy to policy timers.
    his is easy to understand and implement.

So, we introduced group timers again, because we considered
them the best solution for the group deletion problem.

    Juergen