Part1: RE: FW: I-D ACTION:draft-reyes-policy-core-ext-sc hema-04 .txt
[email protected] Fri, 26 Mar 2004 07:46:48 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41338.C92AD3E0 Content-Type: text/plain; charset="ISO-8859-1" 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 protected]' > 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 protected]] > Sent: Friday, February 13, 2004 9:32 PM > To: '[email protected]'; '[email protected]' > 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...) ------_=_NextPart_001_01C41338.C92AD3E0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3DISO-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>Part1: RE: [Policy] FW: I-D = ACTION:draft-reyes-policy-core-ext-schema-04 .txt</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>my message has exceeded the 40 k limit.</FONT> <BR><FONT SIZE=3D2>see below part1</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Pana, Mircea </FONT> <BR><FONT SIZE=3D2>> Sent: Thursday, March 25, 2004 9:59 PM</FONT> <BR><FONT SIZE=3D2>> To: 'John Strassner'; '[email protected]'</FONT> <BR><FONT SIZE=3D2>> Subject: RE: [Policy] FW: I-D</FONT> <BR><FONT SIZE=3D2>> ACTION:draft-reyes-policy-core-ext-schema-04 = .txt</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> John,</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> I have reviewed your comments in detail and = made several </FONT> <BR><FONT SIZE=3D2>> changes to the PCELS text (to be submitted in a = few days) to </FONT> <BR><FONT SIZE=3D2>> address these issues. While for the most part I = understand </FONT> <BR><FONT SIZE=3D2>> your concerns, there are a few items that I = would like to </FONT> <BR><FONT SIZE=3D2>> discuss in more detail. See my comments below = marked </FONT> <BR><FONT SIZE=3D2>> <mircea></mircea>.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Thank You,</FONT> <BR><FONT SIZE=3D2>> Mircea.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: John Strassner [<A = HREF=3D"mailto:[email protected]">mailto:John.Strassner@inte= lliden.com</A>]</FONT> <BR><FONT SIZE=3D2>> Sent: Friday, February 13, 2004 9:32 PM</FONT> <BR><FONT SIZE=3D2>> To: '[email protected]'; = '[email protected]'</FONT> <BR><FONT SIZE=3D2>> Subject: RE: [Policy] FW: I-D </FONT> <BR><FONT SIZE=3D2>> ACTION:draft-reyes-policy-core-ext-schema-04 = .txt</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> First, I support Kurt's comments on LDAP, and = will reply to </FONT> <BR><FONT SIZE=3D2>> those in a separate email. </FONT> <BR><FONT SIZE=3D2>> <mircea>Kurt's recommendations will be = addressed in the next revision.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Second, I list below a set of additional = comments on this draft.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Third, the lack of an overall diagram makes it = very difficult </FONT> <BR><FONT SIZE=3D2>> to evaluate the correctness of this model. This = draft is not </FONT> <BR><FONT SIZE=3D2>> complete enough to construct such a = model.</FONT> <BR><FONT SIZE=3D2>> <mircea>Can you be more specific. The = document includes </FONT> <BR><FONT SIZE=3D2>> several diagrams and tables. What is it = missing?</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Fourth, a cursory scan revealed that there is = no </FONT> <BR><FONT SIZE=3D2>> pcelsPolicyGroup class. This is strange, since = PolicyGroup is </FONT> <BR><FONT SIZE=3D2>> listed as a subclass of PolicySet in RFC 3460. = Why is this?</FONT> <BR><FONT SIZE=3D2>> <mircea>pcelsGroup will be added in the = new revision.</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Fifth, why is there a pcelsRule and a pcimRule = class?</FONT> <BR><FONT SIZE=3D2>> <mircea>I do not understand the = issue.</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Sixth, why is there no = pcelsRuleValidityAssociation subclass? </FONT> <BR><FONT SIZE=3D2>> At this point, <mircea>I do not = understand the issue. PCELS </FONT> <BR><FONT SIZE=3D2>> reuses pcimRuleValidityAssociation that is = defined in PCLS</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> I started to go through the document in detail = with my </FONT> <BR><FONT SIZE=3D2>> developers to try and implement it. We = couldn't. We give you </FONT> <BR><FONT SIZE=3D2>> inconsistencies that we noticed (grammatical = and otherwise) </FONT> <BR><FONT SIZE=3D2>> through page 31).</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Finally, I was surprised to see a lack of an = Acknowledgments </FONT> <BR><FONT SIZE=3D2>> section, especially given the amount of = feedback that several </FONT> <BR><FONT SIZE=3D2>> people on this list gave the authors. That's in = poor form.</FONT> <BR><FONT SIZE=3D2>> <mircea>Acknowledgments will be added in = the new revision.</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Comments are as follows:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - s/RFC zzzz/RFC 3703</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 3. You write: "...the = combined class hierarchy for the LDAP </FONT> <BR><FONT SIZE=3D2>> object classes defined = in [PCLS] and in this document". You should</FONT> <BR><FONT SIZE=3D2>> include concepts from = 3460 that you mapped into new classes, and</FONT> <BR><FONT SIZE=3D2>> add that you defined = new classes not in 3460 or 3703.</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 4-7, class diagram - this = diagram has no caption. Please add</FONT> <BR><FONT SIZE=3D2>> one. In addition, I = find the diagram inpenetrable, in that the</FONT> <BR><FONT SIZE=3D2>> reader has no idea = where these classes came from. I think you need</FONT> <BR><FONT SIZE=3D2>> a simpler introduction = saying 3060 provided this, 3460 </FONT> <BR><FONT SIZE=3D2>> did this, and</FONT> <BR><FONT SIZE=3D2>> thus we came up with = this. Take this key and show, for any class </FONT> <BR><FONT SIZE=3D2>> that isn't new in this = document, where it came from.</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 4 - why is your class named = pcelsFilerEntry, when 3460 names</FONT> <BR><FONT SIZE=3D2>> its class = FilterEntryBase?</FONT> <BR><FONT SIZE=3D2>> - page 4 - why is your class named = pcelsIPHeaders, when 3460 names</FONT> <BR><FONT SIZE=3D2>> its class = IPHeadersFilter? The Filter part is important! </FONT> <BR><FONT SIZE=3D2>> - page 4 - why is your class named = pcels8021Headers, when 3460 names</FONT> <BR><FONT SIZE=3D2>> its class 8021Filter? = The Filter part is important!</FONT> <BR><FONT SIZE=3D2>> - page 4 - why is your class named = </FONT> <BR><FONT SIZE=3D2>> pcelsCompoundFilterAuxClass, when </FONT> <BR><FONT SIZE=3D2>> a more consistent name = would be </FONT> <BR><FONT SIZE=3D2>> pcelsCompoundFilterConditionAuxClass?</FONT> <BR><FONT SIZE=3D2>> The Condition part is = important!</FONT> <BR><FONT SIZE=3D2>> <mircea>All renamed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - general reflections on the = class diagram: part of the </FONT> <BR><FONT SIZE=3D2>> problem is that</FONT> <BR><FONT SIZE=3D2>> you are building a = schema from three different sources: </FONT> <BR><FONT SIZE=3D2>> (1) RFC 3703,</FONT> <BR><FONT SIZE=3D2>> (2) RFC 3460, and (3) = your own additions. I see no </FONT> <BR><FONT SIZE=3D2>> discussion on how</FONT> <BR><FONT SIZE=3D2>> these relate to each = other, which would have been helpful.</FONT> <BR><FONT SIZE=3D2>> <mircea>The new revision will indicate = all these sources explicitly.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 7 - you didn't state = whether this is for all </FONT> <BR><FONT SIZE=3D2>> associations. This</FONT> <BR><FONT SIZE=3D2>> is exacerbated by you = saying: "...might need to implement the </FONT> <BR><FONT SIZE=3D2>> association..." - = which implies a single association. In addition,</FONT> <BR><FONT SIZE=3D2>> this is a terse = description - the naive reader won't </FONT> <BR><FONT SIZE=3D2>> understand why</FONT> <BR><FONT SIZE=3D2>> aux classes are being = used - you need a reference or a couple of</FONT> <BR><FONT SIZE=3D2>> sentences explaining = this.</FONT> <BR><FONT SIZE=3D2>> <mircea>Added example in support of the = generic text. Please </FONT> <BR><FONT SIZE=3D2>> note that the reader is not going to be that = naive. Section </FONT> <BR><FONT SIZE=3D2>> 2. ("Relationship to other Policy = Framework Documents") will </FONT> <BR><FONT SIZE=3D2>> also indicate that "These three documents = ([PCIM], [PCIM_EXT] </FONT> <BR><FONT SIZE=3D2>> and [PCLS]) are a prerequisite for reading and = understanding </FONT> <BR><FONT SIZE=3D2>> this document."</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 7 - you state: "The = LDAP object classes defined in </FONT> <BR><FONT SIZE=3D2>> this document</FONT> <BR><FONT SIZE=3D2>> are a direct mapping = from the corresponding classes and, in some </FONT> <BR><FONT SIZE=3D2>> cases, the associations = defined in [PCIM_EXT] ". Not </FONT> <BR><FONT SIZE=3D2>> strictly true, </FONT> <BR><FONT SIZE=3D2>> as you are also seeking = to update RFC 3703 (e.g., where is </FONT> <BR><FONT SIZE=3D2>> pcimSubtreesPtrAuxClass = defined in RFC 3460?).</FONT> <BR><FONT SIZE=3D2>> <mircea>The text in section 4.1 will be = revised for a better </FONT> <BR><FONT SIZE=3D2>> description of the mapping techniques utilised = by PCELS. </FONT> <BR><FONT SIZE=3D2>> However, I do not understand </FONT> <BR><FONT SIZE=3D2>> your reference to pcimSubtreesPtrAuxClass. That = class is not </FONT> <BR><FONT SIZE=3D2>> defined in PCELS.</FONT> <BR><FONT SIZE=3D2>> <mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - pages 8-11: your table has no = caption</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - pages 8-11: Where are classes = like pcimSubtreesPtrAuxClass? They</FONT> <BR><FONT SIZE=3D2>> aren't listed in this = table, and better be, if you are "updating"</FONT> <BR><FONT SIZE=3D2>> RFC 3703.</FONT> <BR><FONT SIZE=3D2>> <mircea>The two tables list PCIM_EXT = classes mapped by PCELS. </FONT> <BR><FONT SIZE=3D2>> Why should the tables include PCLS = classes?</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - once again, I see lots of irksome = naming issues. The LDAP schema</FONT> <BR><FONT SIZE=3D2>> shouldn't change the = name of a class defined in another RFC. Why</FONT> <BR><FONT SIZE=3D2>> have you done = this?</FONT> <BR><FONT SIZE=3D2>> <mircea>All are going to be renamed to = follow the *exact* </FONT> <BR><FONT SIZE=3D2>> PCIM_EXT names, but I fail to see where is the = problem with </FONT> <BR><FONT SIZE=3D2>> the old names.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 8, 4th row. How can you give = two different mappings </FONT> <BR><FONT SIZE=3D2>> to a single</FONT> <BR><FONT SIZE=3D2>> object class? And how = can a RULE (i.e., pcelsRule) map to a GROUP?</FONT> <BR><FONT SIZE=3D2>> <mircea>pcelsGroup will be added in the = new revision.</FONT> <BR><FONT SIZE=3D2>> </mircea> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 10, 1st row. How can a = single info model association map to</FONT> <BR><FONT SIZE=3D2>> two different = associations? And do you mean "and" in this </FONT> <BR><FONT SIZE=3D2>> row? This</FONT> <BR><FONT SIZE=3D2>> would mean that I would = have to instantiate both pcelsPolicySet</FONT> <BR><FONT SIZE=3D2>> and = pcelsPolicySetAssociation, which is clearly wrong. </FONT> <BR><FONT SIZE=3D2>> This comment</FONT> <BR><FONT SIZE=3D2>> also applies for the = other rows on this page where you have "and".</FONT> <BR><FONT SIZE=3D2>> <mircea> ...means that the = PolicySetComponent aggregation is </FONT> <BR><FONT SIZE=3D2>> realised by a pcelsPolicySetComponentList value = in the </FONT> <BR><FONT SIZE=3D2>> aggregating pcelsPolicySet. This attribute = value is a DN </FONT> <BR><FONT SIZE=3D2>> reference to a pcelsPolicySetAsociation entry. = The </FONT> <BR><FONT SIZE=3D2>> pcelsPolicySetAsociation entry includes a = pcelsPolicySetDN </FONT> <BR><FONT SIZE=3D2>> attribute value that is a reference to the = aggregated </FONT> <BR><FONT SIZE=3D2>> pcelsPolicySet. The details are in section 5. = The table only </FONT> <BR><FONT SIZE=3D2>> gives an overview of the mapping.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - page 10 - it is of no help to say = "see PolicySetInSystem" in this</FONT> <BR><FONT SIZE=3D2>> table for the 3rd and = 4th rows - that only confuses the reader.</FONT> <BR><FONT SIZE=3D2>> Please spell out what = you mean here.</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed. Details are in section = 5.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 11 - the reader will wonder = why ReusablePolicy and </FONT> <BR><FONT SIZE=3D2>> = PolicyRoleCollectionInSystem are only implementable via DIT </FONT> <BR><FONT SIZE=3D2>> containment, when every = other association has an </FONT> <BR><FONT SIZE=3D2>> association defined</FONT> <BR><FONT SIZE=3D2>> (independent of whether = DIT containment could be used).</FONT> <BR><FONT SIZE=3D2>> <mircea>I fail to see the issue.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Section 4.2, line 3, you write: = "The concept of an ordered set of</FONT> <BR><FONT SIZE=3D2>> policies...". LDAP = doesn't have ordered sets. How are you going to</FONT> <BR><FONT SIZE=3D2>> implement this?</FONT> <BR><FONT SIZE=3D2>> <mircea>replaced "ordered" with = "coherent" (from PCIM_EXT)</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 13, Section 4.3, second = paragraph - s/deprecates/deprecate</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 13, Note - actually, PCLS = does NOT have anything to do with</FONT> <BR><FONT SIZE=3D2>> PCIMe, so this note = needs to be reworded</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 14, Section 4.5</FONT> <BR><FONT SIZE=3D2>> - s/an other/another = (and other places)</FONT> <BR><FONT SIZE=3D2>> - s/"rule = /group"/"rule/group" (5 places) (and other = places)</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>(to continue...)</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C41338.C92AD3E0--