-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
[...]Third, the lack of an overall diagram makes it very difficult to evaluate the correctness of this model. This draft is not complete enough to construct such a model.<mircea>Can you be more specific. The document includes several diagrams and tables. What is it missing?
</mircea><js> True, there are several diagrams and tables. However, the draft lacks an overall conceptual model. For example, if you look at RFC3060, Figure 1 shows an overview of all of the classes and their relationships. Note that there is no need to show attributes in such a picture - I'm just looking for a **visual** overview of how the different classes fit together. </js>
<mircea2>A more appropriate place for an overall conceptual model diagram would have been RFC3460. Such diagram is somewhat out of scope for PCELS. Wrt. the LDAP mapping of PCIMe concepts, the case studies in section 4.x include several instance diagrams that illustrate the implementation options. There are many variations and they could hardly fit in a single diagram.
This being said, I am certainly not against the inclusion of an overall class diagram. So, should someone out there volunteer to make such a contribution to the document, I would gladly include it in a new revision of PCELS.</mircea2>
[...]
Fifth, why is there a pcelsRule and a pcimRule class?
<mircea>I do not understand the issue.
</mircea><js> Sorry for not being clearer. I understand that you wanted to create your own class (pcelsRule) because the semantics of RFC3460 were different (for PolicyRules) than those of RFC3460. I support your mentioning both in the draft, since there was feedback (e.g., from Ryan) that some implementations were still using pcimRule. However, I think that given this feedback, this draft needs some guidelines as to when one would use pcelsRule and one would use pcimRule, and what the implications of doing this are (e.g., how priority is implemented). </js>
<mircea2>PCELS recommends the use of pcelsRule. While the use of pcimRule is not prevented by PCELS, I do not see why this document would state any reasons in favour of this class. It is outside the scope of PCELS to make recommendations in this matter. Should RFC3460 be revised, this is where such issue should be addressed.</mircea2>
Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, <mircea>I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS
</mircea>
<js> True, this is addressed in Note 1 in page 27 of the draft. Looking at your class structure, since you subclassed other associations, I was surprised that you didn't subclass this one as well. This is because pcelsRule and pcimRule are siblings, and pcimRuleValidityPeriod (in PCIM) is defined to exist between pcimRule and policyConditionTimePeriod only. So, how do pcelsRule instances use a policyConditionTimePeriod? </js>
<mircea2>PCELS adopts pcimRuleValidityAssociation extending its applicability to pcelsRule. I.e. PCELS recommends the use of pcimRuleValidityAssociation instances subordinated to pcelsRule entries for associating pcimTPCAuxClass instances to a Rule. Note that PCELS also recommends that: "As result, the class pcimRuleValidityAssociation SHOULD be expected (and allowed) to have instances of pcelsRule as superior entries."
This isn't a change of semantics for the pcimRuleValidityAssociation class. In a PCELS implementation, this class continues to represent the PolicyRuleValidityPeriod aggregation. Other association classes defined in PCIM are subclassed in PCELS for the purpose of extending their semantics (and for changing their names ;-)</mircea2>
[...]
- page 7 - you state: "The LDAP object classes defined in this document
are a direct mapping from the corresponding classes and, in some
cases, the associations defined in [PCIM_EXT] ". Not strictly true,
as you are also seeking to update RFC 3703 (e.g., where is
pcimSubtreesPtrAuxClass defined in RFC 3460?).
<mircea>The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understandyour reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS.
<mircea><js> If you look at RFC3703, we defined two aux classes (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify navigation through the DIT, as well as retrieval of entries found more efficient. I think that you should take another look at the rationale behind these classes, and consider again whether they should be included in this draft. </js>
<mircea2>The fact that PCELS does not explicitly discuss these classes does not mean that implementations should not use them. Actually, PCELS application will likely implement them as well as pcimPolicyInstance, pcimConditionVendorAuxClass and many other PCLS classes. Are you suggesting that all these classes should be explicitly listed? IMO sections 2 and 3 of PCELS already address this issue.</mircea2>
[...]
- pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They
aren't listed in this table, and better be, if you are "updating"
RFC 3703.
<mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes?
</mircea><js> Because this draft is supposed to be updating RFC3703, which means that you need to deal with classes defined in that RFC (such as pcimSubtreesPtrAuxClass) as well as your own classes. Or, at the very least, state why these classes do not need to be defined. </js>
<mircea2>Do we understand different things by "updates"? By "updates" we mean that PCELS makes incremental changes and additions to PCLS. So, I fail to see why PCELS should re-define classes that do not change.</mircea2>
[...]
<mircea> ...means that the PolicySetComponent aggregation is realised by a pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. This attribute value is a DN reference to a pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute value that is a reference to the aggregated pcelsPolicySet. The details are in section 5. The table only gives an overview of the mapping.
</mircea>
<js> OK, that makes sense, but I suggest you add a note saying "See section 5.x" so the impatient reader won't get frustrated. ;-) </js>
<mircea2>"4.1 Summary of Class and Association Mappings
[...] The details of this mapping are discussed case by case in section 5."</mircea2>
[...]
- Page 11 - the reader will wonder why ReusablePolicy and
PolicyRoleCollectionInSystem are only implementable via DIT
containment, when every other association has an association defined
(independent of whether DIT containment could be used).
<mircea>I fail to see the issue.
</mircea><js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js>
<mircea2>For ReusablePolicy, DIT containment has the best scalability (btw, PCLS does the same thing).
PolicyRoleCollectionInSystem, is still open for suggestions ;-) </mircea2>
- Section 4.2, line 3, you write: "The concept of an ordered set of
policies...". LDAP doesn't have ordered sets. How are you going to
implement this?
<mircea>replaced "ordered" with "coherent" (from PCIM_EXT)
</mircea><js> That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. </js>
<mircea2> See note at the end of section 5.1 (page 26).</mircea2>
[...]
- 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>
<js> The last MUST contradicts the first SHOULD in the above statement; please change it to SHOULD. The first MUSt in the above statement is OK. </js>
<mircea2> How about replacing the last statement with: "Note that pcelsRule and its subclasses are compatible with [PCIM_EXT] while pcimRule and its subclasses are not.</mircea2>
- 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>
<js> I still disagree (and with PCLS page 50 as well) - it is imprecise. </js>
<mircea2> Note 6 in section 5 warns the reader about the imprecise language. (page 23)</mircea2>
- 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><js> The point is that there is a pronounced difference between an aggregation and an association. Although it is sadly commonplace to call everything an association. ;-( I would suggest changing your text to either only use "association" or only use "aggregation" in the same paragraph. </js>
<mircea2>...So, would it be acceptable to call PolicySetComponent an association, when PCIMe defines it as aggregation?</mircea2>
[...]