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

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 30 Sep 2002 12:12:32 -0400

Just to be clear: I intended in my comments that it be possible, after
setting a group lifetime, to set individual policy rule lifetimes which
exceed the lifetime of their group.

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Wednesday, September 25, 2002 10:04 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
> Cc: 'Martin Stiemerling'
> Subject: RE: Comments on 
> draft-stiemerling-midcom-semantics-02.txt: Role o f Gr oups
> 
> 
> Tom,
> 
> -- Tom-PT Taylor wrote on 25 September 2002 09:30 -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.
> 
> 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
> 
> >> -----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