Part2: RE: [Policy] FW: I-D = ACTION:draft-reyes-policy-core-ext-schema-04 .txt

From exim@www1.ietf.org Fri Mar 26 08:57:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20183 for ; Fri, 26 Mar 2004 08:57:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rpk-0005Sl-Ei for policy-archive@odin.ietf.org; Fri, 26 Mar 2004 08:57:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QDvG5E020987 for policy-archive@odin.ietf.org; Fri, 26 Mar 2004 08:57:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rpV-0005RT-66; Fri, 26 Mar 2004 08:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6roi-0005QO-7N for policy@optimus.ietf.org; Fri, 26 Mar 2004 08:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20167 for ; Fri, 26 Mar 2004 08:56:09 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6rog-0005cL-00 for policy@ietf.org; Fri, 26 Mar 2004 08:56:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6rns-0005Wy-00 for policy@ietf.org; Fri, 26 Mar 2004 08:55:24 -0500 Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B6rnF-0005Pc-00 for policy@ietf.org; Fri, 26 Mar 2004 08:54:41 -0500 Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 07:54:42 -0600 Message-ID: To: policy@ietf.org Subject: Part2: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-sc hema-04 .txt Date: Fri, 26 Mar 2004 07:47:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41338.D64096F0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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'; 'policy@ietf.org' > 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 > . > > Thank You, > Mircea. > > -----Original Message----- > From: John Strassner [mailto:John.Strassner@intelliden.com] > Sent: Friday, February 13, 2004 9:32 PM > To: 'mpana@metasolv.com'; 'policy@ietf.org' > 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) > Fixed. > > > - 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? > Text revised and note added to indicate that > applications must not expect the LDAP data store to implement > sorting and ordering. > > > - Page 23 - the DESC for pcelsPolicySetList should say that it > contains an UNORDERED list of DN references. > Fixed. > > > - 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. > 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." > > > > - 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. > I fail to see a problem with "instance of > ". It is obvious that it means "instance of > non-abstract subclass of ". 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. > > > - 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. > I fail to see the issue. The semantics of > pcelsPolicySetAssociation are context sensitive. > > > - 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. > The new specification will include pcelsGroup as > well. As result, the current text will make more sense. > > > - 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? > 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. > > > - 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. > 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? > > > - Page 24, DESC of pcelsPolicySetDN should state that this is an > UNORDERED list of DNs. > Fixed. > > > - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule > Class and Its Subclasses > Fixed. > > > 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? > I fail to see the issue. > > > - 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? > 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." > > > - 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. > Already discussed > > > - 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. > All Fixed. > > > - 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. > Already discussed > > > - Page 27, section 5.4, again you say "pcelsRule" instead of "non- > abstract subclasses of pcelsRule". > Already discussed > > > - Page 28, top paragraph, another error that you are recommending > should be ignored > Already discussed > > > - 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 > Already discussed > > > - Page 28, section 5.5, again you say "pcelsRule" instead of "non- > abstract subclasses of pcelsRule". > Already discussed > > > - Page 28, last paragraph, another error that you are recommending > should be ignored. > Already discussed > > > - 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 > Already discussed > > > - Page 29, last paragraph above Section 5.6, another error > that you are > recommending should be ignored. > Already discussed > > > - Page 29, Section 5.6, last two paragraphs are errors that you are > recommending should be ignored. > systemic problem that should be fixed in the next release> > Already discussed > > > - Page 29, last paragraph above Section 5.6, another error > that you are > recommending should be ignored. > Already discussed > > > - 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 > Already discussed > > > - Page 30, the DESC for pcelsValueDN is wrong - it should > be a subclass > of pcelsValueDN. > Already discussed > > > > > 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: john.strassner@intelliden.com > ------_=_NextPart_001_01C41338.D64096F0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Part2: RE: [Policy] FW: I-D = ACTION:draft-reyes-policy-core-ext-schema-04 .txt

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

[...]
(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:    = john.strassner@intelliden.com
>

------_=_NextPart_001_01C41338.D64096F0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Mar 26 09:43:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20184 for ; Fri, 26 Mar 2004 08:57:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rpk-0005Si-Dj for policy-archive@odin.ietf.org; Fri, 26 Mar 2004 08:57:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2QDvGsj020986 for policy-archive@odin.ietf.org; Fri, 26 Mar 2004 08:57:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rpU-0005RI-MG; Fri, 26 Mar 2004 08:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6rog-0005QJ-PN for policy@optimus.ietf.org; Fri, 26 Mar 2004 08:56:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20161 for ; Fri, 26 Mar 2004 08:56:08 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6rof-0005cB-00 for policy@ietf.org; Fri, 26 Mar 2004 08:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6rnp-0005Wh-00 for policy@ietf.org; Fri, 26 Mar 2004 08:55:20 -0500 Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B6rmu-0005K5-00 for policy@ietf.org; Fri, 26 Mar 2004 08:54:20 -0500 Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Mar 2004 07:54:18 -0600 Message-ID: To: policy@ietf.org Subject: Part1: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-sc hema-04 .txt Date: Fri, 26 Mar 2004 07:46:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41338.C92AD3E0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C41338.C92AD3E0 Content-Type: text/plain; charset="ISO-8859-1" my message has exceeded the 40 k limit. see below part1 > -----Original Message----- > From: Pana, Mircea > Sent: Thursday, March 25, 2004 9:59 PM > To: 'John Strassner'; 'policy@ietf.org' > 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 > . > > Thank You, > Mircea. > > -----Original Message----- > From: John Strassner [mailto:John.Strassner@intelliden.com] > Sent: Friday, February 13, 2004 9:32 PM > To: 'mpana@metasolv.com'; 'policy@ietf.org' > Subject: RE: [Policy] FW: I-D > ACTION:draft-reyes-policy-core-ext-schema-04 .txt > > > First, I support Kurt's comments on LDAP, and will reply to > those in a separate email. > Kurt's recommendations will be addressed in the next revision. > > > 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. > Can you be more specific. The document includes > several diagrams and tables. What is it missing? > > > 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? > pcelsGroup will be added in the new revision. > > > Fifth, why is there a pcelsRule and a pcimRule class? > I do not understand the issue. > > > Sixth, why is there no pcelsRuleValidityAssociation subclass? > At this point, I do not understand the issue. PCELS > reuses pcimRuleValidityAssociation that is defined in PCLS > > > 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. > Acknowledgments will be added in the new revision. > > > Comments are as follows: > > - s/RFC zzzz/RFC 3703 > Fixed. > > > - 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. > Fixed. > > > - 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. > Fixed. > > > - 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! > All renamed. > > > - 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. > The new revision will indicate all these sources explicitly. > > > - 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. > 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." > > > - 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?). > The text in section 4.1 will be revised for a better > description of the mapping techniques utilised by PCELS. > However, I do not understand > your reference to pcimSubtreesPtrAuxClass. That class is not > defined in PCELS. > > > - pages 8-11: your table has no caption > Fixed. > > > - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They > aren't listed in this table, and better be, if you are "updating" > RFC 3703. > The two tables list PCIM_EXT classes mapped by PCELS. > Why should the tables include PCLS classes? > > > - 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? > 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. > > > - 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? > pcelsGroup will be added in the new revision. > > > - 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". > ...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. > > > - 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. > Fixed. Details are in section 5. > > > - 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). > I fail to see the issue. > > > - 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? > replaced "ordered" with "coherent" (from PCIM_EXT) > > > - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate > Fixed. > > > - Page 13, Note - actually, PCLS does NOT have anything to do with > PCIMe, so this note needs to be reworded > Fixed. > > > - Page 14, Section 4.5 > - s/an other/another (and other places) > - s/"rule /group"/"rule/group" (5 places) (and other places) > Fixed. > > > (to continue...) ------_=_NextPart_001_01C41338.C92AD3E0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Part1: RE: [Policy] FW: I-D = ACTION:draft-reyes-policy-core-ext-schema-04 .txt

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

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

