Part2: RE: FW: I-D ACTION:draft-reyes-policy-core-ext-sc hema-04 .txt
[email protected] Fri, 26 Mar 2004 07:47:10 -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.D64096F0 Content-Type: text/plain; charset="ISO-8859-1" my message has exceeded the 40 k limit. see below part2 > -----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 > [...] (continues...) > - Page 16, section 4.6, > - s/CompoundPolicyActionclasses/CompoundPolicyAction classes > - conditions /actions/"conditions/actions" (and other places) > <mircea>Fixed. > </mircea> > > - Page 22. How are you going to enforce an "ordered set of > rules /groups"? That is, how can you guarantee that the DSA stores > your rules/groups [sic] in the order that you want, and where is > that order specified? What if a DSA doesn't have ordering > controls? > - Same section as above - you say that the "association > entries enable > relative ordering of the aggregated pcelsPolicySet > instances within > the scope of the aggregating pcelsPolicySet" - how is this > accomplished with a plain, vanilla LDAP server with no controls? > <mircea>Text revised and note added to indicate that > applications must not expect the LDAP data store to implement > sorting and ordering. > </mircea> > > - Page 23 - the DESC for pcelsPolicySetList should say that it > contains an UNORDERED list of DN references. > <mircea>Fixed. > </mircea> > > - 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> > > - 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> > > - 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> > > - Next paragraph says: "A non-reusable instance of (subclass of) > pcelsPolicySet is attached as auxiliary class directly to the > pcelsPolicySetAssociation entry." Subclasses of > pcelsPolicySet that > are not abstract are pcelsRuleAuxClass and pcelsRuleInstance. The > above sentence only makes sense for pcelsRuleAuxClass. > <mircea>The new specification will include pcelsGroup as > well. As result, the current text will make more sense. > </mircea> > > - Next paragraph doesn't make sense. First, you clearly mean a non- > abstract subclass of pcelsPolicySet. Second, you are recommending > that an ERROR be ignored? Why don't you stop operation? > <mircea>Revised text: > > "When reading a pcelsPolicySetAssociation instance that has a > pcelsPolicySet attached, the attribute pcelsPolicySetDN MUST > be ignored. Applications SHOULD remove the pcelsPolicySetDN value > from a pcelsPolicySetAssociation upon attachment of a > pcelsPolicySet > to the entry." > > This gives applications some flexibility. > </mircea> > > - Page 24, DESC of pcelsPriority is insufficient, as "0" has special > semantics that you haven't mentioned. This should, of course, also > be present in accompanying prose, as Kurt points out. > <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> > > - Page 24, DESC of pcelsPolicySetDN should state that this is an > UNORDERED list of DNs. > <mircea>Fixed. > </mircea> > > - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule > Class and Its Subclasses > <mircea>Fixed. > </mircea> > > <note: at this point I'm not going to correct any remaining grammar > errors, such as the next line ("The pcelsRule is...") because there > are too many of them.> > - Page 24, Section 5.3, you say: "The pcelsRule is the base class > representing policy rules." Does this mean that an implementation > can NOT use the subclasses of pcimRule anymore? > <mircea>I fail to see the issue. > </mircea> > > - Page 24, next paragraph, you say: "This class shares the > Condition/Action aggregation methods with the > pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass > object classes.". Why does it also not share the > pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass > object classes as well? > <mircea>Revised text. It was actually trying to say that: > > " Like pcelsRule, instances of pcelsCompoundConditionAuxClass use > pcelsConditionList values and subordinated > pcelsConditionAssociation > entries to aggregate policy conditions." > and > " Like pcelsRule, instances of pcelsCompoundActionAuxClass use > pcelsActionList values and subordinated pcelsActionAssociation > entries to aggregate policy actions." > </mircea> > > - Page 25, top paragraph, again says that the implementer > should ignore > an error condition. This isn't a good idea. > - Page 25, next paragraph has the same problem. > <mircea>Already discussed > </mircea> > > - Page 26, the pcelsConditionListType attribute has a constraint. No > text is provided that instructs the implementer what to do, aside > 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. > Note that this is a systemic problem with any constrained attribute > defined in this draft. Thus, I will only mention this once. > <mircea>All Fixed. > </mircea> > > - Page 27, WHY isn't a PolicyGroup class implemented? You give no > reason for not doing this. Note also that Note 2 talks > about ORDERED > policy rules - I don't see how you can construct those. > <mircea>Already discussed > </mircea> > > - Page 27, section 5.4, again you say "pcelsRule" instead of "non- > abstract subclasses of pcelsRule". > <mircea>Already discussed > </mircea> > > - Page 28, top paragraph, another error that you are recommending > should be ignored > <mircea>Already discussed > </mircea> > > - Page 28, DESC for pcelsConditionAssociation is wrong; you say that > it can be used for a pcelsRule instead of a non-abstract > subclass of > pcelsRule > <mircea>Already discussed > </mircea> > > - Page 28, section 5.5, again you say "pcelsRule" instead of "non- > abstract subclasses of pcelsRule". > <mircea>Already discussed > </mircea> > > - Page 28, last paragraph, another error that you are recommending > should be ignored. > <mircea>Already discussed > </mircea> > > - Page 29, DESC for pcelsActionAssociation is wrong; you say that > it can be used for a pcelsRule instead of a non-abstract > subclass of > pcelsRule > <mircea>Already discussed > </mircea> > > - Page 29, last paragraph above Section 5.6, another error > that you are > recommending should be ignored. > <mircea>Already discussed > </mircea> > > - Page 29, Section 5.6, last two paragraphs are errors that you are > recommending should be ignored. > <At this point, I'm going to stop listing these, as it is a > systemic problem that should be fixed in the next release> > <mircea>Already discussed > </mircea> > > - Page 29, last paragraph above Section 5.6, another error > that you are > recommending should be ignored. > <mircea>Already discussed > </mircea> > > - Page 30, the DESC for pcelsVariableDN is wrong. You say > that it is a > "DN reference to a pcelsVariable entry", when it should be a DN > reference to a subclass of either pcelsExplicitVariableAuxClass or > pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass > <mircea>Already discussed > </mircea> > > - Page 30, the DESC for pcelsValueDN is wrong - it should > be a subclass > of pcelsValueDN. > <mircea>Already discussed > </mircea> > > > > regards, > John > John C. Strassner > Chief Strategy Officer > Intelliden Inc. > 90 South Cascade Avenue > Colorado Springs, CO 80906 USA > phone: +1.719.785.0648 > fax: +1.719.785.0644 > email: [email protected] > ------_=_NextPart_001_01C41338.D64096F0 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>Part2: 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 part2</FONT> </P> <BR> <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> </P> <P><FONT SIZE=3D2>[...]</FONT> <BR><FONT SIZE=3D2>(continues...)</FONT> <BR><FONT SIZE=3D2>> - Page 16, section 4.6, </FONT> <BR><FONT SIZE=3D2>> - = s/CompoundPolicyActionclasses/CompoundPolicyAction classes </FONT> <BR><FONT SIZE=3D2>> - conditions = /actions/"conditions/actions" (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>> - Page 22. How are you going to = enforce an "ordered set of </FONT> <BR><FONT SIZE=3D2>> rules /groups"? = That is, how can you guarantee that the DSA stores</FONT> <BR><FONT SIZE=3D2>> your rules/groups [sic] = in the order that you want, and where is</FONT> <BR><FONT SIZE=3D2>> that order specified? = What if a DSA doesn't have ordering </FONT> <BR><FONT SIZE=3D2>> controls?</FONT> <BR><FONT SIZE=3D2>> - Same section as above - you say = that the "association </FONT> <BR><FONT SIZE=3D2>> entries enable </FONT> <BR><FONT SIZE=3D2>> relative ordering of = the aggregated pcelsPolicySet </FONT> <BR><FONT SIZE=3D2>> instances within </FONT> <BR><FONT SIZE=3D2>> the scope of the = aggregating pcelsPolicySet" - how is this </FONT> <BR><FONT SIZE=3D2>> accomplished with a = plain, vanilla LDAP server with no controls?</FONT> <BR><FONT SIZE=3D2>> <mircea>Text revised and note added to = indicate that </FONT> <BR><FONT SIZE=3D2>> applications must not expect the LDAP data = store to implement </FONT> <BR><FONT SIZE=3D2>> sorting and ordering.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 23 - the DESC for = pcelsPolicySetList should say that it</FONT> <BR><FONT SIZE=3D2>> contains an UNORDERED = list of DN references.</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 23, note above Section 5.2, = is slightly incorrect. Only those</FONT> <BR><FONT SIZE=3D2>> implementations that = WANT TO BE COMPATIBLE WITH PCELS should use</FONT> <BR><FONT SIZE=3D2>> this aggregation = mechanism instead of those defined by PCLS. Not</FONT> <BR><FONT SIZE=3D2>> every implementation = mechanism is going to want to change.</FONT> <BR><FONT SIZE=3D2>> <mircea>Revised. The section defining = pcelsRule for example </FONT> <BR><FONT SIZE=3D2>> will include the following compatibility = note:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> "Note 2: PCELS = implementations SHOULD support pcelsRule and its two</FONT> <BR><FONT SIZE=3D2>> subclasses and MAY also = support pcimRule and its two subclasses</FONT> <BR><FONT SIZE=3D2>> [PCLS]. Applications that = choose to support pcelsRule and its two</FONT> <BR><FONT SIZE=3D2>> subclasses MUST use the = aggregation mechanism provided by</FONT> <BR><FONT SIZE=3D2>> pcelsPolicySetAssociation for = aggregating policy groups or policy</FONT> <BR><FONT SIZE=3D2>> rules in policy rules = represented as instances of pcelsRule.</FONT> <BR><FONT SIZE=3D2>> Applications that intend to = be compatible with [PCIM_EXT] MUST</FONT> <BR><FONT SIZE=3D2>> support pcelsRule and its two = subclasses."</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 23, Section 5.2, says = "The pcelsPolicySetAssociation </FONT> <BR><FONT SIZE=3D2>> class is </FONT> <BR><FONT SIZE=3D2>> used to aggregate = instances of pcelsPolicySet into other entries."</FONT> <BR><FONT SIZE=3D2>> This is incorrect, as = pcelsPolicySet is abstract and thus </FONT> <BR><FONT SIZE=3D2>> cannot be</FONT> <BR><FONT SIZE=3D2>> instantiated.</FONT> <BR><FONT SIZE=3D2>> <mircea> I fail to see a problem with = "instance of </FONT> <BR><FONT SIZE=3D2>> <abstract_class>". It is obvious = that it means "instance of </FONT> <BR><FONT SIZE=3D2>> non-abstract subclass of = <abstract_class>". The "non-abstract </FONT> <BR><FONT SIZE=3D2>> subclass of" is superfluous and has been = omitted in order to </FONT> <BR><FONT SIZE=3D2>> improve the text readabilitiy. PCLS, for = instance, uses such </FONT> <BR><FONT SIZE=3D2>> expressions on several occasions. E.g.: (PCLS = page 50 first </FONT> <BR><FONT SIZE=3D2>> paragraph) "instances of pcimRules". = Note that "pcimRules" is </FONT> <BR><FONT SIZE=3D2>> not a class name.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Same section, you write: = "...realizes a (subclass of)</FONT> <BR><FONT SIZE=3D2>> PolicySetComponent = aggregation [sic]. When subordinated </FONT> <BR><FONT SIZE=3D2>> to (subclass </FONT> <BR><FONT SIZE=3D2>> of) = dlm1System...realizes a PolicySetInSystem association = [sic]".</FONT> <BR><FONT SIZE=3D2>> How can the same = element realize an aggregation in one </FONT> <BR><FONT SIZE=3D2>> usage and an</FONT> <BR><FONT SIZE=3D2>> association in another = usage? This is semantically inconsistent.</FONT> <BR><FONT SIZE=3D2>> <mircea>I fail to see the issue. The = semantics of </FONT> <BR><FONT SIZE=3D2>> pcelsPolicySetAssociation are context = sensitive.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Next paragraph says: "A = non-reusable instance of (subclass of)</FONT> <BR><FONT SIZE=3D2>> pcelsPolicySet is = attached as auxiliary class directly to the </FONT> <BR><FONT SIZE=3D2>> = pcelsPolicySetAssociation entry." Subclasses of </FONT> <BR><FONT SIZE=3D2>> pcelsPolicySet that</FONT> <BR><FONT SIZE=3D2>> are not abstract are = pcelsRuleAuxClass and pcelsRuleInstance. The</FONT> <BR><FONT SIZE=3D2>> above sentence only = makes sense for pcelsRuleAuxClass.</FONT> <BR><FONT SIZE=3D2>> <mircea>The new specification will = include pcelsGroup as </FONT> <BR><FONT SIZE=3D2>> well. As result, the current text will make = more sense.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Next paragraph doesn't make = sense. First, you clearly mean a non-</FONT> <BR><FONT SIZE=3D2>> abstract subclass of = pcelsPolicySet. Second, you are recommending</FONT> <BR><FONT SIZE=3D2>> that an ERROR be = ignored? Why don't you stop operation?</FONT> <BR><FONT SIZE=3D2>> <mircea>Revised text:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> "When reading a = pcelsPolicySetAssociation instance that has a</FONT> <BR><FONT SIZE=3D2>> pcelsPolicySet attached, the = attribute pcelsPolicySetDN MUST</FONT> <BR><FONT SIZE=3D2>> be ignored. Applications = SHOULD remove the pcelsPolicySetDN value</FONT> <BR><FONT SIZE=3D2>> from a = pcelsPolicySetAssociation upon attachment of a </FONT> <BR><FONT SIZE=3D2>> pcelsPolicySet</FONT> <BR><FONT SIZE=3D2>> to the entry."</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> This gives applications some = flexibility.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 24, DESC of pcelsPriority is = insufficient, as "0" has special</FONT> <BR><FONT SIZE=3D2>> semantics that you = haven't mentioned. This should, of course, also</FONT> <BR><FONT SIZE=3D2>> be present in = accompanying prose, as Kurt points out.</FONT> <BR><FONT SIZE=3D2>> <mircea>The PCIM_EXT property and the = attribute value </FONT> <BR><FONT SIZE=3D2>> restrictions going to be described in more = detail (in prose). </FONT> <BR><FONT SIZE=3D2>> However I fail to find the meaning of = "0" in PCIM_EXT. Can </FONT> <BR><FONT SIZE=3D2>> you help me locate the text?</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 24, DESC of pcelsPolicySetDN = should state that this is an</FONT> <BR><FONT SIZE=3D2>> UNORDERED list of = DNs.</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 24, Section 5.3, s/The Three = Classes pcelsRule/The pcelsRule</FONT> <BR><FONT SIZE=3D2>> Class and Its = Subclasses</FONT> <BR><FONT SIZE=3D2>> <mircea>Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> <note: at this point I'm not going to = correct any remaining grammar</FONT> <BR><FONT SIZE=3D2>> errors, such as the next line ("The = pcelsRule is...") because there</FONT> <BR><FONT SIZE=3D2>> are too many of them.></FONT> <BR><FONT SIZE=3D2>> - Page 24, Section 5.3, you say: = "The pcelsRule is the base class</FONT> <BR><FONT SIZE=3D2>> representing policy = rules." Does this mean that an implementation</FONT> <BR><FONT SIZE=3D2>> can NOT use the = subclasses of pcimRule anymore?</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>> - Page 24, next paragraph, you say: = "This class shares the </FONT> <BR><FONT SIZE=3D2>> Condition/Action = aggregation methods with the</FONT> <BR><FONT SIZE=3D2>> = pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass</FONT> <BR><FONT SIZE=3D2>> object classes.". = Why does it also not share the</FONT> <BR><FONT SIZE=3D2>> = pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass</FONT> <BR><FONT SIZE=3D2>> object classes as = well?</FONT> <BR><FONT SIZE=3D2>> <mircea>Revised text. It was actually = trying to say that:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> " Like pcelsRule, instances of = pcelsCompoundConditionAuxClass use</FONT> <BR><FONT SIZE=3D2>> pcelsConditionList values and = subordinated </FONT> <BR><FONT SIZE=3D2>> pcelsConditionAssociation</FONT> <BR><FONT SIZE=3D2>> entries to aggregate policy = conditions."</FONT> <BR><FONT SIZE=3D2>> and</FONT> <BR><FONT SIZE=3D2>> " Like pcelsRule, instances of = pcelsCompoundActionAuxClass use</FONT> <BR><FONT SIZE=3D2>> pcelsActionList values and = subordinated pcelsActionAssociation</FONT> <BR><FONT SIZE=3D2>> entries to aggregate policy = actions."</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 25, top paragraph, again = says that the implementer </FONT> <BR><FONT SIZE=3D2>> should ignore</FONT> <BR><FONT SIZE=3D2>> an error condition. = This isn't a good idea.</FONT> <BR><FONT SIZE=3D2>> - Page 25, next paragraph has the = same problem.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 26, the = pcelsConditionListType attribute has a constraint. No</FONT> <BR><FONT SIZE=3D2>> text is provided that = instructs the implementer what to do, aside</FONT> <BR><FONT SIZE=3D2>> from Note 5 on page 21, = which says: "Text has been added </FONT> <BR><FONT SIZE=3D2>> to instruct</FONT> <BR><FONT SIZE=3D2>> servers and = applications what to do if a value outside of </FONT> <BR><FONT SIZE=3D2>> this range</FONT> <BR><FONT SIZE=3D2>> is encountered" - = which is exactly the problem - no text is here.</FONT> <BR><FONT SIZE=3D2>> Note that this is a systemic problem with any = constrained attribute</FONT> <BR><FONT SIZE=3D2>> defined in this draft. Thus, I will only = mention this once.</FONT> <BR><FONT SIZE=3D2>> <mircea>All Fixed.</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 27, WHY isn't a PolicyGroup = class implemented? You give no</FONT> <BR><FONT SIZE=3D2>> reason for not doing = this. Note also that Note 2 talks </FONT> <BR><FONT SIZE=3D2>> about ORDERED</FONT> <BR><FONT SIZE=3D2>> policy rules - I don't = see how you can construct those.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 27, section 5.4, again you = say "pcelsRule" instead of "non-</FONT> <BR><FONT SIZE=3D2>> abstract subclasses of = pcelsRule".</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 28, top paragraph, another = error that you are recommending </FONT> <BR><FONT SIZE=3D2>> should be = ignored</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 28, DESC for = pcelsConditionAssociation is wrong; you say that</FONT> <BR><FONT SIZE=3D2>> it can be used for a = pcelsRule instead of a non-abstract </FONT> <BR><FONT SIZE=3D2>> subclass of</FONT> <BR><FONT SIZE=3D2>> pcelsRule</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 28, section 5.5, again you = say "pcelsRule" instead of "non-</FONT> <BR><FONT SIZE=3D2>> abstract subclasses of = pcelsRule".</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 28, last paragraph, = another error that you are recommending</FONT> <BR><FONT SIZE=3D2>> should be = ignored.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 29, DESC for = pcelsActionAssociation is wrong; you say that </FONT> <BR><FONT SIZE=3D2>> it can be used for a = pcelsRule instead of a non-abstract </FONT> <BR><FONT SIZE=3D2>> subclass of</FONT> <BR><FONT SIZE=3D2>> pcelsRule</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 29, last paragraph = above Section 5.6, another error </FONT> <BR><FONT SIZE=3D2>> that you are</FONT> <BR><FONT SIZE=3D2>> recommending should be = ignored.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 29, Section 5.6, last = two paragraphs are errors that you are</FONT> <BR><FONT SIZE=3D2>> recommending should be = ignored.</FONT> <BR><FONT SIZE=3D2>> <At this point, I'm going to stop listing = these, as it is a </FONT> <BR><FONT SIZE=3D2>> systemic problem that should be fixed in the = next release></FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 29, last paragraph = above Section 5.6, another error </FONT> <BR><FONT SIZE=3D2>> that you are</FONT> <BR><FONT SIZE=3D2>> recommending should be = ignored.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 30, the DESC for = pcelsVariableDN is wrong. You say </FONT> <BR><FONT SIZE=3D2>> that it is a</FONT> <BR><FONT SIZE=3D2>> "DN reference to a = pcelsVariable entry", when it should be a DN</FONT> <BR><FONT SIZE=3D2>> reference to a subclass = of either pcelsExplicitVariableAuxClass or</FONT> <BR><FONT SIZE=3D2>> = pcelsImplicitVariableAuxClass or pcelsVendorVariableAuxClass</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> - Page 30, the DESC for = pcelsValueDN is wrong - it should </FONT> <BR><FONT SIZE=3D2>> be a subclass</FONT> <BR><FONT SIZE=3D2>> of pcelsValueDN.</FONT> <BR><FONT SIZE=3D2>> <mircea>Already discussed</FONT> <BR><FONT SIZE=3D2>> </mircea></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> regards,</FONT> <BR><FONT SIZE=3D2>> John </FONT> <BR><FONT SIZE=3D2>> John C. Strassner </FONT> <BR><FONT SIZE=3D2>> Chief Strategy Officer </FONT> <BR><FONT SIZE=3D2>> Intelliden Inc. </FONT> <BR><FONT SIZE=3D2>> 90 South Cascade Avenue </FONT> <BR><FONT SIZE=3D2>> Colorado Springs, CO 80906 USA = </FONT> <BR><FONT SIZE=3D2>> phone: +1.719.785.0648 </FONT> <BR><FONT SIZE=3D2>> fax: = +1.719.785.0644 </FONT> <BR><FONT SIZE=3D2>> email: = [email protected]</FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C41338.D64096F0--