> > It certainly shouldn't be prescriptive. This relates more > to the policy > > manager service which is not exposed in FeSL - so what PID > to use when > > generating new policy objects. It wouldn't be used to > differentiate between > > (for instance) policy objects and other objects. > > Ahh, I see. Is the policy manager service used for anything > other than > bootstrap (and unit tests :)? (or intended to be?) From one of the > motivations - "there is no way of manipulating XACML policies other > than through direct access to DbXml" - I would guess not.
used for - no (apart from the tests!). intended to be - it was in Muradora, it's an open question as to the form of a policy management API > > > There will be some bootstrap policies - so this namespace > would apply to > > those. > > By 'bootstrap', do we mean 'insert core fedora system default policies > only into a new, pristine, uninitialized repository'**? If > so, then it > may be useful to have this value non-configurable and set to something > like 'fedora-system', so that these core policies receive consistent > pids if present. > I think these correspond to the default XACML policies in the existing (pre FeSL) Fedora XACML implementation, so "bootstrap" is possibly wrong, default (and editable as per the existing implementation) would be more correct. I'd suggest they shouldn't be in a "fedora-system" namespace unless they are non-editable and somehow essential to make Fedora "work". Are the objects that are currently in the fedora-system namespace editable? > > Actually I was thinking of policies as stand-alone objects, > rather than also > > having POLICY datastreams in "conventional" Fedora objects, so that > > parameter was to identify which datastream contains the XACML. > > > > I'd be interested in hearing if there's much demand for > having policy > > datastreams within data objects. > > As I understand it, the current (non-FeSL) architecture has both > repository-wide policies, and object-specific policies > (resident in the > POLICY datastream). See section 2.2.2 in > http://fedora-commons.org/confluence/x/LgBM for a more precise > description of what I am trying to describe. Are we considering > deprecating this feature with FeSL? I think there's a difference here between deprecating and not yet implemented within FeSL ;o) A question here is whether to (continue to) standardise on a datastream called POLICY for XACML policies, whether within existing "data" objects or in stand-alone policy objects, or to make that more flexible. > ** The emphasis on 'pristine unitialized', since someone may > conceivably > wish to remove a system policy, by purging that object. They > certainly > would not want bootstrap to add it back! The existing FeSL > implementation (and existing non-fesl implementation) 'bootstraps' > policies by reading them from a directory, where the directory is the > canonical preservation location of the policies. Presumably, > this would > be undesirable with fedora-backed policies, as the Fedora is the > canonical store now. That's my understanding also. The "bootstrap" (default policies) would essentially be part of the initial installation. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
