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'; 'policy@ietf.org'
> 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:John.Strassner@intelliden.com]
> Sent: Friday, February 13, 2004 9:32 PM
> To: 'mpana@metasolv.com'; 'policy@ietf.org'
> 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: john.strassner@intelliden.com
>