Subject: Part2: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-sc hema-04 .txt

From: [email-masked]
Date: Fri, 26 Mar 2004 07:47:10 -0600

my message has exceeded the 40 k limit.
see below part2

> -----Original Message-----
> From: Pana, Mircea 
> Sent: Thursday, March 25, 2004 9:59 PM
> To: 'John Strassner'; [email-masked]'
> Subject: RE: [Policy] FW: I-D
> ACTION:draft-reyes-policy-core-ext-schema-04 .txt
> 
> 
> John,
> 
> I have reviewed your comments in detail and made several 
> changes to the PCELS text (to be submitted in a few days) to 
> address these issues. While for the most part I understand 
> your concerns, there are a few items that I would like to 
> discuss in more detail. See my comments below marked 
> <mircea></mircea>.
> 
> Thank You,
> Mircea.
> 
> -----Original Message-----
> From: John Strassner [mailto:[email-masked]]
> Sent: Friday, February 13, 2004 9:32 PM
> To: [email-masked]'; [email-masked]'
> Subject: RE: [Policy] FW: I-D 
> ACTION:draft-reyes-policy-core-ext-schema-04 .txt
> 

[...]
(continues...)
>   - Page 16, section 4.6, 
>     - s/CompoundPolicyActionclasses/CompoundPolicyAction classes 
>     - conditions /actions/"conditions/actions" (and other places)
> <mircea>Fixed.
> </mircea>
> 
>   - Page 22. How are you going to enforce an "ordered set of 
>     rules /groups"? That is, how can you guarantee that the DSA stores
>     your rules/groups [sic] in the order that you want, and where is
>     that order specified? What if a DSA doesn't have ordering 
> controls?
>   - Same section as above - you say that the "association 
> entries enable 
>     relative ordering of the aggregated pcelsPolicySet 
> instances within 
>     the scope of the aggregating pcelsPolicySet" - how is this 
>     accomplished with a plain, vanilla LDAP server with no controls?
> <mircea>Text revised and note added to indicate that 
> applications must not expect the LDAP data store to implement 
> sorting and ordering.
> </mircea>
> 
>   - Page 23 - the DESC for pcelsPolicySetList should say that it
>     contains an UNORDERED list of DN references.
> <mircea>Fixed.
> </mircea>
> 
>   - Page 23, note above Section 5.2, is slightly incorrect. Only those
>     implementations that WANT TO BE COMPATIBLE WITH PCELS should use
>     this aggregation mechanism instead of those defined by PCLS. Not
>     every implementation mechanism is going to want to change.
> <mircea>Revised. The section defining pcelsRule for example 
> will include the following compatibility note:
> 
>    "Note 2: PCELS implementations SHOULD support pcelsRule and its two
>    subclasses and MAY also support pcimRule and its two subclasses
>    [PCLS]. Applications that choose to support pcelsRule and its two
>    subclasses MUST use the aggregation mechanism provided by
>    pcelsPolicySetAssociation for aggregating policy groups or policy
>    rules in policy rules represented as instances of pcelsRule.
>    Applications that intend to be compatible with [PCIM_EXT] MUST
>    support pcelsRule and its two subclasses."
> 
> </mircea>
> 
>   - Page 23, Section 5.2, says "The pcelsPolicySetAssociation 
> class is 
>     used to aggregate instances of pcelsPolicySet into other entries."
>     This is incorrect, as pcelsPolicySet is abstract and thus 
> cannot be
>     instantiated.
> <mircea> I fail to see a problem with "instance of 
> <abstract_class>". It is obvious that it means "instance of 
> non-abstract subclass of <abstract_class>". The "non-abstract 
> subclass of" is superfluous and has been omitted in order to 
> improve the text readabilitiy. PCLS, for instance, uses such 
> expressions on several occasions. E.g.: (PCLS page 50 first 
> paragraph) "instances of pcimRules". Note that "pcimRules" is 
> not a class name.
> </mircea>
> 
>   - Same section, you write: "...realizes a (subclass of)
>     PolicySetComponent aggregation [sic]. When subordinated 
> to (subclass 
>     of) dlm1System...realizes a PolicySetInSystem association [sic]".
>     How can the same element realize an aggregation in one 
> usage and an
>     association in another usage? This is semantically inconsistent.
> <mircea>I fail to see the issue. The semantics of 
> pcelsPolicySetAssociation are context sensitive.
> </mircea>
> 
>   - Next paragraph says: "A non-reusable instance of (subclass of)
>     pcelsPolicySet is attached as auxiliary class directly to the 
>     pcelsPolicySetAssociation entry." Subclasses of 
> pcelsPolicySet that
>     are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The
>     above sentence only makes sense for pcelsRuleAuxClass.
> <mircea>The new specification will include pcelsGroup as 
> well. As result, the current text will make more sense.
> </mircea>
> 
>   - Next paragraph doesn't make sense. First, you clearly mean a non-
>     abstract subclass of pcelsPolicySet. Second, you are recommending
>     that an ERROR be ignored? Why don't you stop operation?
> <mircea>Revised text:
> 
>    "When reading a pcelsPolicySetAssociation instance that has a
>    pcelsPolicySet attached, the attribute pcelsPolicySetDN MUST
>    be ignored. Applications SHOULD remove the pcelsPolicySetDN value
>    from a pcelsPolicySetAssociation upon attachment of a 
> pcelsPolicySet
>    to the entry."
> 
> This gives applications some flexibility.
> </mircea>
> 
>   - Page 24, DESC of pcelsPriority is insufficient, as "0" has special
>     semantics that you haven't mentioned. This should, of course, also
>     be present in accompanying prose, as Kurt points out.
> <mircea>The PCIM_EXT property and the attribute value 
> restrictions going to be described in more detail (in prose). 
> However I fail to find the meaning of "0" in PCIM_EXT. Can 
> you help me locate the text?
> </mircea>
> 
>   - Page 24, DESC of pcelsPolicySetDN should state that this is an
>     UNORDERED list of DNs.
> <mircea>Fixed.
> </mircea>
> 
>   - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule
>     Class and Its Subclasses
> <mircea>Fixed.
> </mircea>
> 
> <note: at this point I'm not going to correct any remaining grammar
>  errors, such as the next line ("The pcelsRule is...") because there
>  are too many of them.>
>   - Page 24, Section 5.3, you say: "The pcelsRule is the base class
>     representing policy rules." Does this mean that an implementation
>     can NOT use the subclasses of pcimRule anymore?
> <mircea>I fail to see the issue.
> </mircea>
> 
>   - Page 24, next paragraph, you say: "This class shares the 
>     Condition/Action aggregation methods with the
>     pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass
>     object classes.". Why does it also not share the
>     pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass
>     object classes as well?
> <mircea>Revised text. It was actually trying to say that:
> 
> "   Like pcelsRule, instances of pcelsCompoundConditionAuxClass use
>    pcelsConditionList values and subordinated 
> pcelsConditionAssociation
>    entries to aggregate policy conditions."
> and
> "   Like pcelsRule, instances of pcelsCompoundActionAuxClass use
>    pcelsActionList values and subordinated pcelsActionAssociation
>    entries to aggregate policy actions."
> </mircea>
> 
>   - Page 25, top paragraph, again says that the implementer 
> should ignore
>     an error condition. This isn't a good idea.
>   - Page 25, next paragraph has the same problem.
> <mircea>Already discussed
> </mircea>
> 
>   - Page 26, the pcelsConditionListType attribute has a constraint. No
>     text is provided that instructs the implementer what to do, aside
>     from Note 5 on page 21, which says: "Text has been added 
> to instruct
>     servers and applications what to do if a value outside of 
> this range
>     is encountered" - which is exactly the problem - no text is here.
> Note that this is a systemic problem with any constrained attribute
> defined in this draft. Thus, I will only mention this once.
> <mircea>All Fixed.
> </mircea>
> 
>   - Page 27, WHY isn't a PolicyGroup class implemented? You give no
>     reason for not doing this. Note also that Note 2 talks 
> about ORDERED
>     policy rules - I don't see how you can construct those.
> <mircea>Already discussed
> </mircea>
> 
>   - Page 27, section 5.4, again you say "pcelsRule" instead of "non-
>     abstract subclasses of pcelsRule".
> <mircea>Already discussed
> </mircea>
> 
>   - Page 28, top paragraph, another error that you are recommending 
>     should be ignored
> <mircea>Already discussed
> </mircea>
> 
>   - Page 28, DESC for pcelsConditionAssociation is wrong; you say that
>     it can be used for a pcelsRule instead of a non-abstract 
> subclass of
>     pcelsRule
> <mircea>Already discussed
> </mircea>
> 
>   - Page 28, section 5.5, again you say "pcelsRule" instead of "non-
>     abstract subclasses of pcelsRule".
> <mircea>Already discussed
> </mircea>
> 
>    - Page 28, last paragraph, another error that you are recommending
>     should be ignored.
> <mircea>Already discussed
> </mircea>
> 
>    - Page 29, DESC for pcelsActionAssociation is wrong; you say that 
>     it can be used for a pcelsRule instead of a non-abstract 
> subclass of
>     pcelsRule
> <mircea>Already discussed
> </mircea>
> 
>    - Page 29, last paragraph above Section 5.6, another error 
> that you are
>     recommending should be ignored.
> <mircea>Already discussed
> </mircea>
> 
>    - Page 29, Section 5.6, last two paragraphs are errors that you are
>     recommending should be ignored.
> <At this point, I'm going to stop listing these, as it is a 
> systemic problem that should be fixed in the next release>
> <mircea>Already discussed
> </mircea>
> 
>    - Page 29, last paragraph above Section 5.6, another error 
> that you are
>     recommending should be ignored.
> <mircea>Already discussed
> </mircea>
> 
>    - Page 30, the DESC for pcelsVariableDN is wrong. You say 
> that it is a
>     "DN reference to a pcelsVariable entry", when it should be a DN
>     reference to a subclass of either pcelsExplicitVariableAuxClass or
>     pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass
> <mircea>Already discussed
> </mircea>
> 
>    - Page 30, the DESC for pcelsValueDN is wrong - it should 
> be a subclass
>     of pcelsValueDN.
> <mircea>Already discussed
> </mircea>
> 
>  
> 
> regards,
> John 
> John C. Strassner 
> Chief Strategy Officer 
> Intelliden Inc. 
> 90 South Cascade Avenue 
> Colorado Springs, CO  80906  USA 
> phone:  +1.719.785.0648 
>   fax:     +1.719.785.0644 
> email:    [email-masked]
>