[Policy] response to comments on PCELS-05/May 06

[[e-mail]]

John, See my comments tagged <mircea3></mircea3>.
 
Thank You,
Mircea

-----Original Message-----
From: John Strassner [mailto:[e-mail]]
Sent: Thursday, May 06, 2004 3:44 AM
To: [e-mail]; John Strassner
Cc: [e-mail]; [e-mail]
Subject: RE: your comments on PCELS-05 / April 26


I've just pulled up the remaining problems to make it easier to deal with.
I'm copying Joel and Bert so that they know that I am responding, albeit
slowly...look for <js2/>
 
 
[...]
 
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>

<js2> The above logic is incorrect. Look at how pcimRuleValidityPeriod is
defined in RFC3060. It is NOT a representation of a
PolicyRuleValidityPeriod, it is a representation of the *association*
between a PolicyRuleValidityPeriod and a PolicyRule. So, the problem is that
you have defined a pcelsPolicySet to be a sibling of pcimRule (to which
pcimRuleValidityPeriod applies). Therefore, pcimRuleValidityPeriod does NOT
apply to pcelsPolicySet (and thus not to pcelsRule). Therefore, you have to
either redefine this association, or create a new one. You did neither.
</js2> 

<mircea3>I must be missing something... You say that pcimRuleValidityPeriod
is defined in RFC3060 but in PCIM I can not find any reference to
pcimRuleValidityPeriod. PCLS (RFC3703) does not define such class either.
You also mention the association between a PolicyRuleValidityPeriod and a
PolicyRule but I can not find anything in either PCIM or PCLS that
implements such association.

However, in PCIM I read that PolicyRuleValidityPeriod is defined as "A class
representing the aggregation of PolicyTimePeriodConditions by a PolicyRule".
In PCLS I read that "The policyRuleValidityPeriod aggregation is mapped to
the PCLS pcimRuleValidityAssociation class." So, I conclude that
pcimRuleValidityAssociation is used to associate TimePeriodConditions to a
Rule. For PCLS this means associating instances of pcimTPCAuxClass to a
pcimRule. For PCELS this would mean associating instances of pcimTPCAuxClass
to a pcelsRule. I really don't see the problem. </mircea3> 

 

 [...]

   - 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 understand 

your 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> 

<js2> It wasn't apparent to me or my developers that you were including
these classes. A few sentences here couldn't hurt! </js2> 

<mircea3>We will add a subsection 4.x or an appendix that lists the PCLS
classes that should be used by PCELS implementations.</mircea3> 

 

[...]

  - 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> 

<js2> Perhaps this is a semantic difference. I think that an "update" should
address all issues, and explicitly state whether something is good as is, or
needs to be updated and why. Bert and Joel, your views? </js2> 

<mircea3>We will add a subsection 4.x that lists the PCLS classes that
should be used by PCELS implementations.</mircea3> 

 

[...]

   - 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> 

<js2> But, my issue of consistency still holds. You are preventing the
developer from having a choice here. I would suggest defining both and then
stating, editorially, that DIT containment is preferred here. </js2> 

<mircea3>I have reviewed the PCIMe definitions for these two associations
and I think that mapping them to LDAP classes/attributes is unnecessary (or
even wrong). A PolicyRoleCollection if it exists, it only exists in the
context of a System, therefore the obvious LDAP implementation for
PolicyRoleCollectionInSystem is DIT containment. ReusablePolicy places a
policy element in a *container*. Once again, the obvious choice is DIT
containment. In addition, one could also argue that mapping ReusablePolicy
only to DIT containment is consistent with PCLS (see
Policy*InPolicyRepository association mappings in PCLS).</mircea3> 

 

  - 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>    

<js2> I'm still not satisfied. Joel and Bert? </js2> 

<mircea3>We will make the change suggested by Joel: "[...] (pcelsPolicySet)
provides a set of policies with additional information that allow the
application to apply appropriate ordering to the information."</mircea3> 

 

 [...]

   - 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>

<js2> How about deleting it entirely? This statement doesn't really help,
it's stating the obvious. </js2> 

<mircea3>OK.</mircea3> 

 

[...]



  - 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> 

<js2> No, of course not, in a perfect world. I'm suggesting 1 of 2 courses:
  - easiest: replace "aggregation" with "association" everywhere - this has
the advantage of being imprecise, or
  - go through the document and call things aggregations when they are
aggregations.

The problem is that you call the same object both an association and an
aggregation, which is confusing to some people. </js2> 

<mircea3>OK. We'll call them all "associations".</mircea3> 

[...]

regards,
John Strassner