------_=_NextPart_001_01C41338.C92AD3E0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sat Mar 27 13:31:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24385 for ; Sat, 27 Mar 2004 13:31:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7IaM-0003NZ-AQ for policy-archive@odin.ietf.org; Sat, 27 Mar 2004 13:31:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2RIVATK012988 for policy-archive@odin.ietf.org; Sat, 27 Mar 2004 13:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7IaE-0003Mi-4e; Sat, 27 Mar 2004 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hiE-000496-UY for policy@optimus.ietf.org; Thu, 25 Mar 2004 22:08:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11388 for ; Thu, 25 Mar 2004 22:08:47 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hiB-0003HP-00 for policy@ietf.org; Thu, 25 Mar 2004 22:08:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hhB-00039K-00 for policy@ietf.org; Thu, 25 Mar 2004 22:07:50 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B6hgX-00031k-00 for policy@ietf.org; Thu, 25 Mar 2004 22:07:05 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Mar 2004 21:05:56 -0600 Message-ID: To: John.Strassner@intelliden.com, policy@ietf.org Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt Date: Thu, 25 Mar 2004 20:59:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C412DE.5A872524" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C412DE.5A872524 Content-Type: text/plain; charset="iso-8859-1" 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 . Thank You, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Friday, February 13, 2004 9:32 PM To: 'mpana@metasolv.com'; 'policy@ietf.org' Subject: RE: [Policy] FW: I-D ACTION:draft-reyes-policy-core-ext-schema-04 .txt First, I support Kurt's comments on LDAP, and will reply to those in a separate email. Kurt's recommendations will be addressed in the next revision. 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. Can you be more specific. The document includes several diagrams and tables. What is it missing? 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? pcelsGroup will be added in the new revision. Fifth, why is there a pcelsRule and a pcimRule class? I do not understand the issue. Sixth, why is there no pcelsRuleValidityAssociation subclass? At this point, I do not understand the issue. PCELS reuses pcimRuleValidityAssociation that is defined in PCLS 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. Acknowledgments will be added in the new revision. Comments are as follows: - s/RFC zzzz/RFC 3703 Fixed. - 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. Fixed. - 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. Fixed. - 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! All renamed. - 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. The new revision will indicate all these sources explicitly. - 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. 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." - 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?). The text in section 4.1 will be revised for a better description of the mapping techniques utilised by PCELS. However, I do not understand your reference to pcimSubtreesPtrAuxClass. That class is not defined in PCELS. - pages 8-11: your table has no caption Fixed. - pages 8-11: Where are classes like pcimSubtreesPtrAuxClass? They aren't listed in this table, and better be, if you are "updating" RFC 3703. The two tables list PCIM_EXT classes mapped by PCELS. Why should the tables include PCLS classes? - 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? 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. - 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? pcelsGroup will be added in the new revision. - 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". ...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. - 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. Fixed. Details are in section 5. - 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). I fail to see the issue. - 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? replaced "ordered" with "coherent" (from PCIM_EXT) - Page 13, Section 4.3, second paragraph - s/deprecates/deprecate Fixed. - Page 13, Note - actually, PCLS does NOT have anything to do with PCIMe, so this note needs to be reworded Fixed. - Page 14, Section 4.5 - s/an other/another (and other places) - s/"rule /group"/"rule/group" (5 places) (and other places) Fixed. - Page 16, section 4.6, - s/CompoundPolicyActionclasses/CompoundPolicyAction classes - conditions /actions/"conditions/actions" (and other places) Fixed. - 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? Text revised and note added to indicate that applications must not expect the LDAP data store to implement sorting and ordering. - Page 23 - the DESC for pcelsPolicySetList should say that it contains an UNORDERED list of DN references. Fixed. - 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. 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." - 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. I fail to see a problem with "instance of ". It is obvious that it means "instance of non-abstract subclass of ". 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. - 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. I fail to see the issue. The semantics of pcelsPolicySetAssociation are context sensitive. - 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. The new specification will include pcelsGroup as well. As result, the current text will make more sense. - 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? 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. - 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. 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? - Page 24, DESC of pcelsPolicySetDN should state that this is an UNORDERED list of DNs. Fixed. - Page 24, Section 5.3, s/The Three Classes pcelsRule/The pcelsRule Class and Its Subclasses Fixed. - 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? I fail to see the issue. - 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? 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." - 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. Already discussed - 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. All Fixed. - 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. Already discussed - Page 27, section 5.4, again you say "pcelsRule" instead of "non- abstract subclasses of pcelsRule". Already discussed - Page 28, top paragraph, another error that you are recommending should be ignored Already discussed - 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 Already discussed - Page 28, section 5.5, again you say "pcelsRule" instead of "non- abstract subclasses of pcelsRule". Already discussed - Page 28, last paragraph, another error that you are recommending should be ignored. Already discussed - 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 Already discussed - Page 29, last paragraph above Section 5.6, another error that you are recommending should be ignored. Already discussed - Page 29, Section 5.6, last two paragraphs are errors that you are recommending should be ignored. Already discussed - Page 29, last paragraph above Section 5.6, another error that you are recommending should be ignored. Already discussed - 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 Already discussed - Page 30, the DESC for pcelsValueDN is wrong - it should be a subclass of pcelsValueDN. Already discussed 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: john.strassner@intelliden.com ------_=_NextPart_001_01C412DE.5A872524 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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:John.Strassner@inte= lliden.com]
Sent: Friday, February 13, 2004 9:32 PM
To: 'mpana@metasolv.com'; 'policy@ietf.org'
Subject: RE: [Policy] FW: I-D = ACTION:draft-reyes-policy-core-ext-schema-04 .txt

