RE: FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
"John Strassner" <[email protected]> Sun, 25 Apr 2004 23:59:47 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C42B53.AE30CC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mircea, =20 thanks for addressing these issues, and apologies for the delay in response. Please see inline (<js>..</js>) for clarifications. =20 regards, John -----Original Message----- From: [email protected] [mailto:[email protected]]=20 Sent: Thursday, March 25, 2004 7:59 PM To: John Strassner; [email protected] Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt John,=20 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,=20 Mircea.=20 -----Original Message-----=20 From: John Strassner [mailto:[email protected]]=20 Sent: Friday, February 13, 2004 9:32 PM=20 To: '[email protected]'; '[email protected]'=20 Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt=20 First, I support Kurt's comments on LDAP, and will reply to those in a separate email.=20 <mircea>Kurt's recommendations will be addressed in the next revision.=20 </mircea>=20 Second, I list below a set of additional comments on this draft.=20 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?=20 </mircea> =20 <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> 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.=20 </mircea>=20 Fifth, why is there a pcelsRule and a pcimRule class?=20 <mircea>I do not understand the issue.=20 </mircea> =20 <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> 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> =20 <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> 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.=20 </mircea>=20 Comments are as follows:=20 - s/RFC zzzz/RFC 3703=20 <mircea>Fixed.=20 </mircea>=20 =20 - page 3. You write: "...the combined class hierarchy for the LDAP=20 object classes defined in [PCLS] and in this document". You should=20 include concepts from 3460 that you mapped into new classes, and=20 add that you defined new classes not in 3460 or 3703.=20 <mircea>Fixed.=20 </mircea>=20 - page 4-7, class diagram - this diagram has no caption. Please add=20 one. In addition, I find the diagram inpenetrable, in that the=20 reader has no idea where these classes came from. I think you need=20 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=20 that isn't new in this document, where it came from.=20 <mircea>Fixed.=20 </mircea>=20 - page 4 - why is your class named pcelsFilerEntry, when 3460 names=20 its class FilterEntryBase?=20 - page 4 - why is your class named pcelsIPHeaders, when 3460 names=20 its class IPHeadersFilter? The Filter part is important!=20 - page 4 - why is your class named pcels8021Headers, when 3460 names=20 its class 8021Filter? The Filter part is important!=20 - page 4 - why is your class named pcelsCompoundFilterAuxClass, when=20 a more consistent name would be pcelsCompoundFilterConditionAuxClass?=20 The Condition part is important!=20 <mircea>All renamed.=20 </mircea>=20 - general reflections on the class diagram: part of the problem is that=20 you are building a schema from three different sources: (1) RFC 3703,=20 (2) RFC 3460, and (3) your own additions. I see no discussion on how these relate to each other, which would have been helpful.=20 <mircea>The new revision will indicate all these sources explicitly.=20 </mircea>=20 - page 7 - you didn't state whether this is for all associations. This=20 is exacerbated by you saying: "...might need to implement the=20 association..." - which implies a single association. In addition,=20 this is a terse description - the naive reader won't understand why=20 aux classes are being used - you need a reference or a couple of=20 sentences explaining this.=20 <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>=20 - page 7 - you state: "The LDAP object classes defined in this document=20 are a direct mapping from the corresponding classes and, in some=20 cases, the associations defined in [PCIM_EXT] ". Not strictly true,=20 as you are also seeking to update RFC 3703 (e.g., where is=20 pcimSubtreesPtrAuxClass defined in RFC 3460?).=20 <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=20 your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS.=20 <mircea> =20 <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> - pages 8-11: your table has no caption=20 <mircea>Fixed.=20 </mircea>=20 - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They=20 aren't listed in this table, and better be, if you are "updating"=20 RFC 3703.=20 <mircea>The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes?=20 </mircea>=20 <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> =20 - once again, I see lots of irksome naming issues. The LDAP schema=20 shouldn't change the name of a class defined in another RFC. Why=20 have you done this?=20 <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> =20 <js> It's all about implementation ease. If an earlier RFC exists, the naming in that RFC should be respected and not changed. </js>=20 - 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?=20 <mircea>pcelsGroup will be added in the new revision.=20 </mircea>=20 - page 10, 1st row. How can a single info model association map to=20 two different associations? And do you mean "and" in this row? This=20 would mean that I would have to instantiate both pcelsPolicySet=20 and pcelsPolicySetAssociation, which is clearly wrong. This comment=20 also applies for the other rows on this page where you have "and".=20 <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> =20 <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>=20 - page 10 - it is of no help to say "see PolicySetInSystem" in this=20 table for the 3rd and 4th rows - that only confuses the reader.=20 Please spell out what you mean here.=20 <mircea>Fixed. Details are in section 5.=20 </mircea>=20 - Page 11 - the reader will wonder why ReusablePolicy and=20 PolicyRoleCollectionInSystem are only implementable via DIT=20 containment, when every other association has an association defined (independent of whether DIT containment could be used).=20 <mircea>I fail to see the issue.=20 </mircea> =20 <js> Good schemata are consistent. Why are these two associations only implementable via DIT containment? </js>=20 - Section 4.2, line 3, you write: "The concept of an ordered set of=20 policies...". LDAP doesn't have ordered sets. How are you going to=20 implement this?=20 <mircea>replaced "ordered" with "coherent" (from PCIM_EXT)=20 </mircea> =20 <js> That's certainly better than incoherent ;-) but I don't see how this solves the problem, as the two aren't synonymous. </js>=20 - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate=20 <mircea>Fixed.=20 </mircea>=20 - Page 13, Note - actually, PCLS does NOT have anything to do with=20 PCIMe, so this note needs to be reworded=20 <mircea>Fixed.=20 </mircea>=20 - Page 14, Section 4.5=20 - s/an other/another (and other places)=20 - s/"rule /group"/"rule/group" (5 places) (and other places)=20 <mircea>Fixed.=20 </mircea>=20 - Page 16, section 4.6,=20 - s/CompoundPolicyActionclasses/CompoundPolicyAction classes=20 - conditions /actions/"conditions/actions" (and other places)=20 <mircea>Fixed.=20 </mircea>=20 - Page 22. How are you going to enforce an "ordered set of=20 rules /groups"? That is, how can you guarantee that the DSA stores=20 your rules/groups [sic] in the order that you want, and where is=20 that order specified? What if a DSA doesn't have ordering controls?=20 - Same section as above - you say that the "association entries enable relative ordering of the aggregated pcelsPolicySet instances within=20 the scope of the aggregating pcelsPolicySet" - how is this=20 accomplished with a plain, vanilla LDAP server with no controls?=20 <mircea>Text revised and note added to indicate that applications must not expect the LDAP data store to implement sorting and ordering. </mircea>=20 - Page 23 - the DESC for pcelsPolicySetList should say that it=20 contains an UNORDERED list of DN references.=20 <mircea>Fixed.=20 </mircea>=20 - Page 23, note above Section 5.2, is slightly incorrect. Only those=20 implementations that WANT TO BE COMPATIBLE WITH PCELS should use=20 this aggregation mechanism instead of those defined by PCLS. Not=20 every implementation mechanism is going to want to change.=20 <mircea>Revised. The section defining pcelsRule for example will include the following compatibility note:=20 "Note 2: PCELS implementations SHOULD support pcelsRule and its two=20 subclasses and MAY also support pcimRule and its two subclasses=20 [PCLS]. Applications that choose to support pcelsRule and its two=20 subclasses MUST use the aggregation mechanism provided by=20 pcelsPolicySetAssociation for aggregating policy groups or policy=20 rules in policy rules represented as instances of pcelsRule.=20 Applications that intend to be compatible with [PCIM_EXT] MUST=20 support pcelsRule and its two subclasses."=20 </mircea> =20 <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>=20 - Page 23, Section 5.2, says "The pcelsPolicySetAssociation class is=20 used to aggregate instances of pcelsPolicySet into other entries."=20 This is incorrect, as pcelsPolicySet is abstract and thus cannot be=20 instantiated.=20 <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> =20 <js> I still disagree (and with PCLS page 50 as well) - it is imprecise. </js>=20 - Same section, you write: "...realizes a (subclass of)=20 PolicySetComponent aggregation [sic]. When subordinated to (subclass of) dlm1System...realizes a PolicySetInSystem association [sic]".=20 How can the same element realize an aggregation in one usage and an=20 association in another usage? This is semantically inconsistent.=20 <mircea>I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive.=20 </mircea> =20 <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>=20 - Next paragraph says: "A non-reusable instance of (subclass of)=20 pcelsPolicySet is attached as auxiliary class directly to the=20 pcelsPolicySetAssociation entry." Subclasses of pcelsPolicySet that=20 are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The=20 above sentence only makes sense for pcelsRuleAuxClass.=20 <mircea>The new specification will include pcelsGroup as well. As result, the current text will make more sense.=20 </mircea>=20 - Next paragraph doesn't make sense. First, you clearly mean a non-=20 abstract subclass of pcelsPolicySet. Second, you are recommending=20 that an ERROR be ignored? Why don't you stop operation?=20 <mircea>Revised text:=20 "When reading a pcelsPolicySetAssociation instance that has a=20 pcelsPolicySet attached, the attribute pcelsPolicySetDN MUST=20 be ignored. Applications SHOULD remove the pcelsPolicySetDN value=20 from a pcelsPolicySetAssociation upon attachment of a pcelsPolicySet=20 to the entry."=20 This gives applications some flexibility.=20 </mircea> =20 <js> That's much better </js>=20 - Page 24, DESC of pcelsPriority is insufficient, as "0" has special=20 semantics that you haven't mentioned. This should, of course, also=20 be present in accompanying prose, as Kurt points out.=20 <mircea>The PCIM_EXT property and the attribute value restrictions going to be described in more detail (in prose). However I fail to find the meaning of "0" in PCIM_EXT. Can you help me locate the text? </mircea> =20 <js> My mistake, the RFC states that this is simply the default value. </js>=20 - Page 24, DESC of pcelsPolicySetDN should state that this is an=20 UNORDERED list of DNs.=20 <mircea>Fixed.=20 </mircea>=20 - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule=20 Class and Its Subclasses=20 <mircea>Fixed.=20 </mircea>=20 <note: at this point I'm not going to correct any remaining grammar=20 errors, such as the next line ("The pcelsRule is...") because there=20 are too many of them.>=20 - Page 24, Section 5.3, you say: "The pcelsRule is the base class=20 representing policy rules." Does this mean that an implementation=20 can NOT use the subclasses of pcimRule anymore?=20 <mircea>I fail to see the issue.=20 </mircea>=20 - Page 24, next paragraph, you say: "This class shares the=20 Condition/Action aggregation methods with the=20 pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass=20 object classes.". Why does it also not share the=20 pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass=20 object classes as well?=20 <mircea>Revised text. It was actually trying to say that:=20 " Like pcelsRule, instances of pcelsCompoundConditionAuxClass use=20 pcelsConditionList values and subordinated pcelsConditionAssociation=20 entries to aggregate policy conditions."=20 and=20 " Like pcelsRule, instances of pcelsCompoundActionAuxClass use=20 pcelsActionList values and subordinated pcelsActionAssociation=20 entries to aggregate policy actions."=20 </mircea>=20 - Page 25, top paragraph, again says that the implementer should ignore=20 an error condition. This isn't a good idea.=20 - Page 25, next paragraph has the same problem.=20 <mircea>Already discussed=20 </mircea>=20 - Page 26, the pcelsConditionListType attribute has a constraint. No=20 text is provided that instructs the implementer what to do, aside=20 from Note 5 on page 21, which says: "Text has been added to instruct servers and applications what to do if a value outside of this range is encountered" - which is exactly the problem - no text is here.=20 Note that this is a systemic problem with any constrained attribute=20 defined in this draft. Thus, I will only mention this once.=20 <mircea>All Fixed.=20 </mircea>=20 - Page 27, WHY isn't a PolicyGroup class implemented? You give no=20 reason for not doing this. Note also that Note 2 talks about ORDERED policy rules - I don't see how you can construct those.=20 <mircea>Already discussed=20 </mircea>=20 - Page 27, section 5.4, again you say "pcelsRule" instead of "non-=20 abstract subclasses of pcelsRule".=20 <mircea>Already discussed=20 </mircea>=20 - Page 28, top paragraph, another error that you are recommending=20 should be ignored=20 <mircea>Already discussed=20 </mircea>=20 - Page 28, DESC for pcelsConditionAssociation is wrong; you say that=20 it can be used for a pcelsRule instead of a non-abstract subclass of pcelsRule=20 <mircea>Already discussed=20 </mircea>=20 - Page 28, section 5.5, again you say "pcelsRule" instead of "non-=20 abstract subclasses of pcelsRule".=20 <mircea>Already discussed=20 </mircea>=20 - Page 28, last paragraph, another error that you are recommending=20 should be ignored.=20 <mircea>Already discussed=20 </mircea>=20 - Page 29, DESC for pcelsActionAssociation is wrong; you say that=20 it can be used for a pcelsRule instead of a non-abstract subclass of pcelsRule=20 <mircea>Already discussed=20 </mircea>=20 - Page 29, last paragraph above Section 5.6, another error that you are=20 recommending should be ignored.=20 <mircea>Already discussed=20 </mircea>=20 - Page 29, Section 5.6, last two paragraphs are errors that you are=20 recommending should be ignored.=20 <At this point, I'm going to stop listing these, as it is a systemic problem that should be fixed in the next release>=20 <mircea>Already discussed=20 </mircea>=20 - Page 29, last paragraph above Section 5.6, another error that you are=20 recommending should be ignored.=20 <mircea>Already discussed=20 </mircea>=20 - Page 30, the DESC for pcelsVariableDN is wrong. You say that it is a=20 "DN reference to a pcelsVariable entry", when it should be a DN=20 reference to a subclass of either pcelsExplicitVariableAuxClass or=20 pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass=20 <mircea>Already discussed=20 </mircea>=20 - Page 30, the DESC for pcelsValueDN is wrong - it should be a subclass=20 of pcelsValueDN.=20 <mircea>Already discussed=20 </mircea>=20 regards,=20 John=20 ------_=_NextPart_001_01C42B53.AE30CC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2>Hi Mircea,</FONT></SPAN></DIV> <DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2>thanks for addressing these issues, and apologies for the delay = in=20 response. Please see inline (<js>..</js>) for=20 clarifications.</FONT></SPAN></DIV> <DIV> </DIV> <DIV dir=3Dltr align=3Dleft> <P dir=3Dltr align=3Dleft><FONT face=3D"Times New Roman"><FONT=20 size=3D3>regards,<BR>John</FONT></FONT></P> <P dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2>-----Original=20 Message-----<BR><B>From:</B> [email protected]=20 [mailto:[email protected]] <BR><B>Sent:</B> Thursday, March 25, 2004 = 7:59=20 PM<BR><B>To:</B> John Strassner; [email protected]<BR><B>Subject:</B> RE: = [Policy]=20 FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04=20 .txt<BR><BR></P></FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <P><FONT size=3D2>John,</FONT> </P> <P><FONT size=3D2>I have reviewed your comments in detail and made = several=20 changes to the PCELS text (to be submitted in a few days) to address = these=20 issues. While for the most part I understand your concerns, there are = a few=20 items that I would like to discuss in more detail. See my comments = below=20 marked <mircea></mircea>.</FONT></P> <P><FONT size=3D2>Thank You,</FONT> <BR><FONT size=3D2>Mircea.</FONT> = </P> <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT = size=3D2>From: John=20 Strassner [<A=20 = href=3D"mailto:[email protected]">mailto:John.Strassner@intel= liden.com</A>]</FONT>=20 <BR><FONT size=3D2>Sent: Friday, February 13, 2004 9:32 PM</FONT> = <BR><FONT=20 size=3D2>To: '[email protected]'; '[email protected]'</FONT> <BR><FONT=20 size=3D2>Subject: RE: [Policy] FW: I-D=20 ACTION:draft-reyes-policy-core-ext-schema-04 .txt</FONT> </P><BR> <P><FONT size=3D2>First, I support Kurt's comments on LDAP, and will = reply to=20 those in a separate email. </FONT><BR><FONT = size=3D2><mircea>Kurt's=20 recommendations will be addressed in the next revision.</FONT> = <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2>Second, I list below a set of additional comments on = this=20 draft.</FONT> </P> <P><FONT size=3D2>Third, the lack of an overall diagram makes it very = difficult=20 to evaluate the correctness of this model. This draft is not complete = enough=20 to construct such a model.</FONT></P> <P><FONT size=3D2><mircea>Can you be more specific. The document = includes=20 several diagrams and tables. What is it missing?</FONT> <BR><FONT=20 size=3D2></mircea> <SPAN class=3D745254702-26042004><FONT=20 face=3D"Courier New" color=3D#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT = face=3D"Courier New"=20 color=3D#0000ff><js> True, there are several diagrams and = tables. However,=20 the draft lacks an overall conceptual model. For example, if you look = at=20 RFC3060, Figure 1 shows an overview of all of the classes = and their=20 relationships.</FONT> <FONT face=3D"Courier New" color=3D#0000ff> = Note that=20 there is no need to show attributes in such a picture - I'm just = looking for a=20 **visual** overview of how the different classes fit together.=20 </js></FONT></SPAN></FONT></P> <P><FONT size=3D2>Fourth, a cursory scan revealed that there is no=20 pcelsPolicyGroup class. This is strange, since PolicyGroup is listed = as a=20 subclass of PolicySet in RFC 3460. Why is this?</FONT></P> <P><FONT size=3D2><mircea>pcelsGroup will be added in the new=20 revision.</FONT> <BR><FONT size=3D2></mircea> </FONT></P> <P><FONT size=3D2>Fifth, why is there a pcelsRule and a pcimRule = class?</FONT>=20 <BR><FONT size=3D2><mircea>I do not understand the issue.</FONT> = <BR><FONT=20 size=3D2></mircea> <SPAN class=3D745254702-26042004><FONT=20 face=3D"Courier New" color=3D#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT = face=3D"Courier New"=20 color=3D#0000ff><js> Sorry for not being clearer. I understand = that you=20 wanted to create your own class (pcelsRule) because the semantics of = RFC3460=20 were different (for PolicyRules) than those of RFC3460. I support = your=20 mentioning both in the draft, since there was feedback (e.g., from = Ryan) that=20 some implementations were still using pcimRule. However, I think that = given=20 this feedback, this draft needs some guidelines as to when one = would use=20 pcelsRule and one would use pcimRule, and what the implications of = doing this=20 are (e.g., how priority is implemented). = </js></FONT></SPAN></FONT></P> <P><FONT size=3D2>Sixth, why is there no pcelsRuleValidityAssociation = subclass?=20 At this point, <mircea>I do not understand the issue. PCELS = reuses=20 pcimRuleValidityAssociation that is defined in PCLS</FONT></P> <P><FONT size=3D2></mircea> <SPAN = class=3D745254702-26042004><FONT=20 face=3D"Courier New" color=3D#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT = face=3D"Courier New"=20 color=3D#0000ff><js> True, this is addressed in Note 1 in page = 27 of the=20 draft. Looking at your class structure, since you subclassed other=20 associations, I was surprised that you didn't subclass this one = as well.=20 This is because pcelsRule and </FONT> <FONT face=3D"Courier New"=20 color=3D#0000ff>pcimRule are siblings, and pcimRuleValidityPeriod (in = PCIM) is=20 defined to exist between pcimRule and policyConditionTimePeriod only. = So, how=20 do pcelsRule instances use a policyConditionTimePeriod?=20 </js></FONT></SPAN></FONT></P> <P><FONT size=3D2>I started to go through the document in detail with = my=20 developers to try and implement it. We couldn't. We give you = inconsistencies=20 that we noticed (grammatical and otherwise) through page = 31).</FONT></P> <P><FONT size=3D2>Finally, I was surprised to see a lack of an = Acknowledgments=20 section, especially given the amount of feedback that several people = on this=20 list gave the authors. That's in poor form.</FONT></P> <P><FONT size=3D2><mircea>Acknowledgments will be added in the = new=20 revision.</FONT> <BR><FONT size=3D2></mircea> </FONT></P> <P><FONT size=3D2>Comments are as follows:</FONT> </P> <P><FONT size=3D2> - s/RFC zzzz/RFC 3703</FONT> <BR><FONT=20 size=3D2><mircea>Fixed.</FONT> <BR><FONT = size=3D2></mircea></FONT>=20 <BR><FONT size=3D2> </FONT> <BR><FONT size=3D2> - page 3. = You write:=20 "...the combined class hierarchy for the LDAP </FONT><BR><FONT=20 size=3D2> object classes defined in [PCLS] and in = this=20 document". You should</FONT> <BR><FONT size=3D2> = include=20 concepts from 3460 that you mapped into new classes, and</FONT> = <BR><FONT=20 size=3D2> add that you defined new classes not in = 3460 or=20 3703.</FONT> <BR><FONT size=3D2><mircea>Fixed.</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - page 4-7, class diagram - this diagram has = no=20 caption. Please add</FONT> <BR><FONT size=3D2> one. = In=20 addition, I find the diagram inpenetrable, in that the</FONT> = <BR><FONT=20 size=3D2> reader has no idea where these classes = came from. I=20 think you need</FONT> <BR><FONT size=3D2> a simpler=20 introduction saying 3060 provided this, 3460 did this, and</FONT> = <BR><FONT=20 size=3D2> thus we came up with this. Take this key = and show,=20 for any class </FONT><BR><FONT size=3D2> that isn't = new in=20 this document, where it came from.</FONT> <BR><FONT=20 size=3D2><mircea>Fixed.</FONT> <BR><FONT = size=3D2></mircea></FONT>=20 </P> <P><FONT size=3D2> - page 4 - why is your class named = pcelsFilerEntry,=20 when 3460 names</FONT> <BR><FONT size=3D2> its class = FilterEntryBase?</FONT> <BR><FONT size=3D2> - page 4 - why is = your class=20 named pcelsIPHeaders, when 3460 names</FONT> <BR><FONT=20 size=3D2> its class IPHeadersFilter? The Filter part = is=20 important! </FONT><BR><FONT size=3D2> - page 4 - why is your = class named=20 pcels8021Headers, when 3460 names</FONT> <BR><FONT = size=3D2> =20 its class 8021Filter? The Filter part is important!</FONT> <BR><FONT=20 size=3D2> - page 4 - why is your class named = pcelsCompoundFilterAuxClass,=20 when </FONT><BR><FONT size=3D2> a more consistent = name would=20 be pcelsCompoundFilterConditionAuxClass?</FONT> <BR><FONT=20 size=3D2> The Condition part is important!</FONT> = <BR><FONT=20 size=3D2><mircea>All renamed.</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - general reflections on the class = diagram: part=20 of the problem is that</FONT> <BR><FONT size=3D2> = you are=20 building a schema from three different sources: (1) RFC 3703,</FONT> = <BR><FONT=20 size=3D2> (2) RFC 3460, and (3) your own additions. = I see no=20 discussion on how</FONT> <BR><FONT size=3D2> these = relate to=20 each other, which would have been helpful.</FONT> <BR><FONT=20 size=3D2><mircea>The new revision will indicate all these = sources=20 explicitly.</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - page 7 - you didn't state whether = this is for=20 all associations. This</FONT> <BR><FONT size=3D2> is = exacerbated by you saying: "...might need to implement the = </FONT><BR><FONT=20 size=3D2> association..." - which implies a single=20 association. In addition,</FONT> <BR><FONT size=3D2> = this is a=20 terse description - the naive reader won't understand why</FONT> = <BR><FONT=20 size=3D2> aux classes are being used - you need a = reference or=20 a couple of</FONT> <BR><FONT size=3D2> sentences = explaining=20 this.</FONT> <BR><FONT size=3D2><mircea>Added example in support = of the=20 generic text. Please note that the reader is not going to be that = naive.=20 Section 2. ("Relationship to other Policy Framework Documents") will = also=20 indicate that "These three documents ([PCIM], [PCIM_EXT] and [PCLS]) = are a=20 prerequisite for reading and understanding this document."</FONT></P> <P><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - page 7 - you state: "The LDAP object = classes defined=20 in this document</FONT> <BR><FONT size=3D2> are a = direct=20 mapping from the corresponding classes and, in some </FONT><BR><FONT=20 size=3D2> cases, the associations defined in = [PCIM_EXT] ". Not=20 strictly true, </FONT><BR><FONT size=3D2> as you are = also=20 seeking to update RFC 3703 (e.g., where is </FONT><BR><FONT=20 size=3D2> pcimSubtreesPtrAuxClass defined in RFC=20 3460?).</FONT> <BR><FONT size=3D2><mircea>The text in section = 4.1 will be=20 revised for a better description of the mapping techniques utilised by = PCELS.=20 However, I do not understand </FONT></P> <P><FONT size=3D2>your reference to pcimSubtreesPtrAuxClass. That = class is not=20 defined in PCELS.</FONT> <BR><FONT = size=3D2><mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> If you look at RFC3703, we defined two aux classes = (pcimElementAuxClass and pcimSubtreesPtrAuxClass) to simplify = navigation=20 through the DIT, as well as retrieval of entries found more efficient. = I think=20 that you should take another look at the rationale behind these = classes, and=20 consider again whether they should be included in this draft.=20 </js></FONT></SPAN></P> <P><FONT size=3D2> - pages 8-11: your table has no = caption</FONT>=20 <BR><FONT size=3D2><mircea>Fixed.</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - pages 8-11: Where are classes like=20 pcimSubtreesPtrAuxClass? They</FONT> <BR><FONT = size=3D2> =20 aren't listed in this table, and better be, if you are = "updating"</FONT>=20 <BR><FONT size=3D2> RFC 3703.</FONT> <BR><FONT=20 size=3D2><mircea>The two tables list PCIM_EXT classes mapped by = PCELS. Why=20 should the tables include PCLS classes?</FONT> <BR><FONT=20 size=3D2></mircea><SPAN class=3D745254702-26042004><FONT = face=3D"Courier New"=20 color=3D#0000ff> </FONT></SPAN></FONT></P> <P><FONT size=3D2><SPAN class=3D745254702-26042004><FONT = face=3D"Courier New"=20 color=3D#0000ff><js> Because this draft is supposed to be=20 updating RFC3703, which means that you need to deal with classes = defined=20 in that RFC (such as pcimSubtreesPtrAuxClass) as well as = your own=20 classes. Or, at the very least, state why these classes do not need to = be=20 defined. </js></FONT> </SPAN></FONT><SPAN=20 class=3D745254702-26042004> </SPAN></P> <P><FONT size=3D2> - once again, I see lots of irksome naming = issues. The=20 LDAP schema</FONT> <BR><FONT size=3D2> shouldn't = change the=20 name of a class defined in another RFC. Why</FONT> <BR><FONT=20 size=3D2> have you done this?</FONT> <BR><FONT=20 size=3D2><mircea>All are going to be renamed to follow the = *exact*=20 PCIM_EXT names, but I fail to see where is the problem with the old=20 names.</FONT></P> <P><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> It's all about implementation ease. If an = earlier RFC=20 exists, the naming in that RFC should be respected and not changed.=20 </js></FONT> </SPAN></P> <P><FONT size=3D2> - page 8, 4th row. How can you give two = different=20 mappings to a single</FONT> <BR><FONT size=3D2> = object class?=20 And how can a RULE (i.e., pcelsRule) map to a GROUP?</FONT> <BR><FONT=20 size=3D2><mircea>pcelsGroup will be added in the new = revision.</FONT>=20 <BR><FONT size=3D2></mircea> </FONT></P> <P><FONT size=3D2> - page 10, 1st row. How can a single info = model=20 association map to</FONT> <BR><FONT size=3D2> two = different=20 associations? And do you mean "and" in this row? This</FONT> <BR><FONT = size=3D2> would mean that I would have to = instantiate both=20 pcelsPolicySet</FONT> <BR><FONT size=3D2> and=20 pcelsPolicySetAssociation, which is clearly wrong. This comment</FONT> = <BR><FONT size=3D2> also applies for the other rows = on this=20 page where you have "and".</FONT> <BR><FONT size=3D2><mircea> = ...means=20 that the PolicySetComponent aggregation is realised by a=20 pcelsPolicySetComponentList value in the aggregating pcelsPolicySet. = This=20 attribute value is a DN reference to a pcelsPolicySetAsociation entry. = The=20 pcelsPolicySetAsociation entry includes a pcelsPolicySetDN attribute = value=20 that is a reference to the aggregated pcelsPolicySet. The details are = in=20 section 5. The table only gives an overview of the mapping.</FONT></P> <P><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> OK, that makes sense, but I suggest you add a note = saying=20 "See section 5.x" so the impatient reader won't get frustrated. = ;-)=20 </js></FONT> </SPAN></P> <P><FONT size=3D2> - page 10 - it is of no help to say "see=20 PolicySetInSystem" in this</FONT> <BR><FONT = size=3D2> table=20 for the 3rd and 4th rows - that only confuses the reader.</FONT> = <BR><FONT=20 size=3D2> Please spell out what you mean = here.</FONT>=20 <BR><FONT size=3D2><mircea>Fixed. Details are in section = 5.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 11 - the reader will wonder why = ReusablePolicy=20 and </FONT><BR><FONT size=3D2> = PolicyRoleCollectionInSystem=20 are only implementable via DIT </FONT><BR><FONT = size=3D2> =20 containment, when every other association has an association = defined</FONT>=20 <BR><FONT size=3D2> (independent of whether DIT = containment=20 could be used).</FONT> <BR><FONT size=3D2><mircea>I fail to see = the=20 issue.</FONT> <BR><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> Good schemata are consistent. Why are these = two=20 associations only implementable via DIT containment?=20 </js></FONT> </SPAN></P> <P><FONT size=3D2> - Section 4.2, line 3, you write: "The = concept of an=20 ordered set of</FONT> <BR><FONT size=3D2> = policies...". LDAP=20 doesn't have ordered sets. How are you going to</FONT> <BR><FONT=20 size=3D2> implement this?</FONT> <BR><FONT=20 size=3D2><mircea>replaced "ordered" with "coherent" (from = PCIM_EXT)</FONT>=20 <BR><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> That's certainly better than incoherent ;-) but I = don't see=20 how this solves the problem, as the two aren't synonymous.=20 </js></FONT> </SPAN></P> <P><FONT size=3D2> - Page 13, Section 4.3, second paragraph -=20 s/deprecates/deprecate</FONT> <BR><FONT = size=3D2><mircea>Fixed.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 13, Note - actually, PCLS does NOT = have anything=20 to do with</FONT> <BR><FONT size=3D2> PCIMe, so this = note=20 needs to be reworded</FONT> <BR><FONT = size=3D2><mircea>Fixed.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 14, Section 4.5</FONT> <BR><FONT=20 size=3D2> - s/an other/another (and other = places)</FONT>=20 <BR><FONT size=3D2> - s/"rule /group"/"rule/group" = (5 places)=20 (and other places)</FONT> <BR><FONT = size=3D2><mircea>Fixed.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 16, section 4.6, </FONT><BR><FONT=20 size=3D2> - = s/CompoundPolicyActionclasses/CompoundPolicyAction=20 classes </FONT><BR><FONT size=3D2> - conditions=20 /actions/"conditions/actions" (and other places)</FONT> <BR><FONT=20 size=3D2><mircea>Fixed.</FONT> <BR><FONT = size=3D2></mircea></FONT>=20 </P> <P><FONT size=3D2> - Page 22. How are you going to enforce an = "ordered set=20 of </FONT><BR><FONT size=3D2> rules /groups"? That = is, how can=20 you guarantee that the DSA stores</FONT> <BR><FONT = size=3D2> =20 your rules/groups [sic] in the order that you want, and where = is</FONT>=20 <BR><FONT size=3D2> that order specified? What if a = DSA=20 doesn't have ordering controls?</FONT> <BR><FONT size=3D2> - = Same section=20 as above - you say that the "association entries enable = </FONT><BR><FONT=20 size=3D2> relative ordering of the aggregated = pcelsPolicySet=20 instances within </FONT><BR><FONT size=3D2> the = scope of the=20 aggregating pcelsPolicySet" - how is this </FONT><BR><FONT=20 size=3D2> accomplished with a plain, vanilla LDAP = server with=20 no controls?</FONT> <BR><FONT size=3D2><mircea>Text revised and = note added=20 to indicate that applications must not expect the LDAP data store to = implement=20 sorting and ordering.</FONT></P> <P><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 23 - the DESC for pcelsPolicySetList = should say=20 that it</FONT> <BR><FONT size=3D2> contains an = UNORDERED list=20 of DN references.</FONT> <BR><FONT = size=3D2><mircea>Fixed.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 23, note above Section 5.2, is = slightly=20 incorrect. Only those</FONT> <BR><FONT size=3D2> =20 implementations that WANT TO BE COMPATIBLE WITH PCELS should = use</FONT>=20 <BR><FONT size=3D2> this aggregation mechanism = instead of=20 those defined by PCLS. Not</FONT> <BR><FONT = size=3D2> every=20 implementation mechanism is going to want to change.</FONT> <BR><FONT=20 size=3D2><mircea>Revised. The section defining pcelsRule for = example will=20 include the following compatibility note:</FONT> </P> <P><FONT size=3D2> "Note 2: PCELS implementations SHOULD = support=20 pcelsRule and its two</FONT> <BR><FONT size=3D2> = subclasses and MAY=20 also support pcimRule and its two subclasses</FONT> <BR><FONT=20 size=3D2> [PCLS]. Applications that choose to support = pcelsRule and=20 its two</FONT> <BR><FONT size=3D2> subclasses MUST use the = aggregation mechanism provided by</FONT> <BR><FONT = size=3D2> =20 pcelsPolicySetAssociation for aggregating policy groups or = policy</FONT>=20 <BR><FONT size=3D2> rules in policy rules represented as = instances=20 of pcelsRule.</FONT> <BR><FONT size=3D2> Applications that = intend to=20 be compatible with [PCIM_EXT] MUST</FONT> <BR><FONT = size=3D2> =20 support pcelsRule and its two subclasses."</FONT> </P> <P><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> The last MUST contradicts the first SHOULD in = the above=20 statement; please change it to SHOULD. The first MUSt in the above = statement=20 is OK. </js></FONT> </SPAN></P> <P><FONT size=3D2> - Page 23, Section 5.2, says "The=20 pcelsPolicySetAssociation class is </FONT><BR><FONT = size=3D2> =20 used to aggregate instances of pcelsPolicySet into other = entries."</FONT>=20 <BR><FONT size=3D2> This is incorrect, as = pcelsPolicySet is=20 abstract and thus cannot be</FONT> <BR><FONT = size=3D2> =20 instantiated.</FONT> <BR><FONT size=3D2><mircea> I fail to see a = problem=20 with "instance of <abstract_class>". It is obvious that it means = "instance of non-abstract subclass of <abstract_class>". The=20 "non-abstract subclass of" is superfluous and has been omitted in = order to=20 improve the text readabilitiy. PCLS, for instance, uses such = expressions on=20 several occasions. E.g.: (PCLS page 50 first paragraph) "instances of=20 pcimRules". Note that "pcimRules" is not a class name.</FONT></P> <P><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> I still disagree (and with PCLS page 50 as well) - = it is=20 imprecise. </js></FONT> </SPAN></P> <P><FONT size=3D2> - Same section, you write: "...realizes a = (subclass=20 of)</FONT> <BR><FONT size=3D2> PolicySetComponent = aggregation=20 [sic]. When subordinated to (subclass </FONT><BR><FONT=20 size=3D2> of) dlm1System...realizes a = PolicySetInSystem=20 association [sic]".</FONT> <BR><FONT size=3D2> How = can the=20 same element realize an aggregation in one usage and an</FONT> = <BR><FONT=20 size=3D2> association in another usage? This is = semantically=20 inconsistent.</FONT> <BR><FONT size=3D2><mircea>I fail to see = the issue.=20 The semantics of pcelsPolicySetAssociation are context = sensitive.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> The point is that there is a pronounced difference = between=20 an aggregation and an association. Although it is sadly commonplace to = call=20 everything an association. ;-( I would suggest changing = your=20 text to either only use "association" or only use = "aggregation" in the=20 same paragraph. </js></FONT> </SPAN></P> <P><FONT size=3D2> - Next paragraph says: "A non-reusable = instance of=20 (subclass of)</FONT> <BR><FONT size=3D2> = pcelsPolicySet is=20 attached as auxiliary class directly to the </FONT><BR><FONT=20 size=3D2> pcelsPolicySetAssociation entry." = Subclasses of=20 pcelsPolicySet that</FONT> <BR><FONT size=3D2> are = not=20 abstract are pcelsRuleAuxClass and pcelsRuleInstance. The</FONT> = <BR><FONT=20 size=3D2> above sentence only makes sense for=20 pcelsRuleAuxClass.</FONT> <BR><FONT size=3D2><mircea>The new = specification=20 will include pcelsGroup as well. As result, the current text will make = more=20 sense.</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Next paragraph doesn't make sense. First, = you clearly=20 mean a non-</FONT> <BR><FONT size=3D2> abstract = subclass of=20 pcelsPolicySet. Second, you are recommending</FONT> <BR><FONT=20 size=3D2> that an ERROR be ignored? Why don't you = stop=20 operation?</FONT> <BR><FONT size=3D2><mircea>Revised = text:</FONT> </P> <P><FONT size=3D2> "When reading a = pcelsPolicySetAssociation=20 instance that has a</FONT> <BR><FONT size=3D2> = pcelsPolicySet=20 attached, the attribute pcelsPolicySetDN MUST</FONT> <BR><FONT=20 size=3D2> be ignored. Applications SHOULD remove the=20 pcelsPolicySetDN value</FONT> <BR><FONT size=3D2> from a=20 pcelsPolicySetAssociation upon attachment of a pcelsPolicySet</FONT> = <BR><FONT=20 size=3D2> to the entry."</FONT> </P> <P><FONT size=3D2>This gives applications some flexibility.</FONT> = <BR><FONT=20 size=3D2></mircea></FONT> <SPAN = class=3D745254702-26042004><FONT=20 face=3D"Courier New" color=3D#0000ff size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> That's much better = </js></FONT> </SPAN></P> <P><FONT size=3D2> - Page 24, DESC of pcelsPriority is = insufficient, as=20 "0" has special</FONT> <BR><FONT size=3D2> semantics = that you=20 haven't mentioned. This should, of course, also</FONT> <BR><FONT=20 size=3D2> be present in accompanying prose, as Kurt = points=20 out.</FONT> <BR><FONT size=3D2><mircea>The PCIM_EXT property and = the=20 attribute value restrictions going to be described in more detail (in = prose).=20 However I fail to find the meaning of "0" in PCIM_EXT. Can you help me = locate=20 the text?</FONT></P> <P><FONT size=3D2></mircea></FONT> <SPAN=20 class=3D745254702-26042004><FONT face=3D"Courier New" color=3D#0000ff=20 size=3D2> </FONT></SPAN></P> <P><SPAN class=3D745254702-26042004><FONT face=3D"Courier New" = color=3D#0000ff=20 size=3D2><js> My mistake, the RFC states that this is = simply the=20 default value. </js></FONT> </SPAN></P> <P><FONT size=3D2> - Page 24, DESC of pcelsPolicySetDN should = state that=20 this is an</FONT> <BR><FONT size=3D2> UNORDERED list = of=20 DNs.</FONT> <BR><FONT size=3D2><mircea>Fixed.</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 24, Section 5.3, s/The Three Classes=20 pcelsRule/The pcelsRule</FONT> <BR><FONT size=3D2> = Class and=20 Its Subclasses</FONT> <BR><FONT size=3D2><mircea>Fixed.</FONT> = <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2><note: at this point I'm not going to correct any = remaining=20 grammar</FONT> <BR><FONT size=3D2> errors, such as the next line = ("The=20 pcelsRule is...") because there</FONT> <BR><FONT size=3D2> are = too many of=20 them.></FONT> <BR><FONT size=3D2> - Page 24, Section 5.3, you = say: "The=20 pcelsRule is the base class</FONT> <BR><FONT = size=3D2> =20 representing policy rules." Does this mean that an = implementation</FONT>=20 <BR><FONT size=3D2> can NOT use the subclasses of = pcimRule=20 anymore?</FONT> <BR><FONT size=3D2><mircea>I fail to see the = issue.</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 24, next paragraph, you say: "This = class shares=20 the </FONT><BR><FONT size=3D2> Condition/Action = aggregation=20 methods with the</FONT> <BR><FONT size=3D2> =20 pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass</FONT>=20 <BR><FONT size=3D2> object classes.". Why does it = also not=20 share the</FONT> <BR><FONT size=3D2> =20 pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass</FONT> = <BR><FONT=20 size=3D2> object classes as well?</FONT> <BR><FONT=20 size=3D2><mircea>Revised text. It was actually trying to say = that:</FONT>=20 </P> <P><FONT size=3D2>" Like pcelsRule, instances of=20 pcelsCompoundConditionAuxClass use</FONT> <BR><FONT = size=3D2> =20 pcelsConditionList values and subordinated = pcelsConditionAssociation</FONT>=20 <BR><FONT size=3D2> entries to aggregate policy = conditions."</FONT>=20 <BR><FONT size=3D2>and</FONT> <BR><FONT size=3D2>" Like = pcelsRule,=20 instances of pcelsCompoundActionAuxClass use</FONT> <BR><FONT=20 size=3D2> pcelsActionList values and subordinated=20 pcelsActionAssociation</FONT> <BR><FONT size=3D2> entries = to=20 aggregate policy actions."</FONT> <BR><FONT = size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 25, top paragraph, again says that the = implementer should ignore</FONT> <BR><FONT size=3D2> = an error=20 condition. This isn't a good idea.</FONT> <BR><FONT size=3D2> - = Page 25,=20 next paragraph has the same problem.</FONT> <BR><FONT=20 size=3D2><mircea>Already discussed</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 26, the pcelsConditionListType = attribute has a=20 constraint. No</FONT> <BR><FONT size=3D2> text is = provided=20 that instructs the implementer what to do, aside</FONT> <BR><FONT=20 size=3D2> from Note 5 on page 21, which says: "Text = has been=20 added to instruct</FONT> <BR><FONT size=3D2> servers = and=20 applications what to do if a value outside of this range</FONT> = <BR><FONT=20 size=3D2> is encountered" - which is exactly the = problem - no=20 text is here.</FONT> <BR><FONT size=3D2>Note that this is a systemic = problem=20 with any constrained attribute</FONT> <BR><FONT size=3D2>defined in = this draft.=20 Thus, I will only mention this once.</FONT> <BR><FONT = size=3D2><mircea>All=20 Fixed.</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 27, WHY isn't a PolicyGroup class = implemented?=20 You give no</FONT> <BR><FONT size=3D2> reason for = not doing=20 this. Note also that Note 2 talks about ORDERED</FONT> <BR><FONT=20 size=3D2> policy rules - I don't see how you can = construct=20 those.</FONT> <BR><FONT size=3D2><mircea>Already = discussed</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 27, section 5.4, again you say = "pcelsRule"=20 instead of "non-</FONT> <BR><FONT size=3D2> abstract = subclasses of pcelsRule".</FONT> <BR><FONT = size=3D2><mircea>Already=20 discussed</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 28, top paragraph, another error that = you are=20 recommending </FONT><BR><FONT size=3D2> should be=20 ignored</FONT> <BR><FONT size=3D2><mircea>Already = discussed</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 28, DESC for pcelsConditionAssociation = is wrong;=20 you say that</FONT> <BR><FONT size=3D2> it can be = used for a=20 pcelsRule instead of a non-abstract subclass of</FONT> <BR><FONT=20 size=3D2> pcelsRule</FONT> <BR><FONT=20 size=3D2><mircea>Already discussed</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 28, section 5.5, again you say = "pcelsRule"=20 instead of "non-</FONT> <BR><FONT size=3D2> abstract = subclasses of pcelsRule".</FONT> <BR><FONT = size=3D2><mircea>Already=20 discussed</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 28, last paragraph, another = error that you=20 are recommending</FONT> <BR><FONT size=3D2> should = be=20 ignored.</FONT> <BR><FONT size=3D2><mircea>Already = discussed</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 29, DESC for = pcelsActionAssociation is=20 wrong; you say that </FONT><BR><FONT size=3D2> it = can be used=20 for a pcelsRule instead of a non-abstract subclass of</FONT> <BR><FONT = size=3D2> pcelsRule</FONT> <BR><FONT=20 size=3D2><mircea>Already discussed</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 29, last paragraph above Section = 5.6,=20 another error that you are</FONT> <BR><FONT = size=3D2> =20 recommending should be ignored.</FONT> <BR><FONT = size=3D2><mircea>Already=20 discussed</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 29, Section 5.6, last two = paragraphs are=20 errors that you are</FONT> <BR><FONT size=3D2> = recommending=20 should be ignored.</FONT> <BR><FONT size=3D2><At this point, I'm = going to=20 stop listing these, as it is a systemic problem that should be fixed = in the=20 next release></FONT> <BR><FONT size=3D2><mircea>Already=20 discussed</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 29, last paragraph above Section = 5.6,=20 another error that you are</FONT> <BR><FONT = size=3D2> =20 recommending should be ignored.</FONT> <BR><FONT = size=3D2><mircea>Already=20 discussed</FONT> <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 30, the DESC for pcelsVariableDN = is wrong.=20 You say that it is a</FONT> <BR><FONT size=3D2> "DN = reference=20 to a pcelsVariable entry", when it should be a DN</FONT> <BR><FONT=20 size=3D2> reference to a subclass of either=20 pcelsExplicitVariableAuxClass or</FONT> <BR><FONT = size=3D2> =20 pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass</FONT> = <BR><FONT=20 size=3D2><mircea>Already discussed</FONT> <BR><FONT=20 size=3D2></mircea></FONT> </P> <P><FONT size=3D2> - Page 30, the DESC for pcelsValueDN is = wrong -=20 it should be a subclass</FONT> <BR><FONT size=3D2> = of=20 pcelsValueDN.</FONT> <BR><FONT size=3D2><mircea>Already = discussed</FONT>=20 <BR><FONT size=3D2></mircea></FONT> </P> <P><FONT size=3D2></FONT> </P> <P><FONT size=3D2>regards,</FONT> <BR><FONT size=3D2>John=20 </FONT><BR></P></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C42B53.AE30CC10--