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

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 25 Sep 2002 09:30:06 -0400

With the changes in wording I proposed, I intended that any group timer
setting would reset the time to live on on policy rules currently in the
group, even if these times had been set previously on a per-policy basis.
Thus your group deletion mechanism still holds.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Wednesday, September 25, 2002 4:55 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
> Cc: 'Martin Stiemerling'
> Subject: Re: Comments on 
> draft-stiemerling-midcom-semantics-02.txt: Role of Gr oups
> 
> 
> 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
> 
> 
> -- Tom-PT Taylor wrote on 24 September 2002 11:16 -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 16:04:02 +0200

Tom,

> Thus your group deletion mechanism still holds.

Then we have full agreement. Maybe, we just phrased it not clear
enough in our draft when describint the group lifetime change (GLC)
transaction:

   "After a  successful GLC transaction, all member policies
    have the same lifetime as the group."

Juergen