First, I support Kurt's comments on LDAP, and will = reply to those in a separate email.
<mircea>Kurt's recommendations will be = addressed in the next revision.
</mircea>

Second, I list below a set of additional comments on = this draft.

Third, the lack of an overall diagram makes it very = difficult to evaluate the correctness of this model. This draft is not = complete enough to construct such a model.

<mircea>Can you be more specific. The document = includes several diagrams and tables. What is it missing?
</mircea>

Fourth, a cursory scan revealed that there is no = pcelsPolicyGroup class. This is strange, since PolicyGroup is listed as = a subclass of PolicySet in RFC 3460. Why is this?

<mircea>pcelsGroup will be added in the new = revision.
</mircea>

Fifth, why is there a pcelsRule and a pcimRule = class?
<mircea>I do not understand the issue.
</mircea>

Sixth, why is there no pcelsRuleValidityAssociation = subclass? At this point, <mircea>I do not understand the issue. = PCELS reuses pcimRuleValidityAssociation that is defined in = PCLS

</mircea>

I started to go through the document in detail with = my developers to try and implement it. We couldn't. We give you = inconsistencies that we noticed (grammatical and otherwise) through = page 31).

Finally, I was surprised to see a lack of an = Acknowledgments section, especially given the amount of feedback that = several people on this list gave the authors. That's in poor = form.

<mircea>Acknowledgments will be added in the = new revision.
</mircea>

Comments are as follows:

- s/RFC zzzz/RFC 3703
<mircea>Fixed.
</mircea>

- page 3. You write: "...the combined = class hierarchy for the LDAP
    object classes defined in [PCLS] = and in this document". You should
    include concepts from 3460 that = you mapped into new classes, and
    add that you defined new classes = not in 3460 or 3703.
<mircea>Fixed.
</mircea>

- page 4-7, class diagram - this diagram has = no caption. Please add
    one. In addition, I find the = diagram inpenetrable, in that the
    reader has no idea where these = classes came from. I think you need
    a simpler introduction saying = 3060 provided this, 3460 did this, and
    thus we came up with this. Take = this key and show, for any class
    that isn't new in this document, = where it came from.
<mircea>Fixed.
</mircea>

- page 4 - why is your class named = pcelsFilerEntry, when 3460 names
    its class FilterEntryBase?
- page 4 - why is your class named = pcelsIPHeaders, when 3460 names
    its class IPHeadersFilter? The = Filter part is important!
- page 4 - why is your class named = pcels8021Headers, when 3460 names
    its class 8021Filter? The Filter = part is important!
- page 4 - why is your class named = pcelsCompoundFilterAuxClass, when
    a more consistent name would be = pcelsCompoundFilterConditionAuxClass?
    The Condition part is = important!
<mircea>All renamed.
</mircea>

   - general reflections on the class = diagram: part of the problem is that
    you are building a schema from = three different sources: (1) RFC 3703,
    (2) RFC 3460, and (3) your own = additions. I see no discussion on how
    these relate to each other, which = would have been helpful.
<mircea>The new revision will indicate all = these sources explicitly.
</mircea>

   - page 7 - you didn't state whether this = is for all associations. This
    is exacerbated by you saying: = "...might need to implement the
    association..." - which = implies a single association. In addition,
    this is a terse description - the = naive reader won't understand why
    aux classes are being used - you = need a reference or a couple of
    sentences explaining this.
<mircea>Added example in support of the = generic text. Please note that the reader is not going to be that = naive. Section 2. ("Relationship to other Policy Framework = Documents") will also indicate that "These three documents = ([PCIM], [PCIM_EXT] and [PCLS]) are a prerequisite for reading and = understanding this document."

</mircea>

- page 7 - you state: "The LDAP object = classes defined in this document
    are a direct mapping from the = corresponding classes and, in some
    cases, the associations defined = in [PCIM_EXT] ". Not strictly true,
    as you are also seeking to update = RFC 3703 (e.g., where is
    pcimSubtreesPtrAuxClass defined = in RFC 3460?).
<mircea>The text in section 4.1 will be = revised for a better description of the mapping techniques utilised by = PCELS. However, I do not understand

your reference to pcimSubtreesPtrAuxClass. That class = is not defined in PCELS.
<mircea>

- pages 8-11: your table has no caption
<mircea>Fixed.
</mircea>

- pages 8-11: Where are classes like = pcimSubtreesPtrAuxClass? They
aren't listed in this table, and = better be, if you are "updating"
RFC 3703.
<mircea>The two tables list PCIM_EXT classes = mapped by PCELS. Why should the tables include PCLS classes?
</mircea>

