RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt

[[e-mail]]

John,
 
Is there going to be a follow-up on this message thread? If not, we will
issue one more (minor) revision of PCELS  to address the "MUST contradicts
the first SHOULD" issue as discussed below. Then, we would ask for Joel's
recommendation wrt. advancing the draft to the next stage.
 
Thanks,
Mircea.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
[e-mail]
Sent: Tuesday, April 27, 2004 10:05 PM
To: [e-mail]; [e-mail]
Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04
.txt


John,
 
Thank you for your comments and clarifications. I've added my responses
inline embedded in <mircea2></mircea2>.
 
Regards,
Mircea.
 

-----Original Message-----
From: John Strassner [mailto:[e-mail]]
 [...]
 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 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> 

 

[...]

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

[...]