RE: FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt
John Strassner <[email protected]> Fri, 13 Feb 2004 19:31:48 -0700
| 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_01C3F2A2.B26EDEA0
Content-Type: text/plain
First, I support Kurt's comments on LDAP, and will reply to those in a
separate email.
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.
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?
Fifth, why is there a pcelsRule and a pcimRule class?
Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point,
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.
Comments are as follows:
- s/RFC zzzz/RFC 3703
- 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.
- 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.
- 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!
- 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.
- 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.
- 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?).
- pages 8-11: your table has no caption
- pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They
aren't listed in this table, and better be, if you are "updating"
RFC 3703.
- 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?
- 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?
- 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".
- 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.
- 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).
- 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?
- Page 13, Section 4.3, second paragraph - s/deprecates/deprecate
- Page 13, Note - actually, PCLS does NOT have anything to do with
PCIMe, so this note needs to be reworded
- Page 14, Section 4.5
- s/an other/another (and other places)
- s/"rule /group"/"rule/group" (5 places) (and other places)
- Page 16, section 4.6,
- s/CompoundPolicyActionclasses/CompoundPolicyAction classes
- conditions /actions/"conditions/actions" (and other places)
- 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?
- Page 23 - the DESC for pcelsPolicySetList should say that it
contains an UNORDERED list of DN references.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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.
- Page 24, DESC of pcelsPolicySetDN should state that this is an
UNORDERED list of DNs.
- Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule
Class and Its Subclasses
<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?
- 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?
- 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.
- 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.
- 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.
- Page 27, section 5.4, again you say "pcelsRule" instead of "non-
abstract subclasses of pcelsRule".
- Page 28, top paragraph, another error that you are recommending
should be ignored
- 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
- Page 28, section 5.5, again you say "pcelsRule" instead of "non-
abstract subclasses of pcelsRule".
- Page 28, last paragraph, another error that you are recommending
should be ignored.
- 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
- Page 29, last paragraph above Section 5.6, another error that you are
recommending should be ignored.
- 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>
- Page 29, last paragraph above Section 5.6, another error that you are
recommending should be ignored.
- 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
- Page 30, the DESC for pcelsValueDN is wrong - it should be a subclass
of pcelsValueDN.
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]
<mailto:[email protected]>
------_=_NextPart_001_01C3F2A2.B26EDEA0
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>First, I support Kurt's comments on LDAP, and will reply to those in a
separate email.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>Second, I list below a set of additional comments on this
draft.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>Fourth, a cursory scan revealed that there is no pc</FONT></SPAN><SPAN
class=408553420-12022004><SPAN class=408553420-12022004><FONT face="Courier New"
color=#0000ff size=2>elsPolicyGroup class. This is strange, since PolicyGroup is
listed as a subclass of PolicySet in RFC 3460. Why is
this?</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><SPAN class=408553420-12022004><FONT
face="Courier New" color=#0000ff size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><SPAN class=408553420-12022004><FONT
face="Courier New" color=#0000ff size=2>Fifth, </FONT></SPAN></SPAN><SPAN
class=408553420-12022004><SPAN class=408553420-12022004><FONT face="Courier New"
color=#0000ff size=2>why is there a pcelsRule and a pcimRule
class?</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><SPAN class=408553420-12022004><FONT
face="Courier New" color=#0000ff size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><SPAN class=408553420-12022004><FONT
face="Courier New" color=#0000ff size=2>Sixth, w</FONT></SPAN><SPAN
class=408553420-12022004><FONT face="Courier New" color=#0000ff size=2>hy is
there no pcelsRuleValidityAssociation subclass? At this point, 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).</FONT></SPAN></DIV>
<DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV><!-- Converted from text/rtf format --></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>Comments are as follows:</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - s/RFC zzzz/RFC 3703</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 3. You write: "...the combined class hierarchy for the LDAP
<BR> object classes defined in [PCLS] and in this document".
You should<BR> include concepts from 3460 that you mapped into
new classes, and<BR> add that you defined new classes not in
3460 or 3703.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 4-7, class diagram - this diagram has no caption. Please
add<BR> one. In addition, I find the diagram inpenetrable, in
that the<BR> reader has no idea where these classes came from.
I think you need<BR> a simpler introduction saying 3060
provided this, 3460 did this, and<BR> thus we came up with
this. Take this key and show, for any class </FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> that isn't new in this document, where it came
from.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 4 - why is your class named pcelsFilerEntry, when 3460
names<BR> its class FilterEntryBase?</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 4 - why is your class named pcelsIPHeaders, when 3460
names<BR> its class IPHeadersFilter? The Filter part is
important!
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 4 - why is your class named pcels8021Headers, when 3460
names<BR> its class 8021Filter? The Filter part is
important!</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> - page 4 - why is your class named pcelsCompoundFilterAuxClass,
when <BR> a more consistent name would be
pcelsCompoundFilterConditionAuxClass?</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2> The Condition part is important!</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - general reflections on the class
diagram: part of the problem is that<BR> you are building a
schema from three different sources: (1) RFC 3703,<BR> (2) RFC
3460, and (3) your own additions. I see no discussion on how</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> these relate to each
other, which would have been helpful.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - page 7 - you didn't state whether
this is for all associations. This<BR> is exacerbated by
you saying: "...might need to implement the <BR>
association..." - which implies a single association. In
addition,<BR> this is a terse description - the naive reader
won't understand why<BR> aux classes are being used - you need
a reference or a couple of<BR> sentences explaining
this.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - page 7 - you state: "The LDAP
object classes defined in this document<BR> are a direct
mapping from the corresponding classes and, in some <BR>
cases, the associations defined in [PCIM_EXT] ". Not strictly true,
<BR> as you are also seeking to update RFC 3703 (e.g., where
is <BR> pcimSubtreesPtrAuxClass defined in RFC
3460?).</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - pages 8-11: your table has no
caption</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - pages 8-11: Where are classes like
pcimSubtreesPtrAuxClass? They</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> aren't listed in this
table, and better be, if you are "updating"<BR> RFC
3703.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - once again, I see lots of irksome
naming issues. The LDAP schema<BR> shouldn't change the name
of a class defined in another RFC. Why<BR> have you done
this?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - page 8, 4th row. How can you give
two different mappings to a single<BR> object class? And how
can a RULE (i.e., pcelsRule) map to a GROUP?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - page 10, 1st row. How can a single
info model association map to<BR> two different associations?
And do you mean "and" in this row? This<BR> would mean that I
would have to instantiate both pcelsPolicySet</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> and
pcelsPolicySetAssociation, which is clearly wrong. This
comment<BR> also applies for the other rows on this page where
you have "and".</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - page 10 - it is of no help to say
"see PolicySetInSystem" in this<BR> table for the 3rd and 4th
rows - that only confuses the reader.<BR> Please spell out
what you mean here.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 11 - the reader will wonder
why ReusablePolicy and <BR> PolicyRoleCollectionInSystem are
only implementable via DIT <BR> containment, when every other
association has an association defined<BR> (independent of
whether DIT containment could be used).</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Section 4.2, line 3, you write:
"The concept of an ordered set of<BR> policies...". LDAP
doesn't have ordered sets. How are you going to<BR> implement
this?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 13, Section 4.3, second
paragraph - s/deprecates/deprecate</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 13, Note - actually, PCLS does
NOT have anything to do with<BR> PCIMe, so this note needs to
be reworded</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 14</SPAN><SPAN
class=408553420-12022004>, Section 4.5</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - s/an other/another (and
other places)</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - s/"rule
/group"/"rule/group" (5 places) (and other places)</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 16, section 4.6,
<BR> - s/CompoundPolicyActionclasses/CompoundPolicyAction
classes </SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - conditions
/actions/"conditions/actions" (and other places)</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 22. How are you going to
enforce an "ordered set of <BR> rules /groups"? That is, how
can you guarantee that the DSA stores</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> your rules/groups [sic]
in the order that you want, and where is</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> that order specified?
What if a DSA doesn't have ordering controls?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Same section as above - you say
that the "association entries enable <BR> relative ordering of
the aggregated pcelsPolicySet instances within <BR> the scope
of the aggregating pcelsPolicySet" - how is this </SPAN></DIV>
<DIV><SPAN class=408553420-12022004> accomplished with a
plain, vanilla LDAP server with no controls?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 23 - the DESC for
pcelsPolicySetList should say that it</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> contains an UNORDERED
list of DN references.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 23, note above Section 5.2, is
slightly incorrect. Only those</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> implementations that WANT
TO BE COMPATIBLE WITH PCELS should use</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> this aggregation
mechanism instead of those defined by PCLS. Not</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> every implementation
mechanism is going to want to change.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 23, Section 5.2, says "The
pcelsPolicySetAssociation class is <BR> used to aggregate
instances of pcelsPolicySet into other entries."</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> This is incorrect, as
pcelsPolicySet is abstract and thus cannot be</SPAN></DIV>
<DIV><SPAN class=408553420-12022004>
instantiated.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Same section, you write:
"...realizes a (subclass of)<BR> PolicySetComponent
aggregation [sic]. When subordinated to (subclass <BR> of)
dlm1System...realizes a PolicySetInSystem association
[sic]".<BR> How can the same element realize an aggregation in
one usage and an</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> association in another
usage? This is semantically inconsistent.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Next paragraph says: "A
non-reusable instance of (subclass of)<BR> pcelsPolicySet is
attached as auxiliary class directly to the <BR>
pcelsPolicySetAssociation entry." Subclasses of pcelsPolicySet
that<BR> are not abstract are pcelsRuleAuxClass and
pcelsRuleInstance. The<BR> </SPAN><SPAN
class=408553420-12022004> above sentence only makes sense for
pcelsRuleAuxClass.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Next paragraph doesn't make sense.
First, you clearly mean a non-<BR> abstract subclass of
pcelsPolicySet. Second, you are recommending</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> that an ERROR be ignored?
Why don't you stop operation?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 24, DESC of pcelsPriority is
insufficient, as "0" has special<BR> semantics that you
haven't mentioned. This should, of course, also</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> be present in
accompanying prose, as Kurt points out.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 24, DESC of pcelsPolicySetDN
should state that this is an<BR> UNORDERED list of
DNs.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 24, Section 5.3, s/The Three
Classes pcelsRule/The pcelsRule<BR> Class and Its
Subclasses</SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000><note: at this point
I'm not going to correct any remaining grammar</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000> errors, such as
the next line ("The pcelsRule is...") because there</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000> are too many of
them.></FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004>
<DIV><SPAN class=408553420-12022004> - Page 24, Section 5.3, you say: "The
pcelsRule is the base class<BR> representing policy
rules." Does this mean that an implementation</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> can NOT use the
subclasses of pcimRule anymore?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 24, next paragraph, you say:
"This class shares the <BR> Condition/Action aggregation
methods with the<BR> pcelsCompoundConditionAuxClass and
pcelsCompoundActionAuxClass<BR> object classes.". Why does it
also not share the<BR> pcelsSimpleConditionAuxClass and
pcelsSimpleActionAuxClass<BR> object classes as
well?</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 25, top paragraph, again says
that the implementer should ignore<BR> an error condition.
This isn't a good idea.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 25, next paragraph has the
same problem.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 26, the pcelsConditionListType
attribute has a constraint. No</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> text is provided that
instructs the implementer what to do, aside</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> from Note 5 on page 21,
which says: "Text has been added to instruct<BR> servers
and applications what to do if a value outside of this
range<BR> is encountered" - which is exactly the problem
- no text is here.<BR><FONT color=#000000>Note that this is a systemic problem
with any constrained attribute</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000>defined in this draft.
Thus, I will only mention this once.</FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 27, WHY isn't a PolicyGroup
class implemented? You give no</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> reason for not doing
this. Note also that Note 2 talks about ORDERED</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> policy rules - I don't
see how you can construct those.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 27, section 5.4, again you say
"pcelsRule" instead of "non-<BR> abstract subclasses of
pcelsRule".</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 28, top paragraph, another
error that you are recommending </SPAN></DIV>
<DIV><SPAN class=408553420-12022004> should be
ignored</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 28, DESC for
pcelsConditionAssociation is wrong; you say that</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> it can be used for a
pcelsRule instead of a non-abstract subclass of</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> pcelsRule</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 28, section 5.5, again you say
"pcelsRule" instead of "non-<BR> abstract subclasses of
pcelsRule".</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 28, last paragraph, another
error that you are recommending</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> should be
ignored.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 29, DESC for
pcelsActionAssociation is wrong; you say that
<DIV><SPAN class=408553420-12022004> it can be used for a
pcelsRule instead of a non-abstract subclass of</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> pcelsRule</SPAN></DIV>
<DIV><SPAN class=408553420-12022004>
<DIV><SPAN class=408553420-12022004> - Page 29, last paragraph above
Section 5.6, another error that you are<BR>
recommending</SPAN><SPAN class=408553420-12022004> should be
ignored.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> - Page 29, Section 5.6, last two
paragraphs are errors that you are</SPAN></DIV>
<DIV><SPAN class=408553420-12022004> recommending should be
ignored.</SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000><At this point, I'm
going to stop listing these, as it is a systemic problem that should be fixed in
the next release></FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT color=#000000>
<DIV><FONT color=#0000ff><SPAN class=408553420-12022004> - Page 29, last
paragraph above Section 5.6, another error that you are<BR>
recommending</SPAN><SPAN class=408553420-12022004> should be
ignored.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=408553420-12022004> - Page 30, the
DESC for pcelsVariableDN is wrong. You say that it is a<BR>
"DN reference to a pcelsVariable entry", when it should be a
DN</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=408553420-12022004>
reference to a subclass of either pcelsExplicitVariableAuxClass
or<BR> pcelsImplicitVariableAuxClass or
pcelsVendorVariableAuxClass</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=408553420-12022004> - Page 30, the
DESC for pcelsValueDN is wrong - it should be a subclass</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff><SPAN class=408553420-12022004> of
pcelsValueDN.</SPAN></FONT></DIV></FONT></SPAN></DIV>
<DIV><SPAN class=408553420-12022004><FONT
color=#000000></FONT></SPAN> </DIV></SPAN></SPAN></SPAN><SPAN
class=408553420-12022004><FONT color=#000000></FONT></SPAN></DIV></DIV></DIV>
<DIV><SPAN class=408553420-12022004><FONT
color=#000000></FONT></SPAN> </DIV></SPAN></FONT></SPAN></FONT></SPAN><SPAN
class=408553420-12022004><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN></DIV></DIV></DIV>
<P><FONT face="Times New Roman">regards,<BR>John</FONT> </P>
<P><FONT face="Times New Roman">John C. Strassner</FONT> <BR><FONT
face="Times New Roman">Chief Strategy Officer</FONT> <BR><FONT
face="Times New Roman">Intelliden Inc.</FONT> <BR><FONT
face="Times New Roman">90 South Cascade Avenue</FONT> <BR><FONT
face="Times New Roman">Colorado Springs, CO 80906 USA</FONT>
<BR><FONT face="Times New Roman">phone: +1.719.785.0648</FONT> <BR><FONT
face="Times New Roman"> fax:
+1.719.785.0644</FONT> <BR><FONT face="Times New Roman">email:
<A
href="mailto:[email protected]">[email protected]</A></FONT></P></BODY></HTML>
------_=_NextPart_001_01C3F2A2.B26EDEA0--