- once again, I see lots of irksome naming = issues. The LDAP schema
shouldn't change the name of a = class defined in another RFC. Why
have you done this?
<mircea>All are going to be renamed to follow = the *exact* PCIM_EXT names, but I fail to see where is the problem with = the old names.

</mircea>

- page 8, 4th row. How can you give two = different mappings to a single
object class? And how can a RULE = (i.e., pcelsRule) map to a GROUP?
<mircea>pcelsGroup will be added in the new = revision.
</mircea>

- page 10, 1st row. How can a single info = model association map to
    two different associations? And = do you mean "and" in this row? This
    would mean that I would have to = instantiate both pcelsPolicySet
    and pcelsPolicySetAssociation, = which is clearly wrong. This comment
    also applies for the other rows = on this page where you have "and".
<mircea> ...means that the PolicySetComponent = aggregation is realised by a pcelsPolicySetComponentList value in the = aggregating pcelsPolicySet. This attribute value is a DN reference to a = pcelsPolicySetAsociation entry. The pcelsPolicySetAsociation entry = includes a pcelsPolicySetDN attribute value that is a reference to the = aggregated pcelsPolicySet. The details are in section 5. The table only = gives an overview of the mapping.

</mircea>

- page 10 - it is of no help to say "see = PolicySetInSystem" in this
table for the 3rd and 4th rows - = that only confuses the reader.
Please spell out what you mean = here.
<mircea>Fixed. Details are in section = 5.
</mircea>

- Page 11 - the reader will wonder why = ReusablePolicy and
    PolicyRoleCollectionInSystem are = only implementable via DIT
    containment, when every other = association has an association defined
    (independent of whether DIT = containment could be used).
<mircea>I fail to see the issue.
</mircea>

- Section 4.2, line 3, you write: "The = concept of an ordered set of
policies...". LDAP doesn't = have ordered sets. How are you going to
implement this?
<mircea>replaced "ordered" with = "coherent" (from PCIM_EXT)
</mircea>

- Page 13, Section 4.3, second paragraph - = s/deprecates/deprecate
<mircea>Fixed.
</mircea>

- Page 13, Note - actually, PCLS does NOT have = anything to do with
PCIMe, so this note needs to be = reworded
<mircea>Fixed.
</mircea>

- Page 14, Section 4.5
- s/an other/another (and other = places)
- s/"rule = /group"/"rule/group" (5 places) (and other = places)
<mircea>Fixed.
</mircea>

- 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: = john.strassner@intelliden.com

------_=_NextPart_001_01C412DE.5A872524-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Mar 30 18:59:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08734 for ; Tue, 30 Mar 2004 18:59:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ris-0006YH-Nr for policy-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFdA7Q002609 for policy-archive@odin.ietf.org; Sat, 20 Sep 2003 11:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jpF-0000fq-Mo; Sat, 20 Sep 2003 11:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ibl-0006f7-1Q for policy@optimus.ietf.org; Sat, 20 Sep 2003 10:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05270 for ; Fri, 19 Sep 2003 22:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0XmN-0005wT-00 for policy@ietf.org; Fri, 19 Sep 2003 22:47:23 -0400 Received: from sandvine.com ([199.243.201.138] helo=mail.sandvine.com ident=hidden-user) by ietf-mx with esmtp (Exim 4.12) id 1A0XmD-0005vm-00 for policy@ietf.org; Fri, 19 Sep 2003 22:47:13 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Sep 2003 22:46:53 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'John Strassner'" , David McTavish , "'Joel M. Halpern'" Date: Fri, 19 Sep 2003 22:46:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37F21.6ECFDB30" Subject: [Policy] RE: PCELS position Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C37F21.6ECFDB30 Content-Type: text/plain; charset="iso-8859-1" Opening the box a little further, is it still possible to provide feedback to PCIMe so that its original intent can be maintained, while preserving option #1? It seems that the work so far in PCELS is correct in relation to the PCIMe proposal, and perhaps the schema changes that we are debating should in fact be taken to a higher level. Is PCIMe considered so complete, that it is beyond modification, if such modification could preserve its intent while also adhering to the desires of maintaining consistency with PCIM and PCLS? d. -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Friday, September 19, 2003 5:34 PM To: 'policy@ietf.org' Cc: 'John Strassner'; 'David McTavish'; 'Joel M. Halpern' Subject: PCELS position After having read so many arguments on the position of PCELS relative to PCLS I've come to the conclusion that people wish PCELS to be either a fully interoperable extension of PCLS or a stand-alone policy schema. At the same time the main goal of PCELS was to implement PCIMe (as an increment of PCIM). Based on these facts, I can see three major options (and perhaps a lot of variations): 1. If PCELS ignores or alters some of the PCIMe recommendations, then it can be fully interoperable with PCLS. 2. For PCELS to be fully compliant with PCIMe it must at the minimum define replacement for a couple of the schema items defined by PCLS. 3. For PCELS to be fully compliant with PCIMe and stand-alone (i.e. no dependency on PCLS), it would need to redefine many (otherwise re-usable) PCLS schema items. So, my question to the group is: of the three options above, which one do you like the most (or find the easiest to live with)? Joel, is #1 a viable option? Thank you, Mircea. ------_=_NextPart_001_01C37F21.6ECFDB30 Content-Type: text/html; charset="iso-8859-1" PCELS position

Opening the box a little further, is it still possible to provide feedback to PCIMe so that its original intent can be maintained, while preserving option #1? It seems that the work so far in PCELS is correct in relation to the PCIMe proposal, and perhaps the schema changes that we are debating should in fact be taken to a higher level.

Is PCIMe considered so complete, that it is beyond modification, if such modification could preserve its intent while also adhering to the desires of maintaining consistency with PCIM and PCLS?

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Friday, September 19, 2003 5:34 PM
To: 'policy@ietf.org'
Cc: 'John Strassner'; 'David McTavish'; 'Joel M. Halpern'
Subject: PCELS position

After having read so many arguments on the position of PCELS relative to PCLS I've come to the conclusion that people wish PCELS to be either a fully interoperable extension of PCLS or a stand-alone policy schema. At the same time the main goal of PCELS was to implement PCIMe (as an increment of PCIM).

Based on these facts, I can see three major options (and perhaps a lot of variations):
1. If PCELS ignores or alters some of the PCIMe recommendations, then it can be fully interoperable with PCLS.
2. For PCELS to be fully compliant with PCIMe it must at the minimum define replacement for a couple of the schema items defined by PCLS.

3. For PCELS to be fully compliant with PCIMe and stand-alone (i.e. no dependency on PCLS), it would need to redefine many (otherwise re-usable) PCLS schema items.

So, my question to the group is: of the three options above, which one do you like the most (or find the easiest to live with)?

Joel, is #1 a viable option?

Thank you,
Mircea.

------_=_NextPart_001_01C37F21.6ECFDB30-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Mar 30 19:45:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12665 for ; Tue, 30 Mar 2004 19:45:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Tqu-0007lY-FR for policy-archive@odin.ietf.org; Tue, 30 Mar 2004 19:45:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V0j852029852 for policy-archive@odin.ietf.org; Tue, 30 Mar 2004 19:45:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Tqn-0007kK-DC; Tue, 30 Mar 2004 19:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Tpo-0007hS-Oe for policy@optimus.ietf.org; Tue, 30 Mar 2004 19:44:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12574 for ; Tue, 30 Mar 2004 19:43:58 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Tpn-0001bB-00 for policy@ietf.org; Tue, 30 Mar 2004 19:43:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Too-0001UV-00 for policy@ietf.org; Tue, 30 Mar 2004 19:42:59 -0500 Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Tnu-0001KN-00 for policy@ietf.org; Tue, 30 Mar 2004 19:42:02 -0500 Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 18:42:07 -0600 Message-ID: To: policy@ietf.org Cc: joel@stevecrocker.com Date: Tue, 30 Mar 2004 18:34:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416B7.E7750A50" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] PCELS-05 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C416B7.E7750A50 Content-Type: text/plain; charset="ISO-8859-1" We have just submitted a new revision of PCELS (it usually takes a couple of days for an I-D to be published). This revision includes changes that address (hopefully all) the issues raised by Kurt Zeilenga and John Strassner. All the "Open Issues" noted in the previous revision have also been closed and the necessary OID numbers under "IANA-ASSIGNED-OID" have been assigned. All the unnecessary sections appended at the end of the document in previous revisions (e.g. "Appendix A: Changes in this revision") have been removed. For the record, these sections will be posted as separate messages to this mailing list. Regards, Mircea. ------_=_NextPart_001_01C416B7.E7750A50 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable PCELS-05

We have just submitted a new revision of PCELS (it = usually takes a couple of days for an I-D to be published). This = revision includes changes that address (hopefully all) the issues = raised by Kurt Zeilenga and John Strassner. All the "Open = Issues" noted in the previous revision have also been closed and = the necessary OID numbers under "IANA-ASSIGNED-OID" have been = assigned.

All the unnecessary sections appended at the end of = the document in previous revisions (e.g. "Appendix A: Changes in = this revision") have been removed. For the record, these sections = will be posted as separate messages to this mailing list.

Regards,
Mircea.

------_=_NextPart_001_01C416B7.E7750A50-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Mar 30 19:46:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12721 for ; Tue, 30 Mar 2004 19:46:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Trk-0007rY-Vf for policy-archive@odin.ietf.org; Tue, 30 Mar 2004 19:46:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V0k0HT030193 for policy-archive@odin.ietf.org; Tue, 30 Mar 2004 19:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Trk-0007qp-P7; Tue, 30 Mar 2004 19:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Trg-0007pz-Tr for policy@optimus.ietf.org; Tue, 30 Mar 2004 19:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12702 for ; Tue, 30 Mar 2004 19:45:54 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Trf-0001mz-00 for policy@ietf.org; Tue, 30 Mar 2004 19:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Tqm-0001iZ-00 for policy@ietf.org; Tue, 30 Mar 2004 19:45:02 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Tq3-0001ZO-00 for policy@ietf.org; Tue, 30 Mar 2004 19:44:15 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 18:43:04 -0600 Message-ID: To: policy@ietf.org Date: Tue, 30 Mar 2004 18:36:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416B8.1B08A944" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] Changes in PCELS-05 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C416B8.1B08A944 Content-Type: text/plain; charset="iso-8859-1" Changes since -04 1. Added text to describe LDAP semantics for each class/attribute in sections 5.x. 2. Added text to describe class/attribute restrictions (where applicable) in section 5.x. 3. Revised Note 3 (on attribute matching rules) and Note 5 (on attribute constraints) in Section 5. 4. Added text to indicate what default attribute values (where applicable) in section 5.x. 5. Removed default value from pcelsPriority. A default value is not necessary since this attribute is only used as a MUST in pcelsPolicySetAssociation. 6. The term "list" referring to LDAP attribute values is replaced by the term "set" or "unordered set". The new term is a better choice for LDAP multi-value attributes (that are not ordered). Also added: "No order is implied." to the attribute type description. 7. Moved RFC2119 reference to Normative References. 8. Added Acknowledgements section. 9. Added pcimRepository subclasses that were missing from the class hierarchy in section 3. 10. pcelsImplicitVariableAuxClass MAY pcelsExpectedValueTypes (was MUST). 11. PCLS is now RFC3703. This document has been edited accordingly. 12. Added Policy Group classes. 13. Revised "Abstract" to include actual names of referenced documents. 14. Revised "1. Introduction". Added paragraph on new classes not covered by RFC 3460. 15. Revised section "2. Relationship to other Policy Framework Documents". 16. Revised text in section "3. Inheritance Hierarchy for PCELS" to indicate the source of these classes. 17. Added caption to figures and tables. 18. Renamed classes: pcelsFilterEntry renamed pcelsFilterEntryBase pcelsIPHeaders renamed pcelsIPHeadersFilter pcels8021Headers renamed pcels8021Filter pcelsCompoundFilterAuxClass renamed pcelsCompoundFilterConditionAuxClass 19. Revised section 4. paragraph 1. 20. Revised section 4.1. paragraph 1 and 2. 21. At the end of section 5.1 added note on ordering/sorting PolicySet components. 22. Revised notes regarding compatibility with PCIM_EXT at the end of sections 5.3 (PolicyGroup), 5.4 (PolicyRule) and 5.18 (ReusableContainer). Removed note on compatibility with PCIM_EXT from Section 5.1 (pcelsPolicySet). 23. Revised paragraphs referring to the precedence of the aux class attachment over DN the reference in sections describing pcelsPolicySetAsociation, pcelsConditionAssociation, pcelsActionAssociation, pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass. 24. Section 5.4 (pcelsRule) removed paragraph 2 regarding Condition/Action associations. Added replacement text in sections describing pcelsCompoundConditionAuxClass and pcelsCompoundActionAuxClass. 25. In sections 5.x that describe pcelsPolicySetAssociation, pcelsRule, pcelsConditionAssociation, pcelsActionAssociation, pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass, the paragraph(s) indicating cases when certain attributes must be ignored, have been revised. 26. Note 6 on "instances of " has been added in section 5. 27. Assigned all necessary numbers under IANA-ASSIGNED-OID ------_=_NextPart_001_01C416B8.1B08A944 Content-Type: text/html; charset="iso-8859-1" Changes in PCELS-05

