|
Hi David,
Thanks for a thoughtful response, even if my original posting wasn't directed specifically at you. J
I believe that the root of the problem lies in the wording of PCIMe. I note that in PCLS, the dreaded priority rule attribute is NOT mandatory, viz:
( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule' DESC 'The base class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP pcimPolicy ABSTRACT MAY ( pcimRuleName $ pcimRuleEnabled $ pcimRuleConditionListType $ pcimRuleConditionList $ pcimRuleActionList $ pcimRuleValidityPeriodList $ pcimRuleUsage $ pcimRulePriority $ pcimRuleMandatory $ pcimRuleSequencedActions $ pcimRoles ) )
Hopefully, we've already agreed that deprecation is a Bad Thing in a schema. And I completely agree with your third issue - as a co-author of PCIMe, I voted against this change as I couldn't understand the logic, but was out voted. I note that this falls under the area of Bert's "don't bring it up again".
At this point, I need to reread your thorough analyses and possibly 3460 and 3060 to see what went wrong. Although I hope that the PCELS authors will reply before me, especially since my time is rather limited this week.
regards, John C. Strassner -----Original Message-----
John,
I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced. My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM. My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it. My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction. By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters.
The core key issues that limit compatibility between PCIM and PCIMe are as follows: - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility
You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM.
If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM.
Regards, d.
|