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

From: [email-masked]
Date: Fri, 26 Mar 2004 07:46:48 -0600

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

> -----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
> 
> 
> First, I support Kurt's comments on LDAP, and will reply to 
> those in a separate email. 
> <mircea>Kurt's recommendations will be addressed in the next revision.
> </mircea>
> 
> Second, I list below a set of additional comments on this draft.
> 
> 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> 
> 
> Fourth, a cursory scan revealed that there is no 
> pcelsPolicyGroup class. This is strange, since PolicyGroup is 
> listed as a subclass of PolicySet in RFC 3460. Why is this?
> <mircea>pcelsGroup will be added in the new revision.
> </mircea> 
> 
> Fifth, why is there a pcelsRule and a pcimRule class?
> <mircea>I do not understand the issue.
> </mircea> 
> 
> 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> 
> 
> I started to go through the document in detail with my 
> developers to try and implement it. We couldn't. We give you 
> inconsistencies that we noticed (grammatical and otherwise) 
> through page 31).
> 
> Finally, I was surprised to see a lack of an Acknowledgments 
> section, especially given the amount of feedback that several 
> people on this list gave the authors. That's in poor form.
> <mircea>Acknowledgments will be added in the new revision.
> </mircea> 
> 
> Comments are as follows:
> 
>   - s/RFC zzzz/RFC 3703
> <mircea>Fixed.
> </mircea>
>  
>   - page 3. You write: "...the combined class hierarchy for the LDAP 
>     object classes defined in [PCLS] and in this document". You should
>     include concepts from 3460 that you mapped into new classes, and
>     add that you defined new classes not in 3460 or 3703.
> <mircea>Fixed.
> </mircea>
> 
>   - page 4-7, class diagram - this diagram has no caption. Please add
>     one. In addition, I find the diagram inpenetrable, in that the
>     reader has no idea where these classes came from. I think you need
>     a simpler introduction saying 3060 provided this, 3460 
> did this, and
>     thus we came up with this. Take this key and show, for any class 
>     that isn't new in this document, where it came from.
> <mircea>Fixed.
> </mircea>
> 
>   - page 4 - why is your class named pcelsFilerEntry, when 3460 names
>     its class FilterEntryBase?
>   - page 4 - why is your class named pcelsIPHeaders, when 3460 names
>     its class IPHeadersFilter? The Filter part is important! 
>   - page 4 - why is your class named pcels8021Headers, when 3460 names
>     its class 8021Filter? The Filter part is important!
>   - page 4 - why is your class named 
> pcelsCompoundFilterAuxClass, when 
>     a more consistent name would be 
> pcelsCompoundFilterConditionAuxClass?
>     The Condition part is important!
> <mircea>All renamed.
> </mircea>
> 
>    - general reflections on the class diagram: part of the 
> problem is that
>     you are building a schema from three different sources: 
> (1) RFC 3703,
>     (2) RFC 3460, and (3) your own additions. I see no 
> discussion on how
>     these relate to each other, which would have been helpful.
> <mircea>The new revision will indicate all these sources explicitly.
> </mircea>
> 
>    - page 7 - you didn't state whether this is for all 
> associations. This
>     is exacerbated by you saying: "...might need to implement the 
>     association..." - which implies a single association. In addition,
>     this is a terse description - the naive reader won't 
> understand why
>     aux classes are being used - you need a reference or a couple of
>     sentences explaining this.
> <mircea>Added example in support of the generic text. Please 
> note that the reader is not going to be that naive. Section 
> 2. ("Relationship to other Policy Framework Documents") will 
> also indicate that "These three documents ([PCIM], [PCIM_EXT] 
> and [PCLS]) are a prerequisite for reading and understanding 
> this document."
> </mircea>
> 
>   - 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>
> 
>   - pages 8-11: your table has no caption
> <mircea>Fixed.
> </mircea>
> 
>   - 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>
> 
>   - once again, I see lots of irksome naming issues. The LDAP schema
>     shouldn't change the name of a class defined in another RFC. Why
>     have you done this?
> <mircea>All are going to be renamed to follow the *exact* 
> PCIM_EXT names, but I fail to see where is the problem with 
> the old names.
> </mircea>
> 
>   - page 8, 4th row. How can you give two different mappings 
> to a single
>     object class? And how can a RULE (i.e., pcelsRule) map to a GROUP?
> <mircea>pcelsGroup will be added in the new revision.
> </mircea> 
> 
>   - page 10, 1st row. How can a single info model association map to
>     two different associations? And do you mean "and" in this 
> row? This
>     would mean that I would have to instantiate both pcelsPolicySet
>     and pcelsPolicySetAssociation, which is clearly wrong. 
> This comment
>     also applies for the other rows on this page where you have "and".
> <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>
> 
>   - page 10 - it is of no help to say "see PolicySetInSystem" in this
>     table for the 3rd and 4th rows - that only confuses the reader.
>     Please spell out what you mean here.
> <mircea>Fixed. Details are in section 5.
> </mircea>
> 
>   - 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>
> 
>   - 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>
> 
>   - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate
> <mircea>Fixed.
> </mircea>
> 
>   - Page 13, Note - actually, PCLS does NOT have anything to do with
>     PCIMe, so this note needs to be reworded
> <mircea>Fixed.
> </mircea>
> 
>   - Page 14, Section 4.5
>     - s/an other/another (and other places)
>     - s/"rule /group"/"rule/group" (5 places) (and other places)
> <mircea>Fixed.
> </mircea>
> 
> 
(to continue...)