|-----Original Message-----
|From: Yakov Shafranovich [mailto:research(_at_)solidmatrix(_dot_)com]
<snip>
|
|Please take a look at the work of the POLICY WG of the IETF
|(http://www.ietf.org/html.charters/policy-charter.html). One of the
|documents written by that group is RFC 3060
|(http://www.ietf.org/rfc/rfc3060.txt). It states as follows:
|
<snip>
|
|This looks like something that can be used for representing
|consent within
|our group. Let me know what you think.
I've reviewed the majority of RFC3060. I find it interesting that we've
created a nearly identical object model in the XML-CPDL example from an
independent approach. I also guess that it is to be expected given the
subject.
To compare:
Refer to page 11 in RFC3060.
PCIM represents objects in the RFC.
XML-CPDL represents objects in our proposal.
PCIM:System is analogous to XML-CPDL:SYSTEM
PCIM:PolicyRule is analagous to XML-CPDL:POLICY
PCIM:PolicyGroup is analagous to XML-CPDL:GROUP
PCIM:PolicyCondition is analogous to XML-CPDL:TEST
PCIM:PolicyAction is analogous to XML-CPDL:ACTION
The grouping of these elements in a given XML-CPDL:POLICY uses the
Conjunctive Normal Form as described in RFC3060.
A counterpart to PCIM:PolicyTimePeriodCondition is not yet showing in
the XML-CPDL example, however it is presumed that adaptive policy
mechanisms such as temporary network blocks will make use of these
elements.
In our proposal, XML-CPDL:GROUP is further abstracted to provide
functionality for sharing all elements within a CPD (not restricted to
PolicyRules and PolicyGroups). Also XML-CPDL:GROUP and XML-CPDL:POLICY
elements are further contained within a POLICIES structure. - The
meaning of this structure is "The local system's policies". Presumably a
comprehensive, system-wide representation of a CPD might include a
number of POLICIES elements deliniating the localized POLICY elements
for each SYSTEM described in the CPD. This might occur in practice if a
large ISP or other larger system wished to produce a single document
that represented all of the policy elements in their entire system. In
this way the XML-CPDL provdes a mechanism for representing policies in
widely varying scopes (those of single users, domains, groups of
domains, entire systems, or even large segments of a network).
In RFC3060, PolicyGroups may contain collections of PolicyRule OR
PolicyGroup objects, but not both. No such restriction has been stated
for XML-CPDL thus far. My feelings on this are that this _may_ be an
arbitrary restriction for this application. The proof will be evident if
we can present a case that is complicated by the mixing of rules and
groups in the same hierarchical level. My intuition is that an
artificial restriction would be more trouble than benefit... but better
thinking may prevail later on.
PCIM:PolicyRepository is analogous to the combination of XML-CPDL:TESTS
and XML-CPDL:ACTIONS. If it is desired, we _could_ easily contain the
XML-CPDL:TESTS and XML-CPDL:ACTIONS elements in a structure similar to
PCIM:PolicyRepository... This would be symetrical with the
XML-CPDL:POLICIES element - while this is aesthetically pleasing I don't
have a strong technical reason for it (yet)... not that having a reason
to impose symmetry has ever stopped me before ;-) (provided there was no
reason not to of course). Along these lines, I think that
PolicyRepository is probably a bad choice of names in RFC3060 since what
is collected there are policy fragments and not actual policies - that
is, collections of PCIM:PolicyCondition and PCIM:PolicyAction objects
rather than collections of PolicyRule and/or PolicyGroup objects.
-- Long story short, I will consider the implications of imposing a
collection upon XML-CPDL:TESTS / ACTIONS - in particular a recursive,
herarchical collection as represented in PCIM:PolicyRepository. That
said, it occurs to me that there may be value in isolating
XML-CPDL:GROUP for use only in XML-CPDL:POLICIES and then deriving a
symmetrical counterpart for use in the XML-CPDL counterpart to
PCIM:PolicyRepository.
One good reasons to create a hierarchical model (other than GROUP) in
this area might be to clarify the creation of ACTION and TEST groups
that have a particular affinity. For example, the collection of ACTION
and TEST elements that are on the "well known" list, and subsets of
those that may be inherited by different "SYSTEMs" such as users, domain
admins, etc...
--- I think I can see in the above comparison that some minor
modifications might be made to the XML-CPDL example... I will cogitate
on them and take a stab at it.
One final thought regarding the use of a Declarative vs Procedural
paradigm. Here again the XML-CPDL agrees with RFC3060. Further, the
XML-CPDL example makes a strong recommendation that any Procedural
elements should be coded in an implementation specific way when creating
XML-CPDL:ACTION and/or XML-CPDL:TEST objects where appropriate; and that
these ACTION and TEST object should then be applied in POLICY objects in
a strictly Declarative way. This separation provides for not only
clarity, but some measure of simplicity when sharing policies between
different SYSTEMs.
An additional agreement between the XML-CPDL and RFC3060 is that the
sequencing of XML-CPDL:TEST and XML-CPDL:ACTION elements, when combined,
is implementation specific.
It was stated earlier in this forum, but I will emit a note into the
XML-CPDL document: It is presumed that a strong implementation would
optimize the sequencing of TEST execution (and presumably ACTION
execution) including the preemption of TESTs once the final
determination of a policy is apparent. For example, if a high priority
policy indicated that connections from network x were to be refused,
then an implementation would perform that test first, and if the test
proved true then all other tests would not be executed and the
appropriate action(s) for the policy would be executed immediately
(presumaby "RefuseConnection"). << The above presumes that no other
policy is detected in the CPD that might conflict.
Comments strongly encouraged.
HTH
Thanks,
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg