can XACML help at the granularity of endpoint-policy?
On Nov 7, 2003, at 1:23 AM, Jacques Durand wrote:
Here is a summary of the two major options I believe we face about dealing with timing, as outlined in previous mails,
and my analysis of their advantages / disadvantages.
After consideration, I personally favor Proposal #1 (the one we started on at f-2-f).
Tomorrow I will map this time management proposal to our list of current issues,
and propose corresponding resolution/impact to several of them.
The schema so far is same as last proposed in f-2-f.
Jacques
Proposal #1: (use time parameters)
-----------
Uses ExpiryTime, GroupExpiryTime, MaxGroupIdleTime, here carried in the protocol
(messages), as discussed last f-2-f.
The group termination follows rules based on these values, as we outlined them
in f-2-f, and of which I propose/summarize a complete version in draft sent out Nov 2.
Advantage:
- group duration, scope of duplicate check, is clearly controlled
by these parameters. Semantics is clear to users.
- control of storage space is better (much less chance to overflow available space)
- synchronization between sender and receiver via protocol (same understanding
on both sides, of persistence conditions).
Drawbacks:
- possible abuse by users (the RMP may have to "cap" these values, based
on some configuration).
- implementors must implement these rules in order to conform to spec (more complex).
Proposal #2: (timeless)
------------
Does NOT specify ExpiryTime, GroupExpiryTime, MaxGroupIdleTime.
Instead, groups and message IDs are kept open and persisting until some garbage
collection takes place, controlled by config for each implementation.
Advantage:
- no "termination" management is required to conform to specification. Simpler spec,
Easier to implement.
Drawbacks:
- the contract about the scope of dup elimination, of group duration, is unclear
as controlled by storage availability, possibly differently by each impleemntation.
- synchronization of termination and removal of states between Sender and Receiver unclear.
- more chance to overflow available storage, watermark parameters for space limits
will be reached more often, making terminations of persisted groups and message IDs
unpredictable.