Changes since -04

   1. Added text to describe LDAP semantics for each class/attribute
   in sections 5.x.

   2. Added text to describe class/attribute restrictions (where
   applicable) in section 5.x.

   3. Revised Note 3 (on attribute matching rules) and Note 5 (on
   attribute constraints) in Section 5.

   4. Added text to indicate what default attribute values (where
   applicable) in section 5.x.

   5. Removed default value from pcelsPriority. A default value is not
   necessary since this attribute is only used as a MUST in
   pcelsPolicySetAssociation.

   6. The term "list" referring to LDAP attribute values is replaced by
   the term "set" or "unordered set". The new term is a better choice
   for LDAP multi-value attributes (that are not ordered). Also added:
   "No order is implied." to the attribute type description.

   7. Moved RFC2119 reference to Normative References.

   8. Added Acknowledgements section.

   9. Added pcimRepository subclasses that were missing from the class
   hierarchy in section 3.

   10. pcelsImplicitVariableAuxClass MAY pcelsExpectedValueTypes
   (was MUST).

   11. PCLS is now RFC3703. This document has been edited accordingly.

   12. Added Policy Group classes.

   13. Revised "Abstract" to include actual names of referenced
   documents.

   14. Revised "1. Introduction". Added paragraph on new classes
   not covered by RFC 3460.

   15. Revised section "2. Relationship to other Policy Framework
   Documents".

   16. Revised text in section "3. Inheritance Hierarchy for PCELS"
   to indicate the source of these classes.

   17. Added caption to figures and tables.

   18. Renamed classes:
   pcelsFilterEntry renamed pcelsFilterEntryBase
   pcelsIPHeaders renamed pcelsIPHeadersFilter
   pcels8021Headers renamed pcels8021Filter
   pcelsCompoundFilterAuxClass renamed
               pcelsCompoundFilterConditionAuxClass

   19. Revised section 4. paragraph 1.

   20. Revised section 4.1. paragraph 1 and 2.

   21. At the end of section 5.1 added note on ordering/sorting
   PolicySet components.

   22. Revised notes regarding compatibility with PCIM_EXT at the end
   of sections 5.3 (PolicyGroup), 5.4 (PolicyRule) and 5.18
   (ReusableContainer). Removed note on
   compatibility with PCIM_EXT from Section 5.1 (pcelsPolicySet).

   23. Revised paragraphs referring to the precedence of the aux class
   attachment over DN the reference in sections describing
   pcelsPolicySetAsociation, pcelsConditionAssociation,
   pcelsActionAssociation, pcelsSimpleConditionAuxClass and
   pcelsSimpleActionAuxClass.

   24. Section 5.4 (pcelsRule) removed paragraph 2 regarding
   Condition/Action associations. Added replacement text in sections
   describing pcelsCompoundConditionAuxClass and
   pcelsCompoundActionAuxClass.

   25. In sections 5.x that describe pcelsPolicySetAssociation,
   pcelsRule, pcelsConditionAssociation, pcelsActionAssociation,
   pcelsSimpleConditionAuxClass and pcelsSimpleActionAuxClass,
   the paragraph(s) indicating cases when certain attributes must be
   ignored, have been revised.

   26. Note 6 on "instances of <abstract_class>" has been added in
   section 5.

   27. Assigned all necessary numbers under IANA-ASSIGNED-OID

------_=_NextPart_001_01C416B8.1B08A944-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Mar 31 09:51:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24759 for ; Wed, 31 Mar 2004 09:51:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h3N-0001TC-CD for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:50:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VEorLb005651 for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:50:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h2Z-0001IS-Ft; Wed, 31 Mar 2004 09:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h2R-0001HO-B3 for policy@optimus.ietf.org; Wed, 31 Mar 2004 09:49:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24698 for ; Wed, 31 Mar 2004 09:49:51 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8h2P-0002tF-00 for policy@ietf.org; Wed, 31 Mar 2004 09:49:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8h1d-0002pr-00 for policy@ietf.org; Wed, 31 Mar 2004 09:49:06 -0500 Received: from mail.metasolv.com ([216.30.145.7] helo=srvplemail1.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B8h0r-0002jq-00 for policy@ietf.org; Wed, 31 Mar 2004 09:48:17 -0500 Received: by srvplemail1.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 08:47:00 -0600 Message-ID: To: policy@ietf.org Date: Wed, 31 Mar 2004 08:40:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4172E.1E83A076" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] For the record: Changes in PCELS-04 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C4172E.1E83A076 Content-Type: text/plain; charset="iso-8859-1" The following section was included in the previous revision of PCELS but it has been removed in the current (-05) revision. For the record, these are the changes in PCELS-04 since PCELS-03: Changes since -03 1. This revision does not deprecate schema items defined in PCLS. The "Abstract" of this document has been modified accordingly. 2. To make them easily distinguishable from the object classes and attributes defined in PCLS, the schema items defined in this document are now prefixed "pcels" instead of "pcim". 3. In previous versions of this document the pcimPolicyGroup object class (initially defined by PCLS) was redefined as a subclass of pcimPolicySet (now pcelsPolicySet). This modification has been abandoned. 4. Added note on PolicyGroup representation as pcelsRule or pcelsPolicySet. 5. Abandoned deprecation of pcimRepository and modified pcelsReusableContainer to subclass pcimRepository. 6. Added general considerations in the opening of the schema definitions (section 5). 7. Added text to clarify which attributes defined in PCLS are also used in object classes defined here. 8. Instead of deprecating pcimRuleConditionAssociation and replacing it with pcelsConditionAssociation, the latter object class has been modified, so that is now a subclass of pcimRuleConditionAssociation which is no longer deprecated. 9. Instead of deprecating pcimRuleActionAssociation and replacing it with pcelsActionAssociation, the latter object class has been modified, so that is now a subclass of pcimRuleActionAssociation which is no longer deprecated. 10. The class pcimRule and its subclasses defined by PCLS are no longer deprecated. A note has been added to clarify the issue regarding the functionality replacement for compatibility with PCIM_EXT. 11. The pcimGroupContainmentAuxClass and pcimRuleContainmentAuxClass object classes defined by PCLS are no longer deprecated. A note has been added to clarify the issue regarding the functionality replacement for compatibility with PCIM_EXT. 12. Added text to explicitly describe the use of pcelsPolicySetAssociation for the realization of the PolicySetInSystem association. This was unclear in previous revisions. 13. Revised "Summary of changes since PCLS" in accordance with the changes listed above. 14. Revised security considerations. 15. Updated normative and informative references. 16. Added section to explain impact on PCLS implementations. 17. Added note on OID assignment status. (before section 1). 18. For compliance with NITS, the abstract does not use citations. 19. Added text to indicate valid and default attribute values where applicable. ------_=_NextPart_001_01C4172E.1E83A076 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For the record: Changes in PCELS-04

The following section was included in the previous = revision of PCELS but it has been removed in the current (-05) = revision. For the record, these are the changes in PCELS-04 since = PCELS-03:

Changes since -03

   1. This revision does not deprecate = schema items defined in PCLS.
   The "Abstract" of this = document has been modified accordingly.

   2. To make them easily distinguishable = from the object classes and
   attributes defined in PCLS, the schema = items defined in this document
   are now prefixed "pcels" = instead of "pcim".

   3. In previous versions of this = document the pcimPolicyGroup object
   class (initially defined by PCLS) was = redefined as a subclass of
   pcimPolicySet (now pcelsPolicySet). = This modification has been
   abandoned.

   4. Added note on PolicyGroup = representation as pcelsRule or
   pcelsPolicySet.

   5. Abandoned deprecation of = pcimRepository and modified
   pcelsReusableContainer to subclass = pcimRepository.

   6. Added general considerations in the = opening of the schema
   definitions (section 5).

   7. Added text to clarify which = attributes defined in PCLS are also
   used in object classes defined = here.

   8. Instead of deprecating = pcimRuleConditionAssociation and replacing
   it with pcelsConditionAssociation, the = latter object class has been
   modified, so that is now a subclass of = pcimRuleConditionAssociation
   which is no longer deprecated.

   9. Instead of deprecating = pcimRuleActionAssociation and replacing it
   with pcelsActionAssociation, the latter = object class has been
   modified, so that is now a subclass of = pcimRuleActionAssociation
   which is no longer deprecated.

   10. The class pcimRule and its = subclasses defined by PCLS are no
   longer deprecated. A note has been = added to clarify the issue
   regarding the functionality replacement = for compatibility with
   PCIM_EXT.

   11. The pcimGroupContainmentAuxClass and = pcimRuleContainmentAuxClass
   object classes defined by PCLS are no = longer deprecated. A note has
   been added to clarify the issue = regarding the functionality
   replacement for compatibility with = PCIM_EXT.

   12. Added text to explicitly describe = the use of
   pcelsPolicySetAssociation for the = realization of the
   PolicySetInSystem association. This was = unclear in previous
   revisions.

13. Revised "Summary of changes = since PCLS" in accordance with the
changes listed above.

14. Revised security = considerations.

15. Updated normative and informative = references.

16. Added section to explain impact on = PCLS implementations.

17. Added note on OID assignment status. = (before section 1).

18. For compliance with NITS, the = abstract does not use citations.

19. Added text to indicate valid and = default attribute values where
applicable.

------_=_NextPart_001_01C4172E.1E83A076-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Mar 31 09:54:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25007 for ; Wed, 31 Mar 2004 09:54:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h65-0001ia-Lt for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:53:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VErf1E006596 for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:53:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h5R-0001bg-Fq; Wed, 31 Mar 2004 09:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h4X-0001Zk-Ve for policy@optimus.ietf.org; Wed, 31 Mar 2004 09:52:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24800 for ; Wed, 31 Mar 2004 09:52:02 -0500 (EST) From: mpana@metasolv.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8h4W-00031e-00 for policy@ietf.org; Wed, 31 Mar 2004 09:52:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8h3X-0002xo-00 for policy@ietf.org; Wed, 31 Mar 2004 09:51:05 -0500 Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B8h2u-0002tL-00 for policy@ietf.org; Wed, 31 Mar 2004 09:50:24 -0500 Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Mar 2004 08:50:34 -0600 Message-ID: To: policy@ietf.org Date: Wed, 31 Mar 2004 08:42:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4172E.6DAD1290" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NEW_DOMAIN_EXTENSIONS,NO_REAL_NAME autolearn=no version=2.60 Subject: [Policy] For the record: Open Issues in PCELS-04 (all closed now) Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-BeenThere: policy@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Policy Framework List-Post: List-Help: List-Subscribe: , 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_01C4172E.6DAD1290 Content-Type: text/plain; charset="ISO-8859-1" The following section was included in the previous revision of PCELS but it has been removed in the current (-05) revision. For the record, these are the PCELS-04 Open Issues (now all closed): Appendix B: Open Issues 1. Should RFC 2119 be cited as normative reference? PCIM_EXT, PCLS and other documents refer to RFC 2119 as an informative reference. RESOLUTION: RFC2119 is cited as normative reference. 2. The object classes pcelsVendorVariable and pcelsVendorValue defined in this document are not mapped from PCIM_EXT. Pro: It is estimated that non-standard submodels and their LDAP schema implementations will need to define a considerable number of new PolicyVariable and PolicyValue subtypes. In order to avoid an explosion of LDAP class definitions, the pcelsVendorVariable and pcelsVendorValue classes introduce a value based extension mechanism for handling new data types. These classes do not introduce a new concept but rather a new extension mechanism for an existing concept. A similar mechanism is defined by PCIM and implemented by PCLS for creating vendor specific PolicyCondition and PolicyAction entries. Con: Since PCIM_EXT does not define such classes this document should not do it either. The purpose of this document this document is to map the PCIM_EXT model to an LDAP schema, therefore such functionality is outside its scope. RESOLUTION: classes preserved 3. PolicyGroup is not explicitly mapped to an LDAP object class. Pro: Since the PolicyRule has now the capability to aggregate other PolicyRule instances, this class includes the functionality of the PolicyGroup. Therefore, an explicitly implementation of the PolicyGroup class is unnecessary. Con: The PolicyRule and the PolicyGroup have different semantics so they should be defined using different classes. RESOLUTION: PolicyGroup is explicitly mapped to pcelsGroup. 4. pcelsReusableContainer is defined as a subclass of pcimRepository. Therefore the new class is an extension to the old one, not an alternative to it. Pro: As a subclass of pcimRepository, pcelsReusableContainer is compatible with older implementations that expect containers of reusable policy elements to be implemented as pcimRepository entries. The new class extends the functionality of the pcimRepository class by implementing the ContainedDomain aggregation. Con: pcelsReusableContainer as subclass of pcimRepository has potentially detrimental implications on Object Oriented models. RESOLUTION: inheritance from pcimRepository preserved 5. pcelsConditionAssociation is defined as a subclass of pcimRuleConditionAssociation. It extends the applicability of the old class to the aggregation of PolicyContition instances as components of CompoundPolicyContitions. Pro: The Condition aggregation mechanism can be reused in both Rule and CompoundCondition, therefore making it possible to optimize their implementation. Con: Mapping of the PCIM_EXT aggregations is implicit therefore more difficult for some implementations to detect. RESOLUTION: current implementation preserved ------_=_NextPart_001_01C4172E.6DAD1290 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For the record: Open Issues in PCELS-04 (all closed = now)

The following section was included in the previous = revision of PCELS but it has been removed in the current (-05) = revision. For the record, these are the PCELS-04 Open Issues (now all = closed):

Appendix B: Open Issues

   1. Should RFC 2119 be cited as normative = reference? PCIM_EXT, PCLS
   and other documents refer to RFC 2119 = as an informative reference.
   RESOLUTION: RFC2119 is cited as = normative reference.

   2. The object classes = pcelsVendorVariable and pcelsVendorValue
   defined in this document are not mapped = from PCIM_EXT.
   Pro: It is estimated that non-standard = submodels and their LDAP
   schema implementations will need to = define a considerable number of
   new PolicyVariable and PolicyValue = subtypes. In order to avoid an
   explosion of LDAP class definitions, = the pcelsVendorVariable and
   pcelsVendorValue classes introduce a = value based extension mechanism
   for handling new data types. These = classes do not introduce a new
   concept but rather a new extension = mechanism for an existing concept.
   A similar mechanism is defined by PCIM = and implemented by PCLS for
   creating vendor specific = PolicyCondition and PolicyAction entries.
   Con: Since PCIM_EXT does not define = such classes this document should
   not do it either. The purpose of this = document this document is to
   map the PCIM_EXT model to an LDAP = schema, therefore such
   functionality is outside its = scope.
   RESOLUTION: classes preserved

   3. PolicyGroup is not explicitly mapped = to an LDAP object class.
   Pro: Since the PolicyRule has now the = capability to aggregate other
   PolicyRule instances, this class = includes the functionality of the
   PolicyGroup. Therefore, an explicitly = implementation of the
   PolicyGroup class is = unnecessary.
   Con: The PolicyRule and the PolicyGroup = have different semantics so
   they should be defined using different = classes.
   RESOLUTION: PolicyGroup is explicitly = mapped to pcelsGroup.

   4. pcelsReusableContainer is defined as = a subclass of pcimRepository.
   Therefore the new class is an extension = to the old one, not an
   alternative to it.
   Pro: As a subclass of pcimRepository, = pcelsReusableContainer
   is compatible with older = implementations that expect containers of
   reusable policy elements to be = implemented as pcimRepository
   entries. The new class extends the = functionality of the
   pcimRepository class by implementing = the ContainedDomain aggregation.
   Con: pcelsReusableContainer as subclass = of pcimRepository has
   potentially detrimental implications on = Object Oriented models.
   RESOLUTION: inheritance from = pcimRepository preserved

   5. pcelsConditionAssociation is defined = as a subclass of
   pcimRuleConditionAssociation. It = extends the applicability of
   the old class to the aggregation of = PolicyContition instances as
   components of = CompoundPolicyContitions.
   Pro: The Condition aggregation = mechanism can be reused in both Rule
   and CompoundCondition, therefore making = it possible to optimize
   their implementation.
   Con: Mapping of the PCIM_EXT = aggregations is implicit therefore more
   difficult for some implementations to = detect.
   RESOLUTION: current implementation = preserved

------_=_NextPart_001_01C4172E.6DAD1290-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy