From exim@www1.ietf.org Thu Sep 4 18:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26488 for ; Thu, 4 Sep 2003 18:09:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Hs-00013G-VR for policy-archive@odin.ietf.org; Thu, 04 Sep 2003 18:09:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84M98P9004041 for policy-archive@odin.ietf.org; Thu, 4 Sep 2003 18:09:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Hl-00012g-8o; Thu, 04 Sep 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2HZ-00012D-Ls for policy@optimus.ietf.org; Thu, 04 Sep 2003 18:08:49 -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 SAA26375 for ; Thu, 4 Sep 2003 18:08:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v2HW-00065M-00 for policy@ietf.org; Thu, 04 Sep 2003 18:08:46 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19v2HU-00064g-00 for policy@ietf.org; Thu, 04 Sep 2003 18:08:44 -0400 Received: by mail.metasolv.com with Internet Mail Service (5.5.2655.55) id ; Thu, 4 Sep 2003 17:12:16 -0500 Message-ID: From: "Pana, Mircea" To: "'bwijnen@lucent.com'" , "'policy@ietf.org'" Date: Thu, 4 Sep 2003 17:09:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37331.40491930" Subject: [Policy] PCLS classes deprecated in PCELS 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_01C37331.40491930 Content-Type: text/plain; charset="iso-8859-1" PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible? The classes deprecated by PCELS are discussed below: 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized: " 5.5. Priorities and Decision Strategies [...] Unlike the earlier definition, PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet. Thus, the evaluation of rules within a set is deterministically specified. " If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe. 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons. 3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute. An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe. The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated. 4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it. So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class. Opinions? 5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class 6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe: " Because of the potential for confusion with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for the PCIM class representing a container of reusable policy elements. Thus the class PolicyRepository is being replaced with the class ReusablePolicyContainer." Best Regards, Mircea. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, August 29, 2003 11:15 AM > To: policy@ietf.org > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > What an underwhelming interest in this document. > > When I start reading it, I see in the abstract: > This document defines a number of changes and extensions to the > Policy Core LDAP Schema [PCLS] based on the specifications of the > Policy Core Information Model Extensions [PCIM_EXT]. The changes > include additional object classes previously not covered, > deprecation > of some object classes and changes to the object class hierarchy > defined in [PCLS]. > > And so I immediately wonder... is it really OK that this document > deprecates some object classes ?? > > Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and > PCLS authors/ediotrs to explicitly say so. PLEASE! > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: vrijdag 15 augustus 2003 11:45 > > To: policy@ietf.org > > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > Joel asked from the WG: > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: woensdag 6 augustus 2003 17:33 > > > To: policy@ietf.org > > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > > > > The revised Internet draft is now available in the I-D repository: > > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex > > > t-schema-03.txt > > > > > > I believe it is appropriate for this document to go forward as an > > > individual contribution that has been reviewed by a (our) > > working group. > > > As such, I will give folks one more chance to comment > > before indicating > > > that the author's can (and should) contact the AD for this. > > > Please respond by August 20 (preferably sooner) with any > comments, > > > concerns, issues, etc. It would even be helpful if folks > > would merely > > > indicate that they had read and liked the document. > > > > > > > So did anyone actually READ (or even BROWSE) the document??? > > > > PLEASE be active and participate! > > > > Bert > > > Thank you, > > > Joel M. Halpern > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > https://www1.ietf.org/mailman/listinfo/policy > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37331.40491930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and = attributes for various reasons. In some cases, deprecation could have = been avoided but in other cases this was dictated by PCIMe. (details = discussed below) I agree that deprecation might create backward = compatibility problems where PCELS and PCLS implementations attempt to = cooperate. BTW, does anybody out there have such requirements? Given = that PCIMe deprecates a significant number of concepts from PCIM, is = such cooperation even possible?

The classes deprecated by PCELS are discussed = below:

1. The class pcimGroupContainmentAuxClass defined by = PCLS provides a single, multi-valued attribute that references a set of = pcimGroups. This unordered aggregation mechanism can not be reused in = implementations of PCIMe because the model (PCIMe) requires = PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision = Strategies
   [...] Unlike the earlier = definition,
   PolicySetComponent.Priority MUST have a = unique value when compared
   with others defined for the same = aggregating PolicySet.  Thus, the
   evaluation of rules within a set is = deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then = it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in = PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are = deprecated and redefined as pcimPolicyRule* in PCELS. According to = PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS = redefines the PolicyRule class mainly for removing the Priority = attribute. An other option would have been to leave pcimRule* as they = are and then PCELS would have had to specify that the pcimRulePriority = attribute MUST NOT be used - a less formal solution that does not = prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes = is the renaming of the attributes that serve in the Rule-Condition and = Rule-Action associations. pcimRuleConditionList is replaced by = pcimConditionList and pcimRuleActionList is replaced by pcimActionList. = Thus, the new attributes along with the new association classes = (discussed below) offer a generic mechanism for aggregating Conditions = or Actions. The use the same Condition/Action aggregation mechanism for = both Policy Rules and Compound Conditions/Action is an optimization in = line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly = not the only option but based on our experience implementing PCIMe this = one seemed an acceptable compromise. However, any opinions or = suggestions from the WG based on their experience would be greatly = appreciated.

4. The class pcimRuleConditionAssociation defined by = PCLS has probably less reasons to be deprecated. It was done simply to = keep the Condition aggregation (into rules or compound conditions) = limited to a single association class. Now, looking from this different = prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the = pcimRuleConditionAssociation to become a subclass of the = pcimConditionAssociation already defined in PCELS. The attributes of = the pcimRuleConditionAssociation, all inherited from its superclass, = would end up being the same ones as previously defined by PCLS. Thus, = for aggregating Conditions into a Policy Rule, one would have the = choice of using pcimConditionAssociation or = pcimRuleConditionAssociation while Condition aggregation into a = Compound Condition would be realized only through the = pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for = the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is = deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for = confusion with the Policy Framework
   component Policy Repository (from the = four-box picture: Policy
   Management Tool, Policy Repository, = PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class = representing a container of reusable
   policy elements.  Thus the class = PolicyRepository is being replaced
   with the class = ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy@ietf.org
> Subject: RE: [Policy] Re: = draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this = document.
>
> When I start reading it, I see in the = abstract:
>    This document defines a = number of changes and extensions to the
>    Policy Core LDAP Schema = [PCLS] based on the specifications of the
>    Policy Core Information Model = Extensions [PCIM_EXT]. The changes
>    include additional object = classes previously not covered,
> deprecation
>    of some object classes and = changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK = that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the = PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. = PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> > Sent: vrijdag 15 augustus 2003 = 11:45
> > To: policy@ietf.org
> > Subject: RE: [Policy] Re: = draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel@stevecrocker.com]<= /FONT>
> > > Sent: woensdag 6 augustus 2003 = 17:33
> > > To: policy@ietf.org
> > > Subject: [Policy] Re: = draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now = available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy= -core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this = document to go forward as an
> > > individual contribution that has been = reviewed by a (our)
> > working group.
> > > As such, I will give folks one more = chance to comment
> > before indicating
> > > that the author's can (and should) = contact the AD for this.
> > > Please respond by August 20 = (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would = even be helpful if folks
> > would merely
> > > indicate that they had read and liked = the document.
> > >
> >
> > So did anyone actually READ (or even = BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > = _______________________________________________
> > Policy mailing list
> > Policy@ietf.org
> > https://www1.ietf.org/mailman/listinfo/policy
> >
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37331.40491930-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 4 19:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29795 for ; Thu, 4 Sep 2003 19:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v35A-00037g-Pb for policy-archive@odin.ietf.org; Thu, 04 Sep 2003 19:00:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84N04Cp011997 for policy-archive@odin.ietf.org; Thu, 4 Sep 2003 19:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v358-000377-NY; Thu, 04 Sep 2003 19:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v34k-00036W-CN for policy@optimus.ietf.org; Thu, 04 Sep 2003 18:59:38 -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 SAA29731 for ; Thu, 4 Sep 2003 18:59:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v34h-0007CG-00 for policy@ietf.org; Thu, 04 Sep 2003 18:59:35 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19v34f-0007Bn-00 for policy@ietf.org; Thu, 04 Sep 2003 18:59:33 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h84MwxC14763 for ; Thu, 4 Sep 2003 17:58:59 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 5 Sep 2003 00:58:57 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023314DC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Pana, Mircea'" , "Wijnen, Bert (Bert)" , "'policy@ietf.org'" Date: Fri, 5 Sep 2003 00:58:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37337.D6E5856C" Subject: [Policy] RE: PCLS classes deprecated in PCELS 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_01C37337.D6E5856C Content-Type: text/plain; charset="iso-8859-1" Mircea, thanks for your extensive response. What bothers me a bit is that it seems as if we are having this discussion between a very very small set of people (and I do not consider myself an expert in this space). So I would like to see comments from the WG, from people who have implemented PCLS and how they react to this deprecation. From the original PCLS authors, what their viewpoints are on this... Thanks, Bert -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: vrijdag 5 september 2003 0:10 To: 'bwijnen@lucent.com'; 'policy@ietf.org' Subject: PCLS classes deprecated in PCELS PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible? The classes deprecated by PCELS are discussed below: 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized: " 5.5. Priorities and Decision Strategies [...] Unlike the earlier definition, PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet. Thus, the evaluation of rules within a set is deterministically specified. " If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe. 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons. 3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute. An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe. The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated. 4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it. So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class. Opinions? 5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class 6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe: " Because of the potential for confusion with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for the PCIM class representing a container of reusable policy elements. Thus the class PolicyRepository is being replaced with the class ReusablePolicyContainer." Best Regards, Mircea. > -----Original Message----- > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > Sent: Friday, August 29, 2003 11:15 AM > To: policy@ietf.org > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > What an underwhelming interest in this document. > > When I start reading it, I see in the abstract: > This document defines a number of changes and extensions to the > Policy Core LDAP Schema [PCLS] based on the specifications of the > Policy Core Information Model Extensions [PCIM_EXT]. The changes > include additional object classes previously not covered, > deprecation > of some object classes and changes to the object class hierarchy > defined in [PCLS]. > > And so I immediately wonder... is it really OK that this document > deprecates some object classes ?? > > Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and > PCLS authors/ediotrs to explicitly say so. PLEASE! > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > > Sent: vrijdag 15 augustus 2003 11:45 > > To: policy@ietf.org > > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > Joel asked from the WG: > > > -----Original Message----- > > > From: Joel M. Halpern [ mailto:joel@stevecrocker.com ] > > > Sent: woensdag 6 augustus 2003 17:33 > > > To: policy@ietf.org > > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > > > > The revised Internet draft is now available in the I-D repository: > > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex > > > t-schema-03.txt > > > > > > I believe it is appropriate for this document to go forward as an > > > individual contribution that has been reviewed by a (our) > > working group. > > > As such, I will give folks one more chance to comment > > before indicating > > > that the author's can (and should) contact the AD for this. > > > Please respond by August 20 (preferably sooner) with any > comments, > > > concerns, issues, etc. It would even be helpful if folks > > would merely > > > indicate that they had read and liked the document. > > > > > > > So did anyone actually READ (or even BROWSE) the document??? > > > > PLEASE be active and participate! > > > > Bert > > > Thank you, > > > Joel M. Halpern > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > https://www1.ietf.org/mailman/listinfo/policy > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37337.D6E5856C Content-Type: text/html; charset="iso-8859-1" PCLS classes deprecated in PCELS
Mircea, thanks for your extensive response.
 
What bothers me a bit is that it seems as if we are having this discussion between
a very very small set of people (and I do not consider myself an expert in this space).
So I would like to see comments from the WG, from people who have implemented PCLS
and how they react to this deprecation. From the original PCLS authors, what their
viewpoints are on this...
Thanks,
Bert
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: vrijdag 5 september 2003 0:10
To: 'bwijnen@lucent.com'; 'policy@ietf.org'
Subject: PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible?

The classes deprecated by PCELS are discussed below:

1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision Strategies
   [...] Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared
   with others defined for the same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated.

4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
   Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class representing a container of reusable
   policy elements.  Thus the class PolicyRepository is being replaced
   with the class ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy@ietf.org
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this document.
>
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered,
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: policy@ietf.org
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: policy@ietf.org
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this document to go forward as an
> > > individual contribution that has been reviewed by a (our)
> > working group.
> > > As such, I will give folks one more chance to comment
> > before indicating
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would even be helpful if folks
> > would merely
> > > indicate that they had read and liked the document.
> > >
> >
> > So did anyone actually READ (or even BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > _______________________________________________
> > Policy mailing list
> > Policy@ietf.org
> > https://www1.ietf.org/mailman/listinfo/policy
> >
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37337.D6E5856C-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 5 09:20:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20000 for ; Fri, 5 Sep 2003 09:20:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGVY-0004Lk-0v for policy-archive@odin.ietf.org; Fri, 05 Sep 2003 09:20:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85DKB4Y016715 for policy-archive@odin.ietf.org; Fri, 5 Sep 2003 09:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGVP-0004K9-0J; Fri, 05 Sep 2003 09:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vGUR-0004Du-Df for policy@optimus.ietf.org; Fri, 05 Sep 2003 09:19:03 -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 JAA19911 for ; Fri, 5 Sep 2003 09:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vGUP-0006KG-00 for policy@ietf.org; Fri, 05 Sep 2003 09:19:01 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19vGUM-0006GK-00 for policy@ietf.org; Fri, 05 Sep 2003 09:18:58 -0400 Received: by mail.metasolv.com with Internet Mail Service (5.5.2655.55) id ; Fri, 5 Sep 2003 08:22:27 -0500 Message-ID: From: "Pana, Mircea" To: "'policy@ietf.org'" Date: Fri, 5 Sep 2003 08:19:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C373B0.65F1CE50" Subject: [Policy] RE: PCLS classes deprecated in PCELS 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_01C373B0.65F1CE50 Content-Type: text/plain; charset="iso-8859-1" Bert, Since we have heard opinions on this issue from two people so far (Larry and Ryan, I'd like to thank you for taking the time to do that) I felt that it would be helpful to give a detailed presentation of the reasons. I would love to hear more opinions from the authors of the other documents produced by this group. Are they still around? Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else have an opinion? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, September 04, 2003 6:59 PM To: 'Pana, Mircea'; Wijnen, Bert (Bert); 'policy@ietf.org' Subject: RE: PCLS classes deprecated in PCELS Mircea, thanks for your extensive response. What bothers me a bit is that it seems as if we are having this discussion between a very very small set of people (and I do not consider myself an expert in this space). So I would like to see comments from the WG, from people who have implemented PCLS and how they react to this deprecation. From the original PCLS authors, what their viewpoints are on this... Thanks, Bert -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: vrijdag 5 september 2003 0:10 To: 'bwijnen@lucent.com'; 'policy@ietf.org' Subject: PCLS classes deprecated in PCELS PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible? The classes deprecated by PCELS are discussed below: 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized: " 5.5. Priorities and Decision Strategies [...] Unlike the earlier definition, PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet. Thus, the evaluation of rules within a set is deterministically specified. " If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe. 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons. 3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute. An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe. The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated. 4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it. So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class. Opinions? 5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class 6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe: " Because of the potential for confusion with the Policy Framework component Policy Repository (from the four-box picture: Policy Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for the PCIM class representing a container of reusable policy elements. Thus the class PolicyRepository is being replaced with the class ReusablePolicyContainer." Best Regards, Mircea. > -----Original Message----- > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > Sent: Friday, August 29, 2003 11:15 AM > To: policy@ietf.org > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > What an underwhelming interest in this document. > > When I start reading it, I see in the abstract: > This document defines a number of changes and extensions to the > Policy Core LDAP Schema [PCLS] based on the specifications of the > Policy Core Information Model Extensions [PCIM_EXT]. The changes > include additional object classes previously not covered, > deprecation > of some object classes and changes to the object class hierarchy > defined in [PCLS]. > > And so I immediately wonder... is it really OK that this document > deprecates some object classes ?? > > Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and > PCLS authors/ediotrs to explicitly say so. PLEASE! > > Thanks, > Bert > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] > > Sent: vrijdag 15 augustus 2003 11:45 > > To: policy@ietf.org > > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > Joel asked from the WG: > > > -----Original Message----- > > > From: Joel M. Halpern [ mailto:joel@stevecrocker.com ] > > > Sent: woensdag 6 augustus 2003 17:33 > > > To: policy@ietf.org > > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > > > > The revised Internet draft is now available in the I-D repository: > > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex > > > t-schema-03.txt > > > > > > I believe it is appropriate for this document to go forward as an > > > individual contribution that has been reviewed by a (our) > > working group. > > > As such, I will give folks one more chance to comment > > before indicating > > > that the author's can (and should) contact the AD for this. > > > Please respond by August 20 (preferably sooner) with any > comments, > > > concerns, issues, etc. It would even be helpful if folks > > would merely > > > indicate that they had read and liked the document. > > > > > > > So did anyone actually READ (or even BROWSE) the document??? > > > > PLEASE be active and participate! > > > > Bert > > > Thank you, > > > Joel M. Halpern > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > https://www1.ietf.org/mailman/listinfo/policy > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C373B0.65F1CE50 Content-Type: text/html; charset="iso-8859-1" PCLS classes deprecated in PCELS
Bert,
 
Since we have heard opinions on this issue from two people so far (Larry and Ryan, I'd like to thank you for taking the time to do that) I felt that it would be helpful to give a detailed presentation of the reasons. I would love to hear more opinions from the authors of the other documents produced by this group. Are they still around?
Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else have an opinion?
 
Thanks,
Mircea.
 
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, September 04, 2003 6:59 PM
To: 'Pana, Mircea'; Wijnen, Bert (Bert); 'policy@ietf.org'
Subject: RE: PCLS classes deprecated in PCELS

Mircea, thanks for your extensive response.
 
What bothers me a bit is that it seems as if we are having this discussion between
a very very small set of people (and I do not consider myself an expert in this space).
So I would like to see comments from the WG, from people who have implemented PCLS
and how they react to this deprecation. From the original PCLS authors, what their
viewpoints are on this...
Thanks,
Bert
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: vrijdag 5 september 2003 0:10
To: 'bwijnen@lucent.com'; 'policy@ietf.org'
Subject: PCLS classes deprecated in PCELS

PCELS deprecates some of the PCLS classes and attributes for various reasons. In some cases, deprecation could have been avoided but in other cases this was dictated by PCIMe. (details discussed below) I agree that deprecation might create backward compatibility problems where PCELS and PCLS implementations attempt to cooperate. BTW, does anybody out there have such requirements? Given that PCIMe deprecates a significant number of concepts from PCIM, is such cooperation even possible?

The classes deprecated by PCELS are discussed below:

1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, multi-valued attribute that references a set of pcimGroups. This unordered aggregation mechanism can not be reused in implementations of PCIMe because the model (PCIMe) requires PolicySetComponent associations to be prioritized:

"  5.5. Priorities and Decision Strategies
   [...] Unlike the earlier definition,
   PolicySetComponent.Priority MUST have a unique value when compared
   with others defined for the same aggregating PolicySet.  Thus, the
   evaluation of rules within a set is deterministically specified. "
If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting with PCIMe.

2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by PCELS for the same reasons.

3. The pcimRule* classes defined by PCLS are deprecated and redefined as pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority property is deprecated. Therefore PCELS redefines the PolicyRule class mainly for removing the Priority attribute. An other option would have been to leave pcimRule* as they are and then PCELS would have had to specify that the pcimRulePriority attribute MUST NOT be used - a less formal solution that does not prevent accidental use of the deprecated attribute.

An other reason for replacing the pcimRule* classes is the renaming of the attributes that serve in the Rule-Condition and Rule-Action associations. pcimRuleConditionList is replaced by pcimConditionList and pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes along with the new association classes (discussed below) offer a generic mechanism for aggregating Conditions or Actions. The use the same Condition/Action aggregation mechanism for both Policy Rules and Compound Conditions/Action is an optimization in line with the Policy*Structure concepts defined by PCIMe.

The deprecation of the pcimRule* classes is certainly not the only option but based on our experience implementing PCIMe this one seemed an acceptable compromise. However, any opinions or suggestions from the WG based on their experience would be greatly appreciated.

4. The class pcimRuleConditionAssociation defined by PCLS has probably less reasons to be deprecated. It was done simply to keep the Condition aggregation (into rules or compound conditions) limited to a single association class. Now, looking from this different prospective, I think that it is a good idea to retain it.

So, I suggest the modification of the pcimRuleConditionAssociation to become a subclass of the pcimConditionAssociation already defined in PCELS. The attributes of the pcimRuleConditionAssociation, all inherited from its superclass, would end up being the same ones as previously defined by PCLS. Thus, for aggregating Conditions into a Policy Rule, one would have the choice of using pcimConditionAssociation or pcimRuleConditionAssociation while Condition aggregation into a Compound Condition would be realized only through the pcimConditionAssociation class.

Opinions?

5. pcimRuleActionAssociation - same suggestion as for the pcimRuleConditionAssociation class

6. The pcimRepository class defined by PCLS is deprecated by PCELS for reasons described in PCIMe:
"   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
   Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
   a bad name for the PCIM class representing a container of reusable
   policy elements.  Thus the class PolicyRepository is being replaced
   with the class ReusablePolicyContainer."


Best Regards,
Mircea.



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Friday, August 29, 2003 11:15 AM
> To: policy@ietf.org
> Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
>
>
> What an underwhelming interest in this document.
>
> When I start reading it, I see in the abstract:
>    This document defines a number of changes and extensions to the
>    Policy Core LDAP Schema [PCLS] based on the specifications of the
>    Policy Core Information Model Extensions [PCIM_EXT]. The changes
>    include additional object classes previously not covered,
> deprecation
>    of some object classes and changes to the object class hierarchy
>    defined in [PCLS].
>
> And so I immediately wonder... is it really OK that this document
> deprecates some object classes ??
>
> Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and
> PCLS authors/ediotrs to explicitly say so. PLEASE!
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: vrijdag 15 augustus 2003 11:45
> > To: policy@ietf.org
> > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> >
> >
> > Joel asked from the WG:
> > > -----Original Message-----
> > > From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> > > Sent: woensdag 6 augustus 2003 17:33
> > > To: policy@ietf.org
> > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt
> > >
> > >
> > > The revised Internet draft is now available in the I-D repository:
> > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex
> > > t-schema-03.txt
> > >
> > > I believe it is appropriate for this document to go forward as an
> > > individual contribution that has been reviewed by a (our)
> > working group.
> > > As such, I will give folks one more chance to comment
> > before indicating
> > > that the author's can (and should) contact the AD for this.
> > > Please respond by August 20 (preferably sooner) with any
> comments,
> > > concerns, issues, etc.  It would even be helpful if folks
> > would merely
> > > indicate that they had read and liked the document.
> > >
> >
> > So did anyone actually READ (or even BROWSE) the document???
> >
> > PLEASE be active and participate!
> >
> > Bert
> > > Thank you,
> > > Joel M. Halpern
> >
> > _______________________________________________
> > Policy mailing list
> > Policy@ietf.org
> > https://www1.ietf.org/mailman/listinfo/policy
> >
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C373B0.65F1CE50-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 9 10:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12943 for ; Tue, 9 Sep 2003 10:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTT-0000YU-1z for policy-archive@odin.ietf.org; Tue, 09 Sep 2003 10:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89ES7L7002135 for policy-archive@odin.ietf.org; Tue, 9 Sep 2003 10:28:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjTN-0000XJ-4b; Tue, 09 Sep 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjSh-0000Vn-8V for policy@optimus.ietf.org; Tue, 09 Sep 2003 10:27:19 -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 KAA12849 for ; Tue, 9 Sep 2003 10:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjSf-0004Dz-00 for policy@ietf.org; Tue, 09 Sep 2003 10:27:17 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19wjSe-0004Cj-00 for policy@ietf.org; Tue, 09 Sep 2003 10:27:16 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h89EQRI02358; Tue, 9 Sep 2003 09:26:27 -0500 Date: Tue, 9 Sep 2003 09:26:27 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: "'bwijnen@lucent.com'" , "'policy@ietf.org'" Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030909092627.A2352@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mpana@metasolv.com on Thu, Sep 04, 2003 at 05:09:46PM -0500 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: , On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote: | PCELS deprecates some of the PCLS classes and attributes for various | reasons. In some cases, deprecation could have been avoided but in other | cases this was dictated by PCIMe. (details discussed below) I agree that | deprecation might create backward compatibility problems where PCELS and | PCLS implementations attempt to cooperate. BTW, does anybody out there have | such requirements? Given that PCIMe deprecates a significant number of | concepts from PCIM, is such cooperation even possible? | | The classes deprecated by PCELS are discussed below: | | 1. The class pcimGroupContainmentAuxClass defined by PCLS provides a single, | multi-valued attribute that references a set of pcimGroups. This unordered | aggregation mechanism can not be reused in implementations of PCIMe because | the model (PCIMe) requires PolicySetComponent associations to be | prioritized: | " 5.5. Priorities and Decision Strategies | [...] Unlike the earlier definition, | PolicySetComponent.Priority MUST have a unique value when compared | with others defined for the same aggregating PolicySet. Thus, the | evaluation of rules within a set is deterministically specified. " | If PCELS allowed pcimGroupContainmentAuxClass, then it would be conflicting | with PCIMe. | | 2. The class pcimRuleContainmentAuxClass defined in PCLS is deprecated by | PCELS for the same reasons. Those are not reason to deprecate classes in the more general model. That's a reason to say "in this space, this other class should be used". | 3. The pcimRule* classes defined by PCLS are deprecated and redefined as | pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority | property is deprecated. Therefore PCELS redefines the PolicyRule class | mainly for removing the Priority attribute. An other option would have been | to leave pcimRule* as they are and then PCELS would have had to specify that | the pcimRulePriority attribute MUST NOT be used - a less formal solution | that does not prevent accidental use of the deprecated attribute. | | An other reason for replacing the pcimRule* classes is the renaming of the | attributes that serve in the Rule-Condition and Rule-Action associations. | pcimRuleConditionList is replaced by pcimConditionList and | pcimRuleActionList is replaced by pcimActionList. Thus, the new attributes | along with the new association classes (discussed below) offer a generic | mechanism for aggregating Conditions or Actions. The use the same | Condition/Action aggregation mechanism for both Policy Rules and Compound | Conditions/Action is an optimization in line with the Policy*Structure | concepts defined by PCIMe. Since you are rethinking subclass/deprication below, I'd argue rethink it here. | The deprecation of the pcimRule* classes is certainly not the only option | but based on our experience implementing PCIMe this one seemed an acceptable | compromise. However, any opinions or suggestions from the WG based on their | experience would be greatly appreciated. | | 4. The class pcimRuleConditionAssociation defined by PCLS has probably less | reasons to be deprecated. It was done simply to keep the Condition | aggregation (into rules or compound conditions) limited to a single | association class. Now, looking from this different prospective, I think | that it is a good idea to retain it. | | So, I suggest the modification of the pcimRuleConditionAssociation to become | a subclass of the pcimConditionAssociation already defined in PCELS. The | attributes of the pcimRuleConditionAssociation, all inherited from its | superclass, would end up being the same ones as previously defined by PCLS. | Thus, for aggregating Conditions into a Policy Rule, one would have the | choice of using pcimConditionAssociation or pcimRuleConditionAssociation | while Condition aggregation into a Compound Condition would be realized only | through the pcimConditionAssociation class. | | 5. pcimRuleActionAssociation - same suggestion as for the | pcimRuleConditionAssociation class This is a much better solution... | 6. The pcimRepository class defined by PCLS is deprecated by PCELS for | reasons described in PCIMe: | " Because of the potential for confusion with the Policy Framework | component Policy Repository (from the four-box picture: Policy | Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is | a bad name for the PCIM class representing a container of reusable | policy elements. Thus the class PolicyRepository is being replaced | with the class ReusablePolicyContainer." This could also be handled with a subclass. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 9 10:39:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13590 for ; Tue, 9 Sep 2003 10:39:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wje0-0001En-Rs for policy-archive@odin.ietf.org; Tue, 09 Sep 2003 10:39:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Ed0QO004728 for policy-archive@odin.ietf.org; Tue, 9 Sep 2003 10:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wje0-0001EA-Ky; Tue, 09 Sep 2003 10:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjdU-0001DZ-2h for policy@optimus.ietf.org; Tue, 09 Sep 2003 10:38:28 -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 KAA13526 for ; Tue, 9 Sep 2003 10:38:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjdR-0004SO-00 for policy@ietf.org; Tue, 09 Sep 2003 10:38:25 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19wjdB-0004R7-00 for policy@ietf.org; Tue, 09 Sep 2003 10:38:09 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h89EbYC02549; Tue, 9 Sep 2003 09:37:34 -0500 Date: Tue, 9 Sep 2003 09:37:34 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: "'policy@ietf.org'" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS Message-ID: <20030909093734.B2352@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mpana@metasolv.com on Fri, Sep 05, 2003 at 08:19:55AM -0500 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: , On Fri, Sep 05, 2003 at 08:19:55AM -0500, Pana, Mircea wrote: | Bert, | | Since we have heard opinions on this issue from two people so far (Larry and | Ryan, I'd like to thank you for taking the time to do that) I felt that it | would be helpful to give a detailed presentation of the reasons. I would | love to hear more opinions from the authors of the other documents produced | by this group. Are they still around? | Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else | have an opinion? I have running code that uses PolicyRule and PolicyRule.Priority quite happily through subclasses, so I really don't see the need to deprecate it. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 9 10:45:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14030 for ; Tue, 9 Sep 2003 10:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjjr-0001dG-3C for policy-archive@odin.ietf.org; Tue, 09 Sep 2003 10:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89Ej3dX006247 for policy-archive@odin.ietf.org; Tue, 9 Sep 2003 10:45:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjjq-0001cH-LN; Tue, 09 Sep 2003 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wjjI-0001bT-Cy for policy@optimus.ietf.org; Tue, 09 Sep 2003 10:44:28 -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 KAA13957 for ; Tue, 9 Sep 2003 10:44:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wjjF-0004aJ-00 for policy@ietf.org; Tue, 09 Sep 2003 10:44:25 -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 19wjjF-0004aG-00 for policy@ietf.org; Tue, 09 Sep 2003 10:44:25 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Sep 2003 10:44:15 -0400 Message-ID: From: David McTavish To: "'rmoats@lemurnetworks.net'" , "Pana, Mircea" Cc: "'policy@ietf.org'" Subject: RE: [Policy] RE: PCLS classes deprecated in PCELS Date: Tue, 9 Sep 2003 10:44:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , I would like to second this approach. We have implemented a hardware-based solution using the existing PCIM schema, and with our goal to be following this standard as much as possible. Our experience with deprecating schema, especially within the scope of LDAP, is that it is not a "good thing". While we would like to strive to adopt PCIMe and PCLS for some of the extensions that it brings, we would be hard-pressed to adopt such a sweeping change as currently submitted. I believe, that with Ryan's suggestions, the ability to extend an existing implementation from PCIM would be more approachable than in its current form. rgds, d. -----Original Message----- From: Ryan Moats [mailto:rmoats@lemurnetworks.net] Sent: Tuesday, September 09, 2003 10:38 AM To: Pana, Mircea Cc: 'policy@ietf.org' Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS On Fri, Sep 05, 2003 at 08:19:55AM -0500, Pana, Mircea wrote: | Bert, | | Since we have heard opinions on this issue from two people so far (Larry and | Ryan, I'd like to thank you for taking the time to do that) I felt that it | would be helpful to give a detailed presentation of the reasons. I would | love to hear more opinions from the authors of the other documents produced | by this group. Are they still around? | Does anybody have running code based on PCIM, PCLS, PCIMe? Does anybody else | have an opinion? I have running code that uses PolicyRule and PolicyRule.Priority quite happily through subclasses, so I really don't see the need to deprecate it. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 11 18:27:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16863 for ; Thu, 11 Sep 2003 18:27:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xZuO-0001oM-Vq for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 18:27:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BMROHS006960 for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 18:27:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xZu0-0001nw-I0; Thu, 11 Sep 2003 18:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xZtn-0001ni-MS for policy@optimus.ietf.org; Thu, 11 Sep 2003 18:26:48 -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 SAA16858 for ; Thu, 11 Sep 2003 18:26:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xZtX-0006s0-00 for policy@ietf.org; Thu, 11 Sep 2003 18:26:31 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19xZtV-0006rr-00 for policy@ietf.org; Thu, 11 Sep 2003 18:26:30 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Thu, 11 Sep 2003 17:30:11 -0500 Message-ID: From: "Pana, Mircea" To: "'policy@ietf.org'" Cc: "'bwijnen@lucent.com'" , "'rmoats@lemurnetworks.net'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Thu, 11 Sep 2003 17:21:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C378B3.13A9F390" 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_01C378B3.13A9F390 Content-Type: text/plain; charset="iso-8859-1" IMO the usage of schema items corresponding to deprecated concepts would be in conflict with the model (in this case PCIMe). However, a "peaceful co-existence" would be a very good reason for compromise. The following proposal gets PCELS out of the "policing business" and where compliance with PCIMe requires PCLS classes or attributes not to be used, this is noted with the specific indication "for compliance with PCIMe implementations shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find the following acceptable: 1. Replace the pcimGroupContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe, implementations shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group, Rule or System". 2. Replace the pcimRuleContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe, implementations shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group, Rule or System". 3. The pcimRule* classes would not be deprecated. Instead, the abstract class pcimRule would be modified to become a subclass of the abstract class pcimPolicyRule defined in PCELS. A note would be added to indicate that "for compliance with PCIMe, implementations shall not use the pcimRule.pcimRulePriority attribute". See also Note_1 below. 4. The class pcimRuleConditionAssociation would be modified to become subclass of the pcimConditionAssociation class. 5. The class pcimRuleActionAssociation would be modified to become subclass of the pcimActionAssociation class. 6. The pcimRepository* classes would not be deprecated. Instead the abstract class pcimRepository would be modified to become subclass of the abstract class pcimReusableContainer defined in PCELS. PCELS would indicate that "for compliance with PCIMe, the pcimReusableContainer* classes shall be used instead of the pcimRepository* classes". Note_1: Without other changes, the pcimRule would end up having redundant functionality: - pcimRuleConditionList and pcimConditionList for aggregating conditions - pcimRuleActionList and pcimActionList for aggregating actions etc. A. One option would be to do nothing about it but this may lead to ambiguous situations :-( B. A second option would be to use the pcimRuleConditionAssociation and the pcimRuleActionAssociation attributes and the association classes defined by PCLS in the definition of the pcimPolicyRule. In this case the pcimPolicyRule* and pcimCompound*AuxClass would not use the same attributes and association classes to aggregate Conditions and Actions :-( C. A third option would be to change the pcimPolicyRule definition to: ( [...] SUP pcimPolicySet ABSTRACT MAY ( pcimRuleName $ pcimRuleEnabled $ pcimRuleValidityPeriodList $ pcimRuleUsage $ pcimRuleMandatory ) ) (Condition and Action aggregation attributes removed from the Rule class) In this case, PCELS would recommend the use of attached pcimCompound*AuxClass instances as means to aggregate multiple Actions/Conditions to a Rule. D. A mix of the previous two: Option B with a note that implementations MAY choose to support only C. Comments and suggestions would be greatly appreciated? Also, I would greatly appreciate the PCIMe author's opinion wrt. the [non]deprecation. Thanks, Mircea. > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Tuesday, September 09, 2003 10:26 AM > To: Pana, Mircea > Cc: 'bwijnen@lucent.com'; 'policy@ietf.org' > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote: > | PCELS deprecates some of the PCLS classes and attributes for various > | reasons. In some cases, deprecation could have been avoided > but in other > | cases this was dictated by PCIMe. (details discussed below) > I agree that > | deprecation might create backward compatibility problems > where PCELS and > | PCLS implementations attempt to cooperate. BTW, does > anybody out there have > | such requirements? Given that PCIMe deprecates a > significant number of > | concepts from PCIM, is such cooperation even possible? > | > | The classes deprecated by PCELS are discussed below: > | > | 1. The class pcimGroupContainmentAuxClass defined by PCLS > provides a single, > | multi-valued attribute that references a set of pcimGroups. > This unordered > | aggregation mechanism can not be reused in implementations > of PCIMe because > | the model (PCIMe) requires PolicySetComponent associations to be > | prioritized: > | " 5.5. Priorities and Decision Strategies > | [...] Unlike the earlier definition, > | PolicySetComponent.Priority MUST have a unique value > when compared > | with others defined for the same aggregating PolicySet. > Thus, the > | evaluation of rules within a set is deterministically > specified. " > | If PCELS allowed pcimGroupContainmentAuxClass, then it > would be conflicting > | with PCIMe. > | > | 2. The class pcimRuleContainmentAuxClass defined in PCLS is > deprecated by > | PCELS for the same reasons. > > Those are not reason to deprecate classes in the more general > model. That's > a reason to say "in this space, this other class should be used". > > | 3. The pcimRule* classes defined by PCLS are deprecated and > redefined as > | pcimPolicyRule* in PCELS. According to PCIMe the PolicyRule.Priority > | property is deprecated. Therefore PCELS redefines the > PolicyRule class > | mainly for removing the Priority attribute. An other option > would have been > | to leave pcimRule* as they are and then PCELS would have > had to specify that > | the pcimRulePriority attribute MUST NOT be used - a less > formal solution > | that does not prevent accidental use of the deprecated attribute. > | > | An other reason for replacing the pcimRule* classes is the > renaming of the > | attributes that serve in the Rule-Condition and Rule-Action > associations. > | pcimRuleConditionList is replaced by pcimConditionList and > | pcimRuleActionList is replaced by pcimActionList. Thus, the > new attributes > | along with the new association classes (discussed below) > offer a generic > | mechanism for aggregating Conditions or Actions. The use the same > | Condition/Action aggregation mechanism for both Policy > Rules and Compound > | Conditions/Action is an optimization in line with the > Policy*Structure > | concepts defined by PCIMe. > > Since you are rethinking subclass/deprication below, I'd > argue rethink it > here. > > | The deprecation of the pcimRule* classes is certainly not > the only option > | but based on our experience implementing PCIMe this one > seemed an acceptable > | compromise. However, any opinions or suggestions from the > WG based on their > | experience would be greatly appreciated. > | > | 4. The class pcimRuleConditionAssociation defined by PCLS > has probably less > | reasons to be deprecated. It was done simply to keep the Condition > | aggregation (into rules or compound conditions) limited to a single > | association class. Now, looking from this different > prospective, I think > | that it is a good idea to retain it. > | > | So, I suggest the modification of the > pcimRuleConditionAssociation to become > | a subclass of the pcimConditionAssociation already defined > in PCELS. The > | attributes of the pcimRuleConditionAssociation, all > inherited from its > | superclass, would end up being the same ones as previously > defined by PCLS. > | Thus, for aggregating Conditions into a Policy Rule, one > would have the > | choice of using pcimConditionAssociation or > pcimRuleConditionAssociation > | while Condition aggregation into a Compound Condition would > be realized only > | through the pcimConditionAssociation class. > | > | 5. pcimRuleActionAssociation - same suggestion as for the > | pcimRuleConditionAssociation class > > This is a much better solution... > > | 6. The pcimRepository class defined by PCLS is deprecated > by PCELS for > | reasons described in PCIMe: > | " Because of the potential for confusion with the Policy Framework > | component Policy Repository (from the four-box picture: Policy > | Management Tool, Policy Repository, PDP, PEP), > "PolicyRepository" is > | a bad name for the PCIM class representing a container > of reusable > | policy elements. Thus the class PolicyRepository is > being replaced > | with the class ReusablePolicyContainer." > > This could also be handled with a subclass. > > Ryan > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C378B3.13A9F390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

IMO the usage of schema items corresponding to = deprecated concepts would be in conflict with the model (in this case = PCIMe). However, a "peaceful co-existence" would be a very = good reason for compromise. The following proposal gets PCELS out of = the "policing business" and where compliance with PCIMe = requires PCLS classes or attributes not to be used, this is noted with = the specific indication "for compliance with PCIMe implementations = shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you = will find the following acceptable:

1. Replace the pcimGroupContainmentAuxClass class = deprecation with a paragraph to indicate that "for compliance with = PCIMe, implementations shall use the = pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated = pcimPolicySetAssociation entry instead of an attached = pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy = Group, Rule or System".

2. Replace the pcimRuleContainmentAuxClass class = deprecation with a paragraph to indicate that "for compliance with = PCIMe,  implementations shall use the = pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated = pcimPolicySetAssociation entry instead of an attached = pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy = Group, Rule or System".

3. The pcimRule* classes would not be deprecated. = Instead, the abstract class pcimRule would be modified to become a = subclass of the abstract class pcimPolicyRule defined in PCELS. A note = would be added to indicate that "for compliance with PCIMe, = implementations shall not use the pcimRule.pcimRulePriority = attribute". See also Note_1 below.

4. The class pcimRuleConditionAssociation would be = modified to become subclass of the pcimConditionAssociation = class.

5. The class pcimRuleActionAssociation would be = modified to become subclass of the pcimActionAssociation class.

6. The pcimRepository* classes would not be = deprecated. Instead the abstract class pcimRepository would be modified = to become subclass of the abstract class pcimReusableContainer defined = in PCELS. PCELS would indicate that "for compliance with PCIMe, = the pcimReusableContainer* classes shall be used instead of the = pcimRepository* classes".


Note_1:
Without other changes, the pcimRule would end up = having redundant functionality:
- pcimRuleConditionList and pcimConditionList for = aggregating conditions
- pcimRuleActionList and pcimActionList for = aggregating actions
etc.

A. One option would be to do nothing about it but = this may lead to ambiguous situations :-(

B. A second option would be to use the = pcimRuleConditionAssociation and the pcimRuleActionAssociation = attributes and the association classes defined by PCLS in the = definition of the pcimPolicyRule. In this case the pcimPolicyRule* and = pcimCompound*AuxClass would not use the same attributes and association = classes to aggregate Conditions and Actions :-(

C. A third option would be to change the = pcimPolicyRule definition to:
   ( [...] SUP pcimPolicySet
     ABSTRACT
     MAY ( pcimRuleName
         $ = pcimRuleEnabled
         $ = pcimRuleValidityPeriodList
         $ = pcimRuleUsage
         $ = pcimRuleMandatory )
   )
(Condition and Action aggregation attributes removed = from the Rule class)
In this case, PCELS would recommend the use of = attached pcimCompound*AuxClass instances as means to aggregate multiple = Actions/Conditions to a Rule.

D. A mix of the previous two: Option B with a note = that implementations MAY choose to support only C.

Comments and suggestions would be greatly = appreciated? Also, I would greatly appreciate the PCIMe author's = opinion wrt. the [non]deprecation.

Thanks,
Mircea.



 
> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Tuesday, September 09, 2003 10:26 = AM
> To: Pana, Mircea
> Cc: 'bwijnen@lucent.com'; = 'policy@ietf.org'
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
>
> On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, = Mircea wrote:
> | PCELS deprecates some of the PCLS classes and = attributes for various
> | reasons. In some cases, deprecation could = have been avoided
> but in other
> | cases this was dictated by PCIMe. (details = discussed below)
> I agree that
> | deprecation might create backward = compatibility problems
> where PCELS and
> | PCLS implementations attempt to cooperate. = BTW, does
> anybody out there have
> | such requirements? Given that PCIMe = deprecates a
> significant number of
> | concepts from PCIM, is such cooperation even = possible?
> |
> | The classes deprecated by PCELS are discussed = below:
> |
> | 1. The class pcimGroupContainmentAuxClass = defined by PCLS
> provides a single,
> | multi-valued attribute that references a set = of pcimGroups.
> This unordered
> | aggregation mechanism can not be reused in = implementations
> of PCIMe because
> | the model (PCIMe) requires PolicySetComponent = associations to be
> | prioritized:
> | "  5.5. Priorities and Decision = Strategies
> |    [...] Unlike the earlier = definition,
> |    PolicySetComponent.Priority = MUST have a unique value
> when compared
> |    with others defined for the = same aggregating PolicySet. 
> Thus, the
> |    evaluation of rules within = a set is deterministically
> specified. "
> | If PCELS allowed = pcimGroupContainmentAuxClass, then it
> would be conflicting
> | with PCIMe.
> |
> | 2. The class pcimRuleContainmentAuxClass = defined in PCLS is
> deprecated by
> | PCELS for the same reasons.
>
> Those are not reason to deprecate classes in = the more general
> model.  That's
> a reason to say "in this space, this other = class should be used".
>
> | 3. The pcimRule* classes defined by PCLS are = deprecated and
> redefined as
> | pcimPolicyRule* in PCELS. According to PCIMe = the PolicyRule.Priority
> | property is deprecated. Therefore PCELS = redefines the
> PolicyRule class
> | mainly for removing the Priority attribute. = An other option
> would have been
> | to leave pcimRule* as they are and then PCELS = would have
> had to specify that
> | the pcimRulePriority attribute MUST NOT be = used - a less
> formal solution
> | that does not prevent accidental use of the = deprecated attribute.
> |
> | An other reason for replacing the pcimRule* = classes is the
> renaming of the
> | attributes that serve in the Rule-Condition = and Rule-Action
> associations.
> | pcimRuleConditionList is replaced by = pcimConditionList and
> | pcimRuleActionList is replaced by = pcimActionList. Thus, the
> new attributes
> | along with the new association classes = (discussed below)
> offer a generic
> | mechanism for aggregating Conditions or = Actions. The use the same
> | Condition/Action aggregation mechanism for = both Policy
> Rules and Compound
> | Conditions/Action is an optimization in line = with the
> Policy*Structure
> | concepts defined by PCIMe.
>
> Since you are rethinking subclass/deprication = below, I'd
> argue rethink it
> here.
>
> | The deprecation of the pcimRule* classes is = certainly not
> the only option
> | but based on our experience implementing = PCIMe this one
> seemed an acceptable
> | compromise. However, any opinions or = suggestions from the
> WG based on their
> | experience would be greatly = appreciated.
> |
> | 4. The class pcimRuleConditionAssociation = defined by PCLS
> has probably less
> | reasons to be deprecated. It was done simply = to keep the Condition
> | aggregation (into rules or compound = conditions) limited to a single
> | association class. Now, looking from this = different
> prospective, I think
> | that it is a good idea to retain it.
> |
> | So, I suggest the modification of the
> pcimRuleConditionAssociation to become
> | a subclass of the pcimConditionAssociation = already defined
> in PCELS. The
> | attributes of the = pcimRuleConditionAssociation, all
> inherited from its
> | superclass, would end up being the same ones = as previously
> defined by PCLS.
> | Thus, for aggregating Conditions into a = Policy Rule, one
> would have the
> | choice of using pcimConditionAssociation or =
> pcimRuleConditionAssociation
> | while Condition aggregation into a Compound = Condition would
> be realized only
> | through the pcimConditionAssociation = class.
> |
> | 5. pcimRuleActionAssociation - same = suggestion as for the
> | pcimRuleConditionAssociation class
>
> This is a much better solution...
>
> | 6. The pcimRepository class defined by PCLS = is deprecated
> by PCELS for
> | reasons described in PCIMe:
> | "   Because of the potential = for confusion with the Policy Framework
> |    component Policy Repository = (from the four-box picture: Policy
> |    Management Tool, Policy = Repository, PDP, PEP),
> "PolicyRepository" is
> |    a bad name for the PCIM = class representing a container
> of reusable
> |    policy elements.  Thus = the class PolicyRepository is
> being replaced
> |    with the class = ReusablePolicyContainer."
>
> This could also be handled with a = subclass.
>
> Ryan
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C378B3.13A9F390-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 11 19:08:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17706 for ; Thu, 11 Sep 2003 19:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xaXh-0003A9-C7 for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 19:08:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BN81Kf012140 for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 19:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xaXg-00039V-TA; Thu, 11 Sep 2003 19:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xaXP-00036U-4M for policy@optimus.ietf.org; Thu, 11 Sep 2003 19:07:43 -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 TAA17681 for ; Thu, 11 Sep 2003 19:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xaXL-00077j-00 for policy@ietf.org; Thu, 11 Sep 2003 19:07:39 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xaXL-00077c-00 for policy@ietf.org; Thu, 11 Sep 2003 19:07:39 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8BN73005827; Thu, 11 Sep 2003 18:07:03 -0500 Date: Thu, 11 Sep 2003 18:07:03 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: "'policy@ietf.org'" , "'bwijnen@lucent.com'" Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030911180703.T1869@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mpana@metasolv.com on Thu, Sep 11, 2003 at 05:21:42PM -0500 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: , On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote: | IMO the usage of schema items corresponding to deprecated concepts would be | in conflict with the model (in this case PCIMe). However, a "peaceful | co-existence" would be a very good reason for compromise. The following | proposal gets PCELS out of the "policing business" and where compliance with | PCIMe requires PCLS classes or attributes not to be used, this is noted with | the specific indication "for compliance with PCIMe implementations | shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find | the following acceptable: | | 1. Replace the pcimGroupContainmentAuxClass class deprecation with a | paragraph to indicate that "for compliance with PCIMe, implementations shall | use the pcimPolicySet.pcimPolicySetComponentList attribute and a | subordinated pcimPolicySetAssociation entry instead of an attached | pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group, | Rule or System". | | 2. Replace the pcimRuleContainmentAuxClass class deprecation with a | paragraph to indicate that "for compliance with PCIMe, implementations | shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a | subordinated pcimPolicySetAssociation entry instead of an attached | pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group, | Rule or System". I can live with these two... | 3. The pcimRule* classes would not be deprecated. Instead, the abstract | class pcimRule would be modified to become a subclass of the abstract class | pcimPolicyRule defined in PCELS. A note would be added to indicate that "for | compliance with PCIMe, implementations shall not use the | pcimRule.pcimRulePriority attribute". See also Note_1 below. | | 4. The class pcimRuleConditionAssociation would be modified to become | subclass of the pcimConditionAssociation class. | | 5. The class pcimRuleActionAssociation would be modified to become subclass | of the pcimActionAssociation class. I can't live with these three: they would require me to change my working implementation and change the PCLS schema. If you are going to do a subclass here and not break PCLS or existing implementations, you have to go the other way: pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a subclass of pcimRuleConditionAssociation, etc. This changes Note #1 to what are the issues for pcimPolicyRule... | 6. The pcimRepository* classes would not be deprecated. Instead the abstract | class pcimRepository would be modified to become subclass of the abstract | class pcimReusableContainer defined in PCELS. PCELS would indicate that "for | compliance with PCIMe, the pcimReusableContainer* classes shall be used | instead of the pcimRepository* classes". Again, I can live with #6. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 11 19:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18732 for ; Thu, 11 Sep 2003 19:37:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xazp-00043J-0r for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 19:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BNb4Pp015572 for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 19:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xazl-00041h-2r; Thu, 11 Sep 2003 19:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xayv-0003zF-4B for policy@optimus.ietf.org; Thu, 11 Sep 2003 19:36:11 -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 TAA18685 for ; Thu, 11 Sep 2003 19:36:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xayt-0007Nr-00 for policy@ietf.org; Thu, 11 Sep 2003 19:36:07 -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 19xays-0007No-00 for policy@ietf.org; Thu, 11 Sep 2003 19:36:07 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 19:36:07 -0400 Message-ID: From: David McTavish To: "'rmoats@lemurnetworks.net'" , "Pana, Mircea" Cc: "'policy@ietf.org'" , "'bwijnen@lucent.com'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Thu, 11 Sep 2003 19:36:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , I agree with Ryan for all points except point 6, although, I believe that this change would be easier to manage than in the initial proposal. d. -----Original Message----- From: Ryan Moats [mailto:rmoats@lemurnetworks.net] Sent: Thursday, September 11, 2003 7:07 PM To: Pana, Mircea Cc: 'policy@ietf.org'; 'bwijnen@lucent.com' Subject: Re: [Policy] PCLS classes deprecated in PCELS On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote: | IMO the usage of schema items corresponding to deprecated concepts would be | in conflict with the model (in this case PCIMe). However, a "peaceful | co-existence" would be a very good reason for compromise. The following | proposal gets PCELS out of the "policing business" and where compliance with | PCIMe requires PCLS classes or attributes not to be used, this is noted with | the specific indication "for compliance with PCIMe implementations | shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find | the following acceptable: | | 1. Replace the pcimGroupContainmentAuxClass class deprecation with a | paragraph to indicate that "for compliance with PCIMe, implementations shall | use the pcimPolicySet.pcimPolicySetComponentList attribute and a | subordinated pcimPolicySetAssociation entry instead of an attached | pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group, | Rule or System". | | 2. Replace the pcimRuleContainmentAuxClass class deprecation with a | paragraph to indicate that "for compliance with PCIMe, implementations | shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a | subordinated pcimPolicySetAssociation entry instead of an attached | pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group, | Rule or System". I can live with these two... | 3. The pcimRule* classes would not be deprecated. Instead, the abstract | class pcimRule would be modified to become a subclass of the abstract class | pcimPolicyRule defined in PCELS. A note would be added to indicate that "for | compliance with PCIMe, implementations shall not use the | pcimRule.pcimRulePriority attribute". See also Note_1 below. | | 4. The class pcimRuleConditionAssociation would be modified to become | subclass of the pcimConditionAssociation class. | | 5. The class pcimRuleActionAssociation would be modified to become subclass | of the pcimActionAssociation class. I can't live with these three: they would require me to change my working implementation and change the PCLS schema. If you are going to do a subclass here and not break PCLS or existing implementations, you have to go the other way: pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a subclass of pcimRuleConditionAssociation, etc. This changes Note #1 to what are the issues for pcimPolicyRule... | 6. The pcimRepository* classes would not be deprecated. Instead the abstract | class pcimRepository would be modified to become subclass of the abstract | class pcimReusableContainer defined in PCELS. PCELS would indicate that "for | compliance with PCIMe, the pcimReusableContainer* classes shall be used | instead of the pcimRepository* classes". Again, I can live with #6. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 11 20:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19993 for ; Thu, 11 Sep 2003 20:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xbhK-0005nT-GC for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 20:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8C0M26T022254 for policy-archive@odin.ietf.org; Thu, 11 Sep 2003 20:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xbhK-0005mo-83; Thu, 11 Sep 2003 20:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xbh4-0005mS-An for policy@optimus.ietf.org; Thu, 11 Sep 2003 20:21:46 -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 UAA19982 for ; Thu, 11 Sep 2003 20:21:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xbh2-00000m-00 for policy@ietf.org; Thu, 11 Sep 2003 20:21:44 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xbh1-00000Z-00 for policy@ietf.org; Thu, 11 Sep 2003 20:21:43 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8C0LAu05885; Thu, 11 Sep 2003 19:21:10 -0500 Date: Thu, 11 Sep 2003 19:21:10 -0500 From: Ryan Moats To: David McTavish Cc: "Pana, Mircea" , "'policy@ietf.org'" , "'bwijnen@lucent.com'" Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030911192110.A5878@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dmctavish@sandvine.com on Thu, Sep 11, 2003 at 07:36:05PM -0400 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: , On Thu, Sep 11, 2003 at 07:36:05PM -0400, David McTavish wrote: | I agree with Ryan for all points except point 6, although, I believe that | this change would be easier to manage than in the initial proposal. | | d. David is right, I misread #6. That has the same problem as #3-5. Ryan | -----Original Message----- | From: Ryan Moats [mailto:rmoats@lemurnetworks.net] | Sent: Thursday, September 11, 2003 7:07 PM | To: Pana, Mircea | Cc: 'policy@ietf.org'; 'bwijnen@lucent.com' | Subject: Re: [Policy] PCLS classes deprecated in PCELS | | | On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote: | | IMO the usage of schema items corresponding to deprecated concepts would | be | | in conflict with the model (in this case PCIMe). However, a "peaceful | | co-existence" would be a very good reason for compromise. The following | | proposal gets PCELS out of the "policing business" and where compliance | with | | PCIMe requires PCLS classes or attributes not to be used, this is noted | with | | the specific indication "for compliance with PCIMe implementations | | shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will | find | | the following acceptable: | | | | 1. Replace the pcimGroupContainmentAuxClass class deprecation with a | | paragraph to indicate that "for compliance with PCIMe, implementations | shall | | use the pcimPolicySet.pcimPolicySetComponentList attribute and a | | subordinated pcimPolicySetAssociation entry instead of an attached | | pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy Group, | | Rule or System". | | | | 2. Replace the pcimRuleContainmentAuxClass class deprecation with a | | paragraph to indicate that "for compliance with PCIMe, implementations | | shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a | | subordinated pcimPolicySetAssociation entry instead of an attached | | pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy Group, | | Rule or System". | | I can live with these two... | | | 3. The pcimRule* classes would not be deprecated. Instead, the abstract | | class pcimRule would be modified to become a subclass of the abstract | class | | pcimPolicyRule defined in PCELS. A note would be added to indicate that | "for | | compliance with PCIMe, implementations shall not use the | | pcimRule.pcimRulePriority attribute". See also Note_1 below. | | | | 4. The class pcimRuleConditionAssociation would be modified to become | | subclass of the pcimConditionAssociation class. | | | | 5. The class pcimRuleActionAssociation would be modified to become | subclass | | of the pcimActionAssociation class. | | I can't live with these three: they would require me to change my working | implementation and change the PCLS schema. | | If you are going to do a subclass here and not break PCLS or existing | implementations, you have to go the other way: | pcimPolicyRule is a subclass of pcimRule, pcimConditionAssociation as a | subclass of pcimRuleConditionAssociation, etc. This changes Note #1 to | what are the issues for pcimPolicyRule... | | | 6. The pcimRepository* classes would not be deprecated. Instead the | abstract | | class pcimRepository would be modified to become subclass of the abstract | | class pcimReusableContainer defined in PCELS. PCELS would indicate that | "for | | compliance with PCIMe, the pcimReusableContainer* classes shall be used | | instead of the pcimRepository* classes". | | Again, I can live with #6. | | Ryan | | _______________________________________________ | Policy mailing list | Policy@ietf.org | https://www1.ietf.org/mailman/listinfo/policy | | _______________________________________________ | Policy mailing list | Policy@ietf.org | https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 10:31:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26390 for ; Fri, 12 Sep 2003 10:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xox7-0001WR-Nk for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 10:31:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CEVDSp005825 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 10:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xowx-0001RL-MP; Fri, 12 Sep 2003 10:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xows-0001Ps-Bl for policy@optimus.ietf.org; Fri, 12 Sep 2003 10:30:58 -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 KAA26252 for ; Fri, 12 Sep 2003 10:30:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xowp-0007VM-00 for policy@ietf.org; Fri, 12 Sep 2003 10:30:55 -0400 Received: from mx-relay21.treas.gov ([199.196.132.5]) by ietf-mx with esmtp (Exim 4.12) id 19xowo-0007V1-00 for policy@ietf.org; Fri, 12 Sep 2003 10:30:54 -0400 Received: from tias24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with ESMTP id h8CEFeFH019122; Fri, 12 Sep 2003 10:15:40 -0400 (EDT) Received: from mailhub.treas.gov by tias24.net.treas.gov via smtpd (for mx-relay21.treas.gov [199.196.132.5]) with ESMTP; Fri, 12 Sep 2003 10:30:45 -0400 Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-3.net.treas.gov (8.12.9/8.12.9) with ESMTP id h8CEUigN026956; Fri, 12 Sep 2003 10:30:44 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.8.11]) with ESMTP; Fri, 12 Sep 2003 14:30:39 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h8CEUUf14669; Fri, 12 Sep 2003 09:30:30 -0500 Message-ID: <3F61D886.60401@parnelli.indy.cr.irs.gov> Date: Fri, 12 Sep 2003 09:30:30 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pana, Mircea" CC: "'policy@ietf.org'" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Pana, Mircea wrote, On 09/05/03 08:19: [snip] > Does anybody have running code based on PCIM, PCLS, PCIMe? [snip] > Yes. We have running code which is dependent upon PCIM and PCLS. The code implements applications which are in production. They are used every day to support real work. -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz # # voice (317) 226-7060 # FAX (317) 226-6378 #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 10:44:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26920 for ; Fri, 12 Sep 2003 10:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xp9V-0002GY-Ts for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 10:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CEi1tL008684 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 10:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xp9V-0002Ff-Cb; Fri, 12 Sep 2003 10:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xp8s-0002Er-7M for policy@optimus.ietf.org; Fri, 12 Sep 2003 10:43:22 -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 KAA26880 for ; Fri, 12 Sep 2003 10:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xp8p-0007i2-00 for policy@ietf.org; Fri, 12 Sep 2003 10:43:19 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19xp8p-0007hz-00 for policy@ietf.org; Fri, 12 Sep 2003 10:43:19 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5396206; Fri, 12 Sep 2003 10:43:14 -0400 Message-Id: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Sep 2003 10:43:04 -0400 To: "Larry S. Bartz" , "Pana, Mircea" From: "Joel M. Halpern" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS Cc: "'policy@ietf.org'" In-Reply-To: <3F61D886.60401@parnelli.indy.cr.irs.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Given the discussion about the relationship between PCLS and the proposed PCELS, allow me to ask a naive question please. There were some significant structural changes introduced between PCIM and PCIMe. They were introduced to address problems with the PCIM structuring when other folks tried to use that as a basis for work. Folks seem (as I read the exchanges) to be objecting to the corresponding changes in the LDAP schema. Are the folks who implemented PCLS and are concerned about the changes expecting to support PCIMe? If you are expecting to support PCIMe, how would you expect to deal with the fact that there are structural changes in the underlying model? Yours, Joel M. Halpern speaking as an interested participant At 09:30 AM 9/12/2003 -0500, Larry S. Bartz wrote: >Pana, Mircea wrote, On 09/05/03 08:19: >[snip] >>Does anybody have running code based on PCIM, PCLS, PCIMe? >[snip] >> > >Yes. We have running code which is dependent upon PCIM and PCLS. The >code implements applications which are in production. They are used >every day to support real work. > > >-- >-- >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| ># Larry Bartz ># ># voice (317) 226-7060 ># FAX (317) 226-6378 >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > > >_______________________________________________ >Policy mailing list >Policy@ietf.org >https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 11:11:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27973 for ; Fri, 12 Sep 2003 11:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xpZp-0003HA-CD for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CFBDDH012566 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:11:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xpZe-0003GC-8O; Fri, 12 Sep 2003 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xpYn-0003EL-19 for policy@optimus.ietf.org; Fri, 12 Sep 2003 11:10:19 -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 LAA27912 for ; Fri, 12 Sep 2003 11:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xpYk-0000C2-00 for policy@ietf.org; Fri, 12 Sep 2003 11:10:06 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xpYj-0000Bi-00 for policy@ietf.org; Fri, 12 Sep 2003 11:10:05 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8CF7t203338; Fri, 12 Sep 2003 10:07:55 -0500 Date: Fri, 12 Sep 2003 10:07:55 -0500 From: Ryan Moats To: "Joel M. Halpern" Cc: "Larry S. Bartz" , "Pana, Mircea" , "'policy@ietf.org'" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS Message-ID: <20030912100755.B3093@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <3F61D886.60401@parnelli.indy.cr.irs.gov> <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com>; from joel@stevecrocker.com on Fri, Sep 12, 2003 at 10:43:04AM -0400 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: , On Fri, Sep 12, 2003 at 10:43:04AM -0400, Joel M. Halpern wrote: | Given the discussion about the relationship between PCLS and the proposed | PCELS, allow me to ask a naive question please. | | There were some significant structural changes introduced between PCIM and | PCIMe. They were introduced to address problems with the PCIM structuring | when other folks tried to use that as a basis for work. | Folks seem (as I read the exchanges) to be objecting to the corresponding | changes in the LDAP schema. | Are the folks who implemented PCLS and are concerned about the changes | expecting to support PCIMe? | If you are expecting to support PCIMe, how would you expect to deal with | the fact that there are structural changes in the underlying model? I am not expecting to support PCIMe. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 11:48:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28952 for ; Fri, 12 Sep 2003 11:48:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xq9T-0004Wa-5Q for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CFm3VG017393 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xq9Q-0004WA-Mk; Fri, 12 Sep 2003 11:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xq8p-0004VW-81 for policy@optimus.ietf.org; Fri, 12 Sep 2003 11:47:23 -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 LAA28923 for ; Fri, 12 Sep 2003 11:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xq8o-0000Yu-00 for policy@ietf.org; Fri, 12 Sep 2003 11:47:22 -0400 Received: from mx-relay21.treas.gov ([199.196.132.5]) by ietf-mx with esmtp (Exim 4.12) id 19xq8n-0000Yr-00 for policy@ietf.org; Fri, 12 Sep 2003 11:47:21 -0400 Received: from tias24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with ESMTP id h8CFWCFH010093; Fri, 12 Sep 2003 11:32:12 -0400 (EDT) Received: from mailhub.treas.gov by tias24.net.treas.gov via smtpd (for mx-relay21.treas.gov [199.196.132.5]) with ESMTP; Fri, 12 Sep 2003 11:47:18 -0400 Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-3.net.treas.gov (8.12.9/8.12.9) with ESMTP id h8CFlKgN023213; Fri, 12 Sep 2003 11:47:20 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.8.11]) with ESMTP; Fri, 12 Sep 2003 15:47:15 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h8CFlJf14754; Fri, 12 Sep 2003 10:47:19 -0500 Message-ID: <3F61EA87.70205@parnelli.indy.cr.irs.gov> Date: Fri, 12 Sep 2003 10:47:19 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" CC: "Pana, Mircea" , "'policy@ietf.org'" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS References: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> In-Reply-To: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Joel M. Halpern wrote, On 09/12/03 09:43: > Given the discussion about the relationship between PCLS and the > proposed PCELS, allow me to ask a naive question please. > > There were some significant structural changes introduced between PCIM > and PCIMe. They were introduced to address problems with the PCIM > structuring when other folks tried to use that as a basis for work. > Folks seem (as I read the exchanges) to be objecting to the > corresponding changes in the LDAP schema. > Are the folks who implemented PCLS and are concerned about the changes > expecting to support PCIMe? > If you are expecting to support PCIMe, how would you expect to deal with > the fact that there are structural changes in the underlying model? > I disagreed (in this forum) with some of the strategies of PCIMe. My concerns were not accomodated in the discussion or the design. Ultimately, I made a personal choice not to pursue my points further, as I recognize that intelligent, experienced, and reasonable people may disagree without causing harm. As far as I was concerned, PCIM and PCLS were already accomplished work, work with which I agreed, and work upon which I could (and did) build further. I have not experienced "problems with the PCIM structuring", quite the opposite. I have found PCIM and PCLS to be elegant, thorough, and highly serviceable designs. My work does not require the restructuring and additional complexity of PCIMe. Neither does my work require the QoS-specific components of PCIMe and PCELS. I don't have a requirement for PCIMe. I don't anticipate modifying my work to accomodate PCIMe. I see PCIMe as a departure from PCIM's simplicity and elegance. I see PCIMe as one of many possible elaborations upon PCIM's model. Even with that unfortunate "Update" word in RFC 3460, I still consider PCIM (RFC 3060) to be an authoritative document which describes a viable model. In the same spirit, I really want to see PCLS become an RFC. And I especially don't want PCELS to clobber it or impinge upon it in any way. -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz # # voice (317) 226-7060 # FAX (317) 226-6378 #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 11:57:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29259 for ; Fri, 12 Sep 2003 11:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqI9-0004rD-Pe for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:57:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CFv1aI018657 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 11:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqI9-0004qp-Hh; Fri, 12 Sep 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqI8-0004qb-9V for policy@optimus.ietf.org; Fri, 12 Sep 2003 11:57:00 -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 LAA29243 for ; Fri, 12 Sep 2003 11:56:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqI7-0000dO-00 for policy@ietf.org; Fri, 12 Sep 2003 11:56:59 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19xqI6-0000dL-00 for policy@ietf.org; Fri, 12 Sep 2003 11:56:58 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5396459; Fri, 12 Sep 2003 11:56:58 -0400 Message-Id: <5.1.0.14.0.20030912115219.02140738@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Sep 2003 11:56:51 -0400 To: "Larry S. Bartz" From: "Joel M. Halpern" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS Cc: "Pana, Mircea" , "'policy@ietf.org'" In-Reply-To: <3F61EA87.70205@parnelli.indy.cr.irs.gov> References: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , I think that there really are two separate questions. 1) Should PCLS be completed as a standards track RFC? As far as I know, everyone agrees that the answer to that is yes. 2) How should PCIMe be mapped to LDAP? My concern is taht you and others are holding that mapping up to a standard of PCLS compatibility that PCIMe itself does not meet. I may be mistaken, but I believe that the differences between PCIMe and PCIM are such that it is at best extremely difficult (and quite possibly impossible) to accurately map PCIMe to LDAP in a fashion compatible with PCLS. My feeling is that concerns about PCELS should be in the context of support for PCIMe, not in the context of support for PCIM without PCIMe. I can understand that you (and possibly others) disagreed with the rough consensus on PCIMe. But it is unfair to the PCELS authors to base objections to their mapping on objections to the differences and incompatibilities between PCIM and PCIMe. Yours, Joel M. Halpern PS: In contrast to my concern above, if one can accurately map PCIMe to LDAP in a way that is compatible with PCLS, then that would clearly seem desirable. At 10:47 AM 9/12/2003 -0500, Larry S. Bartz wrote: >Joel M. Halpern wrote, On 09/12/03 09:43: >>Given the discussion about the relationship between PCLS and the proposed >>PCELS, allow me to ask a naive question please. >>There were some significant structural changes introduced between PCIM >>and PCIMe. They were introduced to address problems with the PCIM >>structuring when other folks tried to use that as a basis for work. >>Folks seem (as I read the exchanges) to be objecting to the corresponding >>changes in the LDAP schema. >>Are the folks who implemented PCLS and are concerned about the changes >>expecting to support PCIMe? >>If you are expecting to support PCIMe, how would you expect to deal with >>the fact that there are structural changes in the underlying model? > > >I disagreed (in this forum) with some of the strategies of PCIMe. >My concerns were not accomodated in the discussion or the design. >Ultimately, I made a personal choice not to pursue my points further, >as I recognize that intelligent, experienced, and reasonable people >may disagree without causing harm. > >As far as I was concerned, PCIM and PCLS were already accomplished >work, work with which I agreed, and work upon which I could (and did) >build further. I have not experienced "problems with the PCIM >structuring", quite the opposite. I have found PCIM and PCLS to be >elegant, thorough, and highly serviceable designs. My work does not >require the restructuring and additional complexity of PCIMe. Neither >does my work require the QoS-specific components of PCIMe and PCELS. > >I don't have a requirement for PCIMe. I don't anticipate modifying >my work to accomodate PCIMe. > >I see PCIMe as a departure from PCIM's simplicity and elegance. I >see PCIMe as one of many possible elaborations upon PCIM's model. >Even with that unfortunate "Update" word in RFC 3460, I still consider >PCIM (RFC 3060) to be an authoritative document which describes a >viable model. > >In the same spirit, I really want to see PCLS become an RFC. And >I especially don't want PCELS to clobber it or impinge upon it >in any way. > > >-- >-- >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| ># Larry Bartz ># ># voice (317) 226-7060 ># FAX (317) 226-6378 >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 12:04:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29526 for ; Fri, 12 Sep 2003 12:04:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqPC-0005V5-Vh for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:04:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG4IpL021118 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:04:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqPB-0005UI-MI; Fri, 12 Sep 2003 12:04:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqOC-0005Qv-FW for policy@optimus.ietf.org; Fri, 12 Sep 2003 12:03:16 -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 MAA29481 for ; Fri, 12 Sep 2003 12:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqOB-0000iP-00 for policy@ietf.org; Fri, 12 Sep 2003 12:03:15 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xqOA-0000i4-00 for policy@ietf.org; Fri, 12 Sep 2003 12:03:14 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8CG1ac03688; Fri, 12 Sep 2003 11:01:36 -0500 Date: Fri, 12 Sep 2003 11:01:36 -0500 From: Ryan Moats To: "Joel M. Halpern" Cc: "Larry S. Bartz" , "Pana, Mircea" , "'policy@ietf.org'" Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS Message-ID: <20030912110136.I3093@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> <5.1.0.14.0.20030912103954.0214b5e8@mail.stevecrocker.com> <3F61EA87.70205@parnelli.indy.cr.irs.gov> <5.1.0.14.0.20030912115219.02140738@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20030912115219.02140738@mail.stevecrocker.com>; from joel@stevecrocker.com on Fri, Sep 12, 2003 at 11:56:51AM -0400 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: , On Fri, Sep 12, 2003 at 11:56:51AM -0400, Joel M. Halpern wrote: | I think that there really are two separate questions. | 1) Should PCLS be completed as a standards track RFC? As far as I know, | everyone agrees that the answer to that is yes. I certainly hope so... | 2) How should PCIMe be mapped to LDAP? My concern is taht you and others | are holding that mapping up to a standard of PCLS compatibility that PCIMe | itself does not meet. I may be mistaken, but I believe that the | differences between PCIMe and PCIM are such that it is at best extremely | difficult (and quite possibly impossible) to accurately map PCIMe to LDAP | in a fashion compatible with PCLS. My feeling is that concerns about PCELS | should be in the context of support for PCIMe, not in the context of | support for PCIM without PCIMe. When PCELS starts deprecating PCLS classes or changing the objectclass tree of PCLS objects then its changing PCLS. That's why I've been asking for textual words and having PCELS classes inherit from PCLS classes (rather than the other was around), so that PCELS could be discussed in terms of PCIMe and not PCIM as PCLS is left intact. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 12:16:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01214 for ; Fri, 12 Sep 2003 12:16:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqaZ-0008T0-R2 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:16:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGG3Xb032508 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:16:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqaZ-0008SE-HG; Fri, 12 Sep 2003 12:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqaI-0008Pw-6U for policy@optimus.ietf.org; Fri, 12 Sep 2003 12:15:46 -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 MAA01155 for ; Fri, 12 Sep 2003 12:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqaG-0001AH-00 for policy@ietf.org; Fri, 12 Sep 2003 12:15:44 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xqaF-00019W-00 for policy@ietf.org; Fri, 12 Sep 2003 12:15:44 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8CGF7v03756; Fri, 12 Sep 2003 11:15:07 -0500 Date: Fri, 12 Sep 2003 11:15:07 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: David McTavish , "'policy@ietf.org'" Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030912111507.K3093@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mpana@metasolv.com on Fri, Sep 12, 2003 at 11:01:33AM -0500 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: , On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote: | I would like to understand why you have a problem with PCELS inserting a new | class in the inheritance chain of a PCLS defined class. Because you've broken the binding between an LDAP object class's OID and an that object class's name. Included in this binding is the superior objectclass. Therefore ( NAME "pcimRepository" SUP top ) and ( NAME "pcimRepository" SUP pcimRulesContainer ) are *NOT* the same from an LDAP point of view: they require different OID and different names. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 12:29:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02170 for ; Fri, 12 Sep 2003 12:29:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqn8-0001LR-0p for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CGT1sU005134 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqn7-0001Ke-L8; Fri, 12 Sep 2003 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqmU-0001Is-Pk for policy@optimus.ietf.org; Fri, 12 Sep 2003 12:28:22 -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 MAA02119 for ; Fri, 12 Sep 2003 12:28:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqmT-0001UD-00 for policy@ietf.org; Fri, 12 Sep 2003 12:28:21 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xqmS-0001TU-00 for policy@ietf.org; Fri, 12 Sep 2003 12:28:20 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8CGRmN03798; Fri, 12 Sep 2003 11:27:48 -0500 Date: Fri, 12 Sep 2003 11:27:48 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: David McTavish , "'policy@ietf.org'" Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030912112748.O3093@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: <20030912111507.K3093@privateer.local.windrose.omaha.ne.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030912111507.K3093@privateer.local.windrose.omaha.ne.us>; from rmoats@lemurnetworks.net on Fri, Sep 12, 2003 at 11:15:07AM -0500 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: , On Fri, Sep 12, 2003 at 11:15:07AM -0500, Ryan Moats wrote: | On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote: | | I would like to understand why you have a problem with PCELS inserting a new | | class in the inheritance chain of a PCLS defined class. | | Because you've broken the binding between an LDAP object class's OID and | an that object class's name. Included in this binding is the superior | objectclass. Therefore | | ( NAME "pcimRepository" SUP top ) | | and | | ( NAME "pcimRepository" SUP pcimRulesContainer ) | | are *NOT* the same from an LDAP point of view: they require different | OID and different names. | | Ryan Actually, that is a solution for all of the subclass cases: in PCELS call tem pcime*, give them different OIDs from what's in PCLS and then everything is ok. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 13:40:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06385 for ; Fri, 12 Sep 2003 13:40:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrty-0006Yk-83 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 13:40:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CHe9Pt025206 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 13:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrtr-0006Xw-6w; Fri, 12 Sep 2003 13:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xrtJ-0006WO-4C for policy@optimus.ietf.org; Fri, 12 Sep 2003 13:39:29 -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 NAA06315 for ; Fri, 12 Sep 2003 13:39:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xrtG-0002qP-00 for policy@ietf.org; Fri, 12 Sep 2003 13:39:27 -0400 Received: from mx-relay21.treas.gov ([199.196.132.5]) by ietf-mx with esmtp (Exim 4.12) id 19xrtG-0002qL-00 for policy@ietf.org; Fri, 12 Sep 2003 13:39:26 -0400 Received: from tias24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with ESMTP id h8CHOHFH013452; Fri, 12 Sep 2003 13:24:17 -0400 (EDT) Received: from mailhub.treas.gov by tias24.net.treas.gov via smtpd (for [199.196.132.5]) with ESMTP; Fri, 12 Sep 2003 13:39:22 -0400 Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-3.net.treas.gov (8.12.9/8.12.9) with ESMTP id h8CHdNgN027138; Fri, 12 Sep 2003 13:39:24 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.8.11]) with ESMTP; Fri, 12 Sep 2003 17:39:18 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h8CHdNf14930; Fri, 12 Sep 2003 12:39:23 -0500 Message-ID: <3F6204CA.2050401@parnelli.indy.cr.irs.gov> Date: Fri, 12 Sep 2003 12:39:22 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'policy@ietf.org'" CC: rmoats@lemurnetworks.net, David McTavish , "Joel M. Halpern" , "Pana, Mircea" Subject: Re: [Policy] PCLS classes deprecated in PCELS References: <20030912111507.K3093@privateer.local.windrose.omaha.ne.us> <20030912112748.O3093@privateer.local.windrose.omaha.ne.us> In-Reply-To: <20030912112748.O3093@privateer.local.windrose.omaha.ne.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Ryan Moats wrote, On 09/12/03 11:27: [snip} > > Actually, that is a solution for all of the subclass cases: in PCELS call > tem pcime*, give them different OIDs from what's in PCLS and then everything > is ok. > I'll go further and suggest that every component of PCIMe which is not exactly as defined in PCLS should be prefixed "pcime". If PCELS simply avoids deprecating, renaming, or redefining anything from PCLS, there can be no conflict with PCLS. And if everything new which is introduced by PCELS is prefixed "pcime", there can be no confusion about which is "core" and which is "extension". Such a strategy will ultimately satisfy Joel's concerns, when he wrote: > My feeling is that concerns about PCELS should be in the context of > support for PCIMe, and > if one can accurately map PCIMe to LDAP in a way that is compatible > with PCLS, then that would clearly seem desirable PCELS should map PCIMe to LDAP in a way which is not INcompatible with PCLS, in a way which does not break PCLS. I agree that "concerns about PCELS should be in the context of support for PCIMe". I augment that by saying that PCELS should not be concerned with recasting PCLS in any way. PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any impact on PCLS. -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz # # voice (317) 226-7060 # FAX (317) 226-6378 #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 13:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06844 for ; Fri, 12 Sep 2003 13:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xs4U-0006ve-Ra for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 13:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CHp2xM026595 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 13:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xs4U-0006ur-FJ; Fri, 12 Sep 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xs3p-0006t4-A5 for policy@optimus.ietf.org; Fri, 12 Sep 2003 13:50:21 -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 NAA06779 for ; Fri, 12 Sep 2003 13:50:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xs3m-0002zN-00 for policy@ietf.org; Fri, 12 Sep 2003 13:50:18 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19xs3l-0002zD-00 for policy@ietf.org; Fri, 12 Sep 2003 13:50:18 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5396850; Fri, 12 Sep 2003 13:50:16 -0400 Message-Id: <5.1.0.14.0.20030912134749.0206c8b8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 12 Sep 2003 13:50:09 -0400 To: "Larry S. Bartz" , "'policy@ietf.org'" From: "Joel M. Halpern" Subject: Re: [Policy] PCLS classes deprecated in PCELS Cc: rmoats@lemurnetworks.net, David McTavish , "Pana, Mircea" In-Reply-To: <3F6204CA.2050401@parnelli.indy.cr.irs.gov> References: <20030912112748.O3093@privateer.local.windrose.omaha.ne.us> <20030912111507.K3093@privateer.local.windrose.omaha.ne.us> <20030912112748.O3093@privateer.local.windrose.omaha.ne.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , Ryan as just nicely explained this to me in a way that got it through my thick skull. You both are correct. We can not move existing classes. Hence, one needs to create new classes, and include text that says "use this instead of the old thing". Unfortunate, but really a common problem with class naming / inheritance (not specific to just LDAP). As I said to Ryan, thanks for the patience explaining this. Joel At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: >Ryan Moats wrote, On 09/12/03 11:27: >[snip} >>Actually, that is a solution for all of the subclass cases: in PCELS call >>tem pcime*, give them different OIDs from what's in PCLS and then everything >>is ok. > >I'll go further and suggest that every component of PCIMe which is >not exactly as defined in PCLS should be prefixed "pcime". If PCELS >simply avoids deprecating, renaming, or redefining anything from >PCLS, there can be no conflict with PCLS. And if everything new >which is introduced by PCELS is prefixed "pcime", there can be no >confusion about which is "core" and which is "extension". > >Such a strategy will ultimately satisfy Joel's concerns, when he wrote: > > My feeling is that concerns about PCELS should be in the context of > > support for PCIMe, >and > > if one can accurately map PCIMe to LDAP in a way that is compatible > > with PCLS, then that would clearly seem desirable > >PCELS should map PCIMe to LDAP in a way which is not INcompatible with >PCLS, in a way which does not break PCLS. I agree that "concerns about >PCELS should be in the context of support for PCIMe". I augment that >by saying that PCELS should not be concerned with recasting PCLS in >any way. > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any >impact on PCLS. > > >-- >-- >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| ># Larry Bartz ># ># voice (317) 226-7060 ># FAX (317) 226-6378 >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 17:16:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17032 for ; Fri, 12 Sep 2003 17:16:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvGv-00019w-SY for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 17:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CLG5fe004452 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 17:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvGr-00019V-0P; Fri, 12 Sep 2003 17:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvGE-00017m-J4 for policy@optimus.ietf.org; Fri, 12 Sep 2003 17:15:23 -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 RAA16991 for ; Fri, 12 Sep 2003 17:15:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvGC-0005sY-00 for policy@ietf.org; Fri, 12 Sep 2003 17:15:20 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19xvGB-0005ru-00 for policy@ietf.org; Fri, 12 Sep 2003 17:15:19 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Fri, 12 Sep 2003 16:19:07 -0500 Message-ID: From: "Pana, Mircea" To: "'Joel M. Halpern'" , "Larry S. Bartz" , "'policy@ietf.org'" Cc: rmoats@lemurnetworks.net, David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Fri, 12 Sep 2003 16:10:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37972.4DB1B3B0" 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_01C37972.4DB1B3B0 Content-Type: text/plain; charset="iso-8859-1" So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37972.4DB1B3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be = "OK" if PCELS did:

1. Define only subclasses of PCLS classes and, where = not possible, redefine PCLS concepts as new classes (use different = names and oid.s). This is already the case in the currently published = ID with the exception of pcimGroup* that would need to be redefined = with a different name. 

2. Use "for compliance with PCIMe = implementations SHALL use <list schema items> instead of <list = of schema items> for the realization of <concepts>" = instead of deprecating PCLS classes. This would be added to a new = revision of the ID.

I'm fine with both. (I hope I did not miss = anything)

Wrt. naming PCELS classes and attributes pcime* = instead of pcim*, as long as there are no naming conflicts, I would = prefer to avoid it if possible. Could you live with that? However if we = have to do it for one item we should do it for all.

Thanks,
Mircea.




> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]<= /FONT>
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; = Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
>
> Ryan as just nicely explained this to me in a = way that got it
> through my
> thick skull.  You both are correct.  = We can not move existing classes.
>
> Hence, one needs to create new classes, and = include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with = class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience = explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz = wrote:
> >Ryan Moats wrote, On 09/12/03 11:27:
> >[snip}
> >>Actually, that is a solution for all of = the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs = from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every = component of PCIMe which is
> >not exactly as defined in PCLS should be = prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or = redefining anything from
> >PCLS, there can be no conflict with PCLS. = And if everything new
> >which is introduced by PCELS is prefixed = "pcime", there can be no
> >confusion about which is "core" = and which is "extension".
> >
> >Such a strategy will ultimately satisfy = Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about = PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to = LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly = seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way = which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I = agree that
> "concerns about
> >PCELS should be in the context of support = for PCIMe". I augment that
> >by saying that PCELS should not be = concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to = LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> = >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::=
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) = 226-6378
> = >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::=
> ::::::::::|
>
>
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37972.4DB1B3B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 12 17:32:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17637 for ; Fri, 12 Sep 2003 17:32:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvWL-00023X-SG for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 17:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CLW1eP007867 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 17:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvWL-00022n-Fz; Fri, 12 Sep 2003 17:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xvVU-00021o-3h for policy@optimus.ietf.org; Fri, 12 Sep 2003 17:31:08 -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 RAA17557 for ; Fri, 12 Sep 2003 17:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xvVR-00064K-00 for policy@ietf.org; Fri, 12 Sep 2003 17:31:05 -0400 Received: from tconl91223.tconl.com ([204.26.91.223]) by ietf-mx with esmtp (Exim 4.12) id 19xvVQ-00063r-00 for policy@ietf.org; Fri, 12 Sep 2003 17:31:05 -0400 Received: (from jayhawk@localhost) by tconl91223.tconl.com (8.11.6/8.11.0) id h8CLUKr01992; Fri, 12 Sep 2003 16:30:20 -0500 Date: Fri, 12 Sep 2003 16:30:20 -0500 From: Ryan Moats To: "Pana, Mircea" Cc: "'Joel M. Halpern'" , "Larry S. Bartz" , "'policy@ietf.org'" , David McTavish Subject: Re: [Policy] PCLS classes deprecated in PCELS Message-ID: <20030912163020.A1660@privateer.local.windrose.omaha.ne.us> Reply-To: rmoats@lemurnetworks.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mpana@metasolv.com on Fri, Sep 12, 2003 at 04:10:33PM -0500 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: , On Fri, Sep 12, 2003 at 04:10:33PM -0500, Pana, Mircea wrote: | So, if I understand correctly, everything would be "OK" if PCELS did: | | 1. Define only subclasses of PCLS classes and, where not possible, redefine | PCLS concepts as new classes (use different names and oid.s). This is | already the case in the currently published ID with the exception of | pcimGroup* that would need to be redefined with a different name. | 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " | instead of deprecating PCLS classes. This would be added to a new revision | of the ID. | | I'm fine with both. (I hope I did not miss anything) | | Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as | there are no naming conflicts, I would prefer to avoid it if possible. Could | you live with that? However if we have to do it for one item we should do it | for all. | It might confuse future implementers to reuse "pcim", but I'm unsure if that is a valid technical reason for avoiding reuse. Ryan _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27712 for ; Mon, 15 Sep 2003 09:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073B-D6 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG8Ai026945 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD1-0006xb-VD; Mon, 15 Sep 2003 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCO-0006sd-Bd for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:24 -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 JAA27671 for ; Mon, 15 Sep 2003 09:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCM-00055k-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:22 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCL-00052d-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:21 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: "Pana, Mircea" , "'policy@ietf.org'" Cc: "'bwijnen@lucent.com'" , "'rmoats@lemurnetworks.net'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.53174390" 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_01C37B8B.53174390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see comments inline. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com]=20 Sent: Thursday, September 11, 2003 4:22 PM To: 'policy@ietf.org' Cc: 'bwijnen@lucent.com'; 'rmoats@lemurnetworks.net' Subject: RE: [Policy] PCLS classes deprecated in PCELS IMO the usage of schema items corresponding to deprecated concepts = would be in conflict with the model (in this case PCIMe). Au contraire, it is inappropriate to deprecate LDAP schema. You have a tough choice - try and design a true update of PCLS, or say = "Gee, since PCIMe changed the playing rules, so can we. Unfortunately, what = you've done is try to do both - build a new design under the guise of an = "update", and it doesn't work. You need to choose one approach or the other. And = if you choose update, then you need to be compatible with PCLS. Currently, you're not. However, a "peaceful co-existence" would be a very good reason for compromise. The following proposal gets PCELS out of the "policing = business" and where compliance with PCIMe requires PCLS classes or attributes not = to be used, this is noted with the specific indication "for compliance = with PCIMe implementations shall/shall not use ..." (or rather SHALL / SHALL NOT). I hope you will find the following acceptable: But you STILL need to choose one approach or the other, see below = 1. Replace the pcimGroupContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe, implementations = shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy = Group, Rule or System". 2. Replace the pcimRuleContainmentAuxClass class deprecation with a paragraph to indicate that "for compliance with PCIMe,=A0 = implementations shall use the pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated pcimPolicySetAssociation entry instead of an attached pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy = Group, Rule or System".=20 Upper case SHALL, or just a plain "shall"? 3. The pcimRule* classes would not be deprecated. Instead, the abstract class pcimRule would be modified to become a subclass of the abstract = class pcimPolicyRule defined in PCELS. A note would be added to indicate that = "for compliance with PCIMe, implementations shall not use the pcimRule.pcimRulePriority attribute". See also Note_1 below. 4. The class pcimRuleConditionAssociation would be modified to become subclass of the pcimConditionAssociation class.=20 5. The class pcimRuleActionAssociation would be modified to become = subclass of the pcimActionAssociation class.=20 6. The pcimRepository* classes would not be deprecated. Instead the = abstract class pcimRepository would be modified to become subclass of the = abstract class pcimReusableContainer defined in PCELS. PCELS would indicate that = "for compliance with PCIMe, the pcimReusableContainer* classes shall be used instead of the pcimRepository* classes". These are exactly backwards. A PolicyRule is-a special type of = Rule. Same problem with 4 and 5 - for example, in the old QPIM work, we had defined the concept of a condition in a condition. Thus, there is (or = at least could be) a marked difference between a condition and a = ruleCondition. Regarding pcimRepository, it shares two things with the other classes = in 3-5 - in the LDAP sense, it is exactly backwards, and your proposal ensures incompatibility. Note_1:=20 Without other changes, the pcimRule would end up having redundant functionality:=20 - pcimRuleConditionList and pcimConditionList for aggregating = conditions=20 - pcimRuleActionList and pcimActionList for aggregating actions=20 etc.=20 This assumes that the semantics of aggregating a condition in a = rule are the same as aggregating a condition in other types of objects. I, = for one, disagree with that assumption. A. One option would be to do nothing about it but this may lead to = ambiguous situations :-(=20 B. A second option would be to use the pcimRuleConditionAssociation and = the pcimRuleActionAssociation attributes and the association classes = defined by PCLS in the definition of the pcimPolicyRule. In this case the pcimPolicyRule* and pcimCompound*AuxClass would not use the same = attributes and association classes to aggregate Conditions and Actions :-( C. A third option would be to change the pcimPolicyRule definition to:=20 =A0=A0 ( [...] SUP pcimPolicySet=20 =A0=A0=A0=A0 ABSTRACT=20 =A0=A0=A0=A0 MAY ( pcimRuleName=20 =A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleEnabled=20 =A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleValidityPeriodList=20 =A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleUsage=20 =A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleMandatory )=20 =A0=A0 )=20 (Condition and Action aggregation attributes removed from the Rule = class)=20 In this case, PCELS would recommend the use of attached pcimCompound*AuxClass instances as means to aggregate multiple Actions/Conditions to a Rule. D. A mix of the previous two: Option B with a note that implementations = MAY choose to support only C.=20 Comments and suggestions would be greatly appreciated? Also, I would = greatly appreciate the PCIMe author's opinion wrt. the [non]deprecation. Your choice depends on whether you believe that we're done, or = that their may be future implementations that want to further refine the semantics that PCIMe has defined. Your choice must also consider compatibility with previous PCLS implementations. Since I'm working on = one of those "future" implementations, I would rather see a generic = condition aggregation defined, with the particular case of a policyCondition aggregated by a policyRule treated as a specialization of that generic aggregation. Thanks,=20 Mircea.=20 =A0=20 > -----Original Message-----=20 > From: Ryan Moats [mailto:rmoats@lemurnetworks.net]=20 > Sent: Tuesday, September 09, 2003 10:26 AM=20 > To: Pana, Mircea=20 > Cc: 'bwijnen@lucent.com'; 'policy@ietf.org'=20 > Subject: Re: [Policy] PCLS classes deprecated in PCELS=20 >=20 >=20 > On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote:=20 > | PCELS deprecates some of the PCLS classes and attributes for = various=20 > | reasons. In some cases, deprecation could have been avoided=20 > but in other=20 > | cases this was dictated by PCIMe. (details discussed below)=20 > I agree that=20 > | deprecation might create backward compatibility problems=20 > where PCELS and=20 > | PCLS implementations attempt to cooperate. BTW, does=20 > anybody out there have=20 > | such requirements? Given that PCIMe deprecates a=20 > significant number of=20 > | concepts from PCIM, is such cooperation even possible?=20 > |=20 > | The classes deprecated by PCELS are discussed below:=20 > |=20 > | 1. The class pcimGroupContainmentAuxClass defined by PCLS=20 > provides a single,=20 > | multi-valued attribute that references a set of pcimGroups.=20 > This unordered=20 > | aggregation mechanism can not be reused in implementations=20 > of PCIMe because=20 > | the model (PCIMe) requires PolicySetComponent associations to be=20 > | prioritized:=20 > | "=A0 5.5. Priorities and Decision Strategies=20 > |=A0=A0=A0 [...] Unlike the earlier definition,=20 > |=A0=A0=A0 PolicySetComponent.Priority MUST have a unique value=20 > when compared=20 > |=A0=A0=A0 with others defined for the same aggregating PolicySet.=A0 = > Thus, the=20 > |=A0=A0=A0 evaluation of rules within a set is deterministically=20 > specified. "=20 > | If PCELS allowed pcimGroupContainmentAuxClass, then it=20 > would be conflicting=20 > | with PCIMe.=20 > |=20 > | 2. The class pcimRuleContainmentAuxClass defined in PCLS is=20 > deprecated by=20 > | PCELS for the same reasons.=20 >=20 > Those are not reason to deprecate classes in the more general=20 > model.=A0 That's=20 > a reason to say "in this space, this other class should be used".=20 >=20 > | 3. The pcimRule* classes defined by PCLS are deprecated and=20 > redefined as=20 > | pcimPolicyRule* in PCELS. According to PCIMe the = PolicyRule.Priority=20 > | property is deprecated. Therefore PCELS redefines the=20 > PolicyRule class=20 > | mainly for removing the Priority attribute. An other option=20 > would have been=20 > | to leave pcimRule* as they are and then PCELS would have=20 > had to specify that=20 > | the pcimRulePriority attribute MUST NOT be used - a less=20 > formal solution=20 > | that does not prevent accidental use of the deprecated attribute.=20 > |=20 > | An other reason for replacing the pcimRule* classes is the=20 > renaming of the=20 > | attributes that serve in the Rule-Condition and Rule-Action=20 > associations.=20 > | pcimRuleConditionList is replaced by pcimConditionList and=20 > | pcimRuleActionList is replaced by pcimActionList. Thus, the=20 > new attributes=20 > | along with the new association classes (discussed below)=20 > offer a generic=20 > | mechanism for aggregating Conditions or Actions. The use the same=20 > | Condition/Action aggregation mechanism for both Policy=20 > Rules and Compound=20 > | Conditions/Action is an optimization in line with the=20 > Policy*Structure=20 > | concepts defined by PCIMe.=20 >=20 > Since you are rethinking subclass/deprication below, I'd=20 > argue rethink it=20 > here.=20 >=20 > | The deprecation of the pcimRule* classes is certainly not=20 > the only option=20 > | but based on our experience implementing PCIMe this one=20 > seemed an acceptable=20 > | compromise. However, any opinions or suggestions from the=20 > WG based on their=20 > | experience would be greatly appreciated.=20 > |=20 > | 4. The class pcimRuleConditionAssociation defined by PCLS=20 > has probably less=20 > | reasons to be deprecated. It was done simply to keep the Condition=20 > | aggregation (into rules or compound conditions) limited to a single = > | association class. Now, looking from this different=20 > prospective, I think=20 > | that it is a good idea to retain it.=20 > |=20 > | So, I suggest the modification of the=20 > pcimRuleConditionAssociation to become=20 > | a subclass of the pcimConditionAssociation already defined=20 > in PCELS. The=20 > | attributes of the pcimRuleConditionAssociation, all=20 > inherited from its=20 > | superclass, would end up being the same ones as previously=20 > defined by PCLS.=20 > | Thus, for aggregating Conditions into a Policy Rule, one=20 > would have the=20 > | choice of using pcimConditionAssociation or=20 > pcimRuleConditionAssociation=20 > | while Condition aggregation into a Compound Condition would=20 > be realized only=20 > | through the pcimConditionAssociation class.=20 > |=20 > | 5. pcimRuleActionAssociation - same suggestion as for the=20 > | pcimRuleConditionAssociation class=20 >=20 > This is a much better solution...=20 >=20 > | 6. The pcimRepository class defined by PCLS is deprecated=20 > by PCELS for=20 > | reasons described in PCIMe:=20 > | "=A0=A0 Because of the potential for confusion with the Policy = Framework=20 > |=A0=A0=A0 component Policy Repository (from the four-box picture: = Policy=20 > |=A0=A0=A0 Management Tool, Policy Repository, PDP, PEP),=20 > "PolicyRepository" is=20 > |=A0=A0=A0 a bad name for the PCIM class representing a container=20 > of reusable=20 > |=A0=A0=A0 policy elements.=A0 Thus the class PolicyRepository is=20 > being replaced=20 > |=A0=A0=A0 with the class ReusablePolicyContainer."=20 >=20 > This could also be handled with a subclass.=20 >=20 > Ryan=20 >=20 > _______________________________________________=20 > Policy mailing list=20 > Policy@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/policy=20 >=20 ------_=_NextPart_001_01C37B8B.53174390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

Please see comments inline.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com] =
Sent: Thursday, September 11, 2003 4:22 PM
To: 'policy@ietf.org'
Cc: 'bwijnen@lucent.com'; = 'rmoats@lemurnetworks.net'
Subject: RE: [Policy] PCLS classes deprecated in = PCELS

IMO the usage of schema items corresponding to = deprecated concepts would be in conflict with the model (in this case = PCIMe).

<js> Au contraire, it is inappropriate to = deprecate LDAP schema.

You have a tough choice - try and design a true = update of PCLS, or say "Gee, since PCIMe changed the playing = rules, so can we. Unfortunately, what you've done is try to do both - = build a new design under the guise of an "update", and it = doesn't work. You need to choose one approach or the other. And if you = choose update, then you need to be compatible with PCLS. Currently, = you're not. </js>

However, a "peaceful co-existence" would be = a very good reason for compromise. The following proposal gets PCELS = out of the "policing business" and where compliance with = PCIMe requires PCLS classes or attributes not to be used, this is noted = with the specific indication "for compliance with PCIMe = implementations shall/shall not use ..." (or rather SHALL / SHALL = NOT). I hope you will find the following acceptable:

<js> But you STILL need to choose one approach = or the other, see below </js>

1. Replace the pcimGroupContainmentAuxClass class = deprecation with a paragraph to indicate that "for compliance with = PCIMe, implementations shall use the = pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated = pcimPolicySetAssociation entry instead of an attached = pcimGroupContainmentAuxClass to aggregate Policy Groups in a Policy = Group, Rule or System".

2. Replace the pcimRuleContainmentAuxClass class = deprecation with a paragraph to indicate that "for compliance with = PCIMe,=A0 implementations shall use the = pcimPolicySet.pcimPolicySetComponentList attribute and a subordinated = pcimPolicySetAssociation entry instead of an attached = pcimRuleContainmentAuxClass to aggregate Policy Rules in a Policy = Group, Rule or System".

<js> Upper case SHALL, or just a plain = "shall"? </js>

3. The pcimRule* classes would not be deprecated. = Instead, the abstract class pcimRule would be modified to become a = subclass of the abstract class pcimPolicyRule defined in PCELS. A note = would be added to indicate that "for compliance with PCIMe, = implementations shall not use the pcimRule.pcimRulePriority = attribute". See also Note_1 below.

4. The class pcimRuleConditionAssociation would be = modified to become subclass of the pcimConditionAssociation class. =
5. The class pcimRuleActionAssociation would be = modified to become subclass of the pcimActionAssociation class.
6. The pcimRepository* classes would not be = deprecated. Instead the abstract class pcimRepository would be modified = to become subclass of the abstract class pcimReusableContainer defined = in PCELS. PCELS would indicate that "for compliance with PCIMe, = the pcimReusableContainer* classes shall be used instead of the = pcimRepository* classes".

<js> These are exactly backwards. A PolicyRule = is-a special type of Rule. Same problem with 4 and 5 - for example, in = the old QPIM work, we had defined the concept of a condition in a = condition. Thus, there is (or at least could be) a marked difference = between a condition and a ruleCondition.

Regarding pcimRepository, it shares two things with = the other classes in 3-5 - in the LDAP sense, it is exactly backwards, = and your proposal ensures incompatibility. </js>

Note_1:
Without other changes, the pcimRule would end up = having redundant functionality:
- pcimRuleConditionList and pcimConditionList for = aggregating conditions
- pcimRuleActionList and pcimActionList for = aggregating actions
etc.

<js> This assumes that the semantics of = aggregating a condition in a rule are the same as aggregating a = condition in other types of objects. I, for one, disagree with that = assumption. </js>

A. One option would be to do nothing about it but = this may lead to ambiguous situations :-(
B. A second option would be to use the = pcimRuleConditionAssociation and the pcimRuleActionAssociation = attributes and the association classes defined by PCLS in the = definition of the pcimPolicyRule. In this case the pcimPolicyRule* and = pcimCompound*AuxClass would not use the same attributes and association = classes to aggregate Conditions and Actions :-(

C. A third option would be to change the = pcimPolicyRule definition to:
=A0=A0 ( [...] SUP pcimPolicySet
=A0=A0=A0=A0 ABSTRACT
=A0=A0=A0=A0 MAY ( pcimRuleName
=A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleEnabled
=A0=A0=A0=A0=A0=A0=A0=A0 $ = pcimRuleValidityPeriodList
=A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleUsage
=A0=A0=A0=A0=A0=A0=A0=A0 $ pcimRuleMandatory ) =
=A0=A0 )
(Condition and Action aggregation attributes removed = from the Rule class)
In this case, PCELS would recommend the use of = attached pcimCompound*AuxClass instances as means to aggregate multiple = Actions/Conditions to a Rule.

D. A mix of the previous two: Option B with a note = that implementations MAY choose to support only C.
Comments and suggestions would be greatly = appreciated? Also, I would greatly appreciate the PCIMe author's = opinion wrt. the [non]deprecation.

<js> Your choice depends on whether you believe = that we're done, or that their may be future implementations that want = to further refine the semantics that PCIMe has defined. Your choice = must also consider compatibility with previous PCLS implementations. = Since I'm working on one of those "future" implementations, I = would rather see a generic condition aggregation defined, with the = particular case of a policyCondition aggregated by a policyRule treated = as a specialization of that generic aggregation. </js>

Thanks,
Mircea.

=A0
> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Tuesday, September 09, 2003 10:26 AM =
> To: Pana, Mircea
> Cc: 'bwijnen@lucent.com'; 'policy@ietf.org' =
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
>
> On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, = Mircea wrote:
> | PCELS deprecates some of the PCLS classes and = attributes for various
> | reasons. In some cases, deprecation could = have been avoided
> but in other
> | cases this was dictated by PCIMe. (details = discussed below)
> I agree that
> | deprecation might create backward = compatibility problems
> where PCELS and
> | PCLS implementations attempt to cooperate. = BTW, does
> anybody out there have
> | such requirements? Given that PCIMe = deprecates a
> significant number of
> | concepts from PCIM, is such cooperation even = possible?
> |
> | The classes deprecated by PCELS are discussed = below:
> |
> | 1. The class pcimGroupContainmentAuxClass = defined by PCLS
> provides a single,
> | multi-valued attribute that references a set = of pcimGroups.
> This unordered
> | aggregation mechanism can not be reused in = implementations
> of PCIMe because
> | the model (PCIMe) requires PolicySetComponent = associations to be
> | prioritized:
> | "=A0 5.5. Priorities and Decision = Strategies
> |=A0=A0=A0 [...] Unlike the earlier definition, =
> |=A0=A0=A0 PolicySetComponent.Priority MUST = have a unique value
> when compared
> |=A0=A0=A0 with others defined for the same = aggregating PolicySet.=A0
> Thus, the
> |=A0=A0=A0 evaluation of rules within a set is = deterministically
> specified. "
> | If PCELS allowed = pcimGroupContainmentAuxClass, then it
> would be conflicting
> | with PCIMe.
> |
> | 2. The class pcimRuleContainmentAuxClass = defined in PCLS is
> deprecated by
> | PCELS for the same reasons.
>
> Those are not reason to deprecate classes in = the more general
> model.=A0 That's
> a reason to say "in this space, this other = class should be used".
>
> | 3. The pcimRule* classes defined by PCLS are = deprecated and
> redefined as
> | pcimPolicyRule* in PCELS. According to PCIMe = the PolicyRule.Priority
> | property is deprecated. Therefore PCELS = redefines the
> PolicyRule class
> | mainly for removing the Priority attribute. = An other option
> would have been
> | to leave pcimRule* as they are and then PCELS = would have
> had to specify that
> | the pcimRulePriority attribute MUST NOT be = used - a less
> formal solution
> | that does not prevent accidental use of the = deprecated attribute.
> |
> | An other reason for replacing the pcimRule* = classes is the
> renaming of the
> | attributes that serve in the Rule-Condition = and Rule-Action
> associations.
> | pcimRuleConditionList is replaced by = pcimConditionList and
> | pcimRuleActionList is replaced by = pcimActionList. Thus, the
> new attributes
> | along with the new association classes = (discussed below)
> offer a generic
> | mechanism for aggregating Conditions or = Actions. The use the same
> | Condition/Action aggregation mechanism for = both Policy
> Rules and Compound
> | Conditions/Action is an optimization in line = with the
> Policy*Structure
> | concepts defined by PCIMe.
>
> Since you are rethinking subclass/deprication = below, I'd
> argue rethink it
> here.
>
> | The deprecation of the pcimRule* classes is = certainly not
> the only option
> | but based on our experience implementing = PCIMe this one
> seemed an acceptable
> | compromise. However, any opinions or = suggestions from the
> WG based on their
> | experience would be greatly appreciated. =
> |
> | 4. The class pcimRuleConditionAssociation = defined by PCLS
> has probably less
> | reasons to be deprecated. It was done simply = to keep the Condition
> | aggregation (into rules or compound = conditions) limited to a single
> | association class. Now, looking from this = different
> prospective, I think
> | that it is a good idea to retain it.
> |
> | So, I suggest the modification of the
> pcimRuleConditionAssociation to become
> | a subclass of the pcimConditionAssociation = already defined
> in PCELS. The
> | attributes of the = pcimRuleConditionAssociation, all
> inherited from its
> | superclass, would end up being the same ones = as previously
> defined by PCLS.
> | Thus, for aggregating Conditions into a = Policy Rule, one
> would have the
> | choice of using pcimConditionAssociation or =
> pcimRuleConditionAssociation
> | while Condition aggregation into a Compound = Condition would
> be realized only
> | through the pcimConditionAssociation class. =
> |
> | 5. pcimRuleActionAssociation - same = suggestion as for the
> | pcimRuleConditionAssociation class
>
> This is a much better solution...
>
> | 6. The pcimRepository class defined by PCLS = is deprecated
> by PCELS for
> | reasons described in PCIMe:
> | "=A0=A0 Because of the potential for = confusion with the Policy Framework
> |=A0=A0=A0 component Policy Repository (from = the four-box picture: Policy
> |=A0=A0=A0 Management Tool, Policy Repository, = PDP, PEP),
> "PolicyRepository" is
> |=A0=A0=A0 a bad name for the PCIM class = representing a container
> of reusable
> |=A0=A0=A0 policy elements.=A0 Thus the class = PolicyRepository is
> being replaced
> |=A0=A0=A0 with the class = ReusablePolicyContainer."
>
> This could also be handled with a subclass. =
>
> Ryan
>
> _______________________________________________ =
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy =
>

------_=_NextPart_001_01C37B8B.53174390-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27713 for ; Mon, 15 Sep 2003 09:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073C-DM for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG8Ju026962 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD2-0006xu-Qf; Mon, 15 Sep 2003 09:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCJ-0006rt-As for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:25 -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 JAA27662 for ; Mon, 15 Sep 2003 09:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCH-000555-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:17 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCG-00051T-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:16 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:39 -0600 Message-ID: From: John Strassner To: rmoats@lemurnetworks.net, "Joel M. Halpern" Cc: "Larry S. Bartz" , "Pana, Mircea" , "'policy@ietf.org'" Subject: RE: [Policy] RE: PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.5082DD10" 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_01C37B8B.5082DD10 Content-Type: text/plain I have to agree with Ryan, Larry and David. I find the notion of deprecation in PCELS unfortunate and technically NOT a good idea. I agree with Ryan's points on this email, and could add even more, but see that as beating a dead horse. With respect to the two questions asked: 1) PCLS should, in my opinion, be completed as a standards track document 2) An extension document, by definition, further refines the original document. It does not fold, spindle, and mutilate the original document. IF there are fundamental reasons why the original document cannot be extended, then the problem should be corrected in the original document, NOT by building an incompatible new document. 3) Thus, I agree with Ryan: when PCELS starts deprecating PCLS classes or changing the PCLS objectclass tree, then it is changing PCLS and it is impossible to then say that PCELS is an **extension** of PCLS. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Friday, September 12, 2003 10:02 AM > To: Joel M. Halpern > Cc: Larry S. Bartz; Pana, Mircea; 'policy@ietf.org' > Subject: Re: [Policy] RE: PCLS classes deprecated in PCELS > > On Fri, Sep 12, 2003 at 11:56:51AM -0400, Joel M. Halpern wrote: > | I think that there really are two separate questions. > | 1) Should PCLS be completed as a standards track RFC? As far as > I know, > | everyone agrees that the answer to that is yes. > > I certainly hope so... > > | 2) How should PCIMe be mapped to LDAP? My concern is taht you > and others > | are holding that mapping up to a standard of PCLS compatibility > that PCIMe > | itself does not meet. I may be mistaken, but I believe that the > | differences between PCIMe and PCIM are such that it is at best > extremely > | difficult (and quite possibly impossible) to accurately map PCIMe > to LDAP > | in a fashion compatible with PCLS. My feeling is that concerns > about PCELS > | should be in the context of support for PCIMe, not in the context > of > | support for PCIM without PCIMe. > > When PCELS starts deprecating PCLS classes or changing the > objectclass tree of > PCLS objects then its changing PCLS. That's why I've been asking > for textual > words and having PCELS classes inherit from PCLS classes (rather > than the > other was around), so that PCELS could be discussed in terms of > PCIMe and > not PCIM as PCLS is left intact. > > Ryan > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.5082DD10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] RE: PCLS classes deprecated in PCELS

I have to agree with Ryan, Larry and David. I find = the notion of deprecation in PCELS unfortunate and technically NOT a = good idea. I agree with Ryan's points on this email, and could add even = more, but see that as beating a dead horse.

With respect to the two questions asked:

  1) PCLS should, in my opinion, be completed as = a standards
     track document
  2) An extension document, by definition, = further refines the
     original document. It does = not fold, spindle, and mutilate
     the original document. IF = there are fundamental reasons
     why the original document = cannot be extended, then the
     problem should be corrected = in the original document, NOT
     by building an incompatible = new document.
  3) Thus, I agree with Ryan: when PCELS starts = deprecating
     PCLS classes or changing = the PCLS objectclass tree, then
     it is changing PCLS and it = is impossible to then say that
     PCELS is an **extension** = of PCLS.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Friday, September 12, 2003 10:02 = AM
> To: Joel M. Halpern
> Cc: Larry S. Bartz; Pana, Mircea; = 'policy@ietf.org'
> Subject: Re: [Policy] RE: PCLS classes = deprecated in PCELS
>
> On Fri, Sep 12, 2003 at 11:56:51AM -0400, Joel = M. Halpern wrote:
> | I think that there really are two separate = questions.
> | 1) Should PCLS be completed as a standards = track RFC?  As far as
> I know,
> | everyone agrees that the answer to that is = yes.
>
> I certainly hope so...
>
> | 2) How should PCIMe be mapped to LDAP?  = My concern is taht you
> and others
> | are holding that mapping up to a standard of = PCLS compatibility
> that PCIMe
> | itself does not meet.  I may be = mistaken, but I believe that the
> | differences between PCIMe and PCIM are such = that it is at best
> extremely
> | difficult (and quite possibly impossible) to = accurately map PCIMe
> to LDAP
> | in a fashion compatible with PCLS.  My = feeling is that concerns
> about PCELS
> | should be in the context of support for = PCIMe, not in the context
> of
> | support for PCIM without PCIMe.
>
> When PCELS starts deprecating PCLS classes or = changing the
> objectclass tree of
> PCLS objects then its changing PCLS. That's why = I've been asking
> for textual
> words and having PCELS classes inherit from = PCLS classes (rather
> than the
> other was around), so that PCELS could be = discussed in terms of
> PCIMe and
> not PCIM as PCLS is left intact.
>
> Ryan
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.5082DD10-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:16:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27714 for ; Mon, 15 Sep 2003 09:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073F-E3 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG9Bk026960 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD1-0006xG-2c; Mon, 15 Sep 2003 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCJ-0006ro-25 for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:19 -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 JAA27659 for ; Mon, 15 Sep 2003 09:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCH-000556-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:17 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCG-00051S-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:16 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:39 -0600 Message-ID: From: John Strassner To: "Larry S. Bartz" , "Wijnen, Bert (Bert)" Cc: policy@ietf.org Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt Date: Mon, 15 Sep 2003 07:14:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.4C0A4D40" 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_01C37B8B.4C0A4D40 Content-Type: text/plain I've been away for awhile, but am commenting because Bert asked for comments from the original authors. I agree with Larry and Ryan. There is no technical justification for deprecating these classes. In rereading the draft, I would go further and state that there some of the restructuring may not be a good idea; however, I want to reread this one last time and then I will provide detailed comments. Finally, Kurt is absolutely correct - deprecation is inappropriate in an LDAP schema standards document. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] > Sent: Friday, August 29, 2003 3:24 PM > To: Wijnen, Bert (Bert) > Cc: policy@ietf.org > Subject: Re: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > Wijnen, Bert (Bert) wrote, On 08/29/03 10:14: > > What an underwhelming interest in this document. > > > > When I start reading it, I see in the abstract: > > This document defines a number of changes and extensions to > the > > Policy Core LDAP Schema [PCLS] based on the specifications of > the > > Policy Core Information Model Extensions [PCIM_EXT]. The > changes > > include additional object classes previously not covered, > deprecation > > of some object classes and changes to the object class > hierarchy > > defined in [PCLS]. > > > > And so I immediately wonder... is it really OK that this document > > deprecates some object classes ?? > > > > Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT > and > > PCLS authors/ediotrs to explicitly say so. PLEASE! > > > > Thanks, > > Bert > > > I argued several months ago that it is actually unnecessary to > deprecate any of PCLS's information components. There are no > naming clashes with PCLS components. The proposed deprecation > only insures that PCLS and this schema will not be able to > co-exist in the same Directory implementations. This is counter > to the spirit of "extension". It casts a negative light on an > elegant and highly serviceable information model and schema > definition. > > Further, another commenter (I believe it was Kurt Zielenga) > asserted > that the specification of deprecation is inappropriate in a schema > standards document. Rather, deprecation is to be asserted by > Directory service implementers in the course of managing instances > of the Directory service. > > -- > -- > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| > # Larry Bartz > # > # voice (317) 226-7060 > # FAX (317) 226-6378 > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.4C0A4D40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] Re: = draft-reyes-policy-core-ext-schema-03.txt

I've been away for awhile, but am commenting because = Bert asked for comments from the original authors.

I agree with Larry and Ryan. There is no technical = justification for deprecating these classes. In rereading the draft, I = would go further and state that there some of the restructuring may not = be a good idea; however, I want to reread this one last time and then I = will provide detailed comments.

Finally, Kurt is absolutely correct - deprecation is = inappropriate in an LDAP schema standards document.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Larry S. Bartz [mailto:lbartz@parnelli.i= ndy.cr.irs.gov]
> Sent: Friday, August 29, 2003 3:24 PM
> To: Wijnen, Bert (Bert)
> Cc: policy@ietf.org
> Subject: Re: [Policy] Re: = draft-reyes-policy-core-ext-schema-03.txt
>
> Wijnen, Bert (Bert) wrote, On 08/29/03 = 10:14:
> > What an underwhelming interest in this = document.
> >
> > When I start reading it, I see in the = abstract:
> >    This document defines a = number of changes and extensions to
> the
> >    Policy Core LDAP Schema = [PCLS] based on the specifications of
> the
> >    Policy Core Information = Model Extensions [PCIM_EXT]. The
> changes
> >    include additional = object classes previously not covered,
> deprecation
> >    of some object classes = and changes to the object class
> hierarchy
> >    defined in = [PCLS].
> >
> > And so I immediately wonder... is it = really OK that this document
> > deprecates some object classes ??
> >
> > Possibly so... but I'd like to hear some = of the PCIM, PCIM-EXT
> and
> > PCLS authors/ediotrs to explicitly say so. = PLEASE!
> >
> > Thanks,
> > Bert
>
>
> I argued several months ago that it is actually = unnecessary to
> deprecate any of PCLS's information components. = There are no
> naming clashes with PCLS components. The = proposed deprecation
> only insures that PCLS and this schema will not = be able to
> co-exist in the same Directory implementations. = This is counter
> to the spirit of "extension". It = casts a negative light on an
> elegant and highly serviceable information = model and schema
> definition.
>
> Further, another commenter (I believe it was = Kurt Zielenga)
> asserted
> that the specification of deprecation is = inappropriate in a schema
> standards document. Rather, deprecation is to = be asserted by
> Directory service implementers in the course of = managing instances
> of the Directory service.
>
> --
> --
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
> # Larry Bartz
> #
> #  voice (317) 226-7060
> #  FAX   (317) 226-6378
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
>
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.4C0A4D40-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27733 for ; Mon, 15 Sep 2003 09:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073G-EW for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG9T6026995 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD3-0006yH-Nt; Mon, 15 Sep 2003 09:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCQ-0006tF-Bv for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:26 -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 JAA27677 for ; Mon, 15 Sep 2003 09:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCO-000567-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:24 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCO-00052l-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:24 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: "Pana, Mircea" , "'Joel M. Halpern'" , "Larry S. Bartz" , "'policy@ietf.org'" Cc: rmoats@lemurnetworks.net, David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.5547B820" 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_01C37B8B.5547B820 Content-Type: text/plain With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. With respect to the second point, that's much better. I will provide comments on the schema itself next week. With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com ] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37B8B.5547B820 Content-Type: text/html RE: [Policy] PCLS classes deprecated in PCELS

With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

 

With respect to the second point, that's much better. I will provide comments on the schema itself next week.

 

With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts.

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

So, if I understand correctly, everything would be "OK" if PCELS did:

1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 

2. Use "for compliance with PCIMe implementations SHALL use <list schema items> instead of <list of schema items> for the realization of <concepts>" instead of deprecating PCLS classes. This would be added to a new revision of the ID.

I'm fine with both. (I hope I did not miss anything)

Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all.

Thanks,
Mircea.



> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
>
>
> Ryan as just nicely explained this to me in a way that got it
> through my
> thick skull.  You both are correct.  We can not move existing classes.
>
> Hence, one needs to create new classes, and include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote:
> >Ryan Moats wrote, On 09/12/03 11:27:
> >[snip}
> >>Actually, that is a solution for all of the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every component of PCIMe which is
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or redefining anything from
> >PCLS, there can be no conflict with PCLS. And if everything new
> >which is introduced by PCELS is prefixed "pcime", there can be no
> >confusion about which is "core" and which is "extension".
> >
> >Such a strategy will ultimately satisfy Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I agree that
> "concerns about
> >PCELS should be in the context of support for PCIMe". I augment that
> >by saying that PCELS should not be concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) 226-6378
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
>
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37B8B.5547B820-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:16:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27769 for ; Mon, 15 Sep 2003 09:16:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073E-Dm for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG9OQ026964 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD3-0006y6-8a; Mon, 15 Sep 2003 09:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCP-0006t8-Vb for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:26 -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 JAA27674 for ; Mon, 15 Sep 2003 09:15:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCO-000561-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:24 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCN-00052l-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:23 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: "Wijnen, Bert (Bert)" , "'Pana, Mircea'" , "'Marcus Brunner'" , "'telabm@mat.upc.es'" , "'angelica@mat.upc.es'" , "'David Moron'" Cc: "Policy (E-mail)" Subject: RE: [Policy] AD review: draft-reyes-policy-core-ext-schema-03.txt (targeted fo r PS) Date: Mon, 15 Sep 2003 07:14:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.51B40A10" 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_01C37B8B.51B40A10 Content-Type: text/plain Hi Bert, My opinions in answer to your questions are inline. Look for .. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, August 29, 2003 2:50 PM > To: 'Pana, Mircea'; 'Marcus Brunner'; 'telabm@mat.upc.es'; > 'angelica@mat.upc.es'; 'David Moron' > Cc: Policy (E-mail) > Subject: [Policy] AD review: draft-reyes-policy-core-ext-schema- > 03.txt (targeted fo r PS) > > Here are my comments. Would be good to not only hear > authors/editors > responses, but also input from the WG. > > - RFC3460 Updates RFC3060. So would it not be logical to say/claim > that this PCELS Updates PCLS ?? If so, we need to say so in the > abstract with a simple, but explicit sentence: > This document updates RFC zzzz > -- RFC-Editor replaces zzzz with RFC number assigned to > [PCLS] One would have thought so. But this document changes PCLS in several fundamental ways. I do NOT think that the word "update" should be used anywhere in this document. > - Maybe I just do not understand... But is it valid to just move a > class, like you moved the pcimGroup (and all that was under it) > underneath a new pcimPolicySet. Would it not be more cuatious to > deprecate the pcimGroup and define s pcimeGroup or such under > pcimPolicySet and do something similar for the other moved groups > classes? I understand that PCIM-EXT did this moving too, but that > is an information model (so abstract) while this is a mapping > onto > a repository, so here things may get incompatible if we already > have implementation of PCLS, no? I don't think that moving classes around are justified or a good idea. This would be equivalent to me building a MIB where I "update" an existing table by building a completely new table. This and other things render the resulting schema of PCELS incompatible with older PCLS implementations. > - Is it wise to have (as part of this document) two Vendor specific > classes that are not part of or based on PCIM-EXT ?? This doc is > supposed to do the LDAP Schema defintiions for PCIM-EXT, right? > So why these additions? The vendor classes were originally intended to provide extensibility. But having new classes that are not built from PCIM or PCIMe is NOT a good idea, and they certainly do not qualify as an "update". > - Is it wise to just rename classes (sect 4.2, bullet 1). Would it > not be wiser to deprecate the old ones and add new ones? Renaming is a bad idea, because everything else now changes - their OIDs, classes referencing them, etc. But I don't believe that deprecation is appropriate for a schema. I know of no LDAP documents that have deprecated schema - this is rather done in an implementation. Again, it seems that this is more of a NEW implementation as opposed to an UPDATE of any type. > - There seems to be more of these things that I wonder if > deprecation > and adding new ones would be better. I guess I do not very well > understand the impact (or non-impact) on existing implementations > of the PCLS by the changes being made. Can someone explain to me. > Or possibly add text to the document that describes such > (non-)impact. There's a very large impact - lack of compatibility. Fundamentally, this document proposes a set of incompatible changes to PCLS. I don't understand why these changes are being asked for. It would seem that instead of rewriting parts of the schema, as this document proposes, changes should have been made to PCLS. > - In section 5, I think you need to explain/define which matching > rules are used and make citations to where they are defined. > PCLS does that too (zeilenga-user_schema), but you probably > better use: draft-zeilenga-ldap-user-schema-mr-00.txt > Pls make sure that that indeed covers all matching rules. The matching rules are not defined as normative references, which is imho a mistake. They should at least reference RFC2252 for LDAP definitions and X.520 for the X.5 definitions. Note that PCLS uses the 2001 version of X.520. > - Security Considerations > Would it not be better to change the first 3 paragraphs: > This topic is based on requirements from previous [PCLS] > documents > and also takes into account other RFCs about the same security > aspects entitled as following: > > RFC 2829 (Authentication Methods for LDAP) > RFC 2830 (Lightweight Directory Access Protocol (v3): Extension > for > Transport Layer Security) > > These RFC documents provide a general framework for security > architecture of the system. However some comments have to be > provided > as a consequence of the inclusion of extensions in this own > document > and its relation with PCLS doc. > Into something like: > Since this PCELS document is an update to the [PCLS] it has the > same > basic security considerations as the [PCLS] document. So see > the > Security considerations in [PCLS] first. I would agree > - You may want to check the English on Page 55 (up to IANA > considerations) > For example: what is "obtention" ?? > what is "p.e." ? I guess par example or per exemple? > in English text we tend to use e.g. > > And for me (but I am not a security expert), I do not understand > what > that text on page 55 is trying to tell me. You may want to check > with > one of the security ADs, Russ Housley is probably the most > appropriate, > if this is clear and acceptable for them. Russ Mundy was the security advisor for PCIM. Luis Sanchez also looked at early copies of the document. > - IANA Considerations. > Isn't the IANA-ASSIGNED-OID the same as the one in PCLS ?? > If so, we should make that clear in the document, so it is > easy for IANA to see and understand. Depends on what they would want to do. But I would expect that new classes (regardless of whether they update an existing class or not) to have new OIDs. > NITS: > - in abstract, do not use citations as per RFC-Editor policy. It is > OK to > use RFC numbers. > - RFC2119 (your [KEYWORDS] citation) must be a normative reference > Your text on keywors on page 1 does not make a citation to this > by the > way. > > I want to get this doc reviewed by an LDAP expert (from the LDAP > directorate) as well, but maybe you can try to address and/or > answer > the above first. I'm on the LDAP directorate ;-) and will take a good look at actual recommended schema next week. > Thanks, > Bert > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.51B40A10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] AD review: = draft-reyes-policy-core-ext-schema-03.txt (targeted fo r PS)

Hi Bert,

My opinions in answer to your questions are inline. = Look for <js>..</js>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Friday, August 29, 2003 2:50 PM
> To: 'Pana, Mircea'; 'Marcus Brunner'; = 'telabm@mat.upc.es';
> 'angelica@mat.upc.es'; 'David Moron'
> Cc: Policy (E-mail)
> Subject: [Policy] AD review: = draft-reyes-policy-core-ext-schema-
> 03.txt (targeted fo r PS)
>
> Here are my comments. Would be good to not only = hear
> authors/editors
> responses, but also input from the WG.
>
> - RFC3460 Updates RFC3060. So would it not be = logical to say/claim
>   that this PCELS Updates PCLS ?? If = so, we need to say so in the
>   abstract with a simple, but = explicit sentence:
>       This = document updates RFC zzzz
>       -- = RFC-Editor replaces zzzz with RFC number assigned to
> [PCLS]

<js> One would have thought so. But this = document changes PCLS in several fundamental ways. I do NOT think that = the word "update" should be used anywhere in this document. = </js>

> - Maybe I just do not understand... But is it = valid to just move a
>   class, like you moved the pcimGroup = (and all that was under it)
>   underneath a new pcimPolicySet. = Would it not be more cuatious to
>   deprecate the pcimGroup and define = s pcimeGroup or such under
>   pcimPolicySet and do something = similar for the other moved groups
>   classes? I understand that PCIM-EXT = did this moving too, but that
>   is an information model (so = abstract) while this is a mapping
> onto
>   a repository, so here things may = get incompatible if we already
>   have implementation of PCLS, = no?

<js> I don't think that moving classes around = are justified or a good idea. This would be equivalent to me building a = MIB where I "update" an existing table by building a = completely new table. This and other things render the resulting schema = of PCELS incompatible with older PCLS implementations. </js>

> - Is it wise to have (as part of this document) = two Vendor specific
>   classes that are not part of or = based on PCIM-EXT ?? This doc is
>   supposed to do the LDAP Schema = defintiions for PCIM-EXT, right?
>   So why these additions?

<js> The vendor classes were originally = intended to provide extensibility. But having new classes that are not = built from PCIM or PCIMe is NOT a good idea, and they certainly do not = qualify as an "update". </js>

> - Is it wise to just rename classes (sect 4.2, = bullet 1). Would it
>   not be wiser to deprecate the old = ones and add new ones?

<js> Renaming is a bad idea, because everything = else now changes - their OIDs, classes referencing them, etc. But I = don't believe that deprecation is appropriate for a schema. I know of = no LDAP documents that have deprecated schema - this is rather done in = an implementation.

Again, it seems that this is more of a NEW = implementation as opposed to an UPDATE of any type. </js>

> - There seems to be more of these things that I = wonder if
> deprecation
>   and adding new ones would be = better. I guess I do not very well
>   understand the impact (or = non-impact) on existing implementations
>   of the PCLS by the changes being = made. Can someone explain to me.
>   Or possibly add text to the = document that describes such
>   (non-)impact.

<js> There's a very large impact - lack of = compatibility. Fundamentally, this document proposes a set of = incompatible changes to PCLS. I don't understand why these changes are = being asked for. It would seem that instead of rewriting parts of the = schema, as this document proposes, changes should have been made to = PCLS. </js>

> - In section 5, I think you need to = explain/define which matching
>   rules are used and make citations = to where they are defined.
>   PCLS does that too = (zeilenga-user_schema), but you probably
>   better use: = draft-zeilenga-ldap-user-schema-mr-00.txt
>   Pls make sure that that indeed = covers all matching rules.

<js> The matching rules are not defined as = normative references, which is imho a mistake. They should at least = reference RFC2252 for LDAP definitions and X.520 for the X.5 = definitions. Note that PCLS uses the 2001 version of X.520. = </js>

> - Security Considerations
>   Would it not be better to change = the first 3 paragraphs:
>     This topic is based on = requirements from previous [PCLS]
> documents
>     and also takes into = account other RFCs about the same security
>     aspects entitled as = following:
>
>     RFC 2829 = (Authentication Methods for LDAP)
>     RFC 2830 (Lightweight = Directory Access Protocol (v3): Extension
> for
>          = ;     Transport Layer Security)
>
>     These RFC documents = provide a general framework for security
>     architecture of the = system. However some comments have to be
> provided
>     as a consequence of the = inclusion of extensions in this own
> document
>     and its relation with = PCLS doc.
>   Into something like:
>     Since this PCELS = document is an update to the [PCLS] it has the
> same
>     basic security = considerations as the [PCLS] document. So see
> the
>     Security considerations = in [PCLS] first.

<js> I would agree </js>

> - You may want to check the English on Page 55 = (up to IANA
> considerations)
>   For example: what is = "obtention" ??
>          = ;      what is "p.e." ? I guess par = example or per exemple?
>          = ;      in English text we tend to use = e.g.
>
>   And for me (but I am not a security = expert), I do not understand
> what
>   that text on page 55 is trying to = tell me. You may want to check
> with
>   one of the security ADs, Russ = Housley is probably the most
> appropriate,
>   if this is clear and acceptable for = them.

<js> Russ Mundy was the security advisor for = PCIM. Luis Sanchez also looked at early copies of the document. = </js>

> - IANA Considerations.
>   Isn't the IANA-ASSIGNED-OID the = same as the one in PCLS ??
>   If so, we should make that clear in = the document, so it is
>   easy for IANA to see and = understand.

<js> Depends on what they would want to do. But = I would expect that new classes (regardless of whether they update an = existing class or not) to have new OIDs. </js>

> NITS:
> - in abstract, do not use citations as per = RFC-Editor policy. It is
> OK to
>   use RFC numbers.
> - RFC2119 (your [KEYWORDS] citation) must be a = normative reference
>   Your text on keywors on page 1 does = not make a citation to this
> by the
>   way.
>
> I want to get this doc reviewed by an LDAP = expert (from the LDAP
> directorate) as well, but maybe you can try to = address and/or
> answer
> the above first.

<js> I'm on the LDAP directorate ;-) and will = take a good look at actual recommended schema next week. = </js>

> Thanks,
> Bert
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.51B40A10-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 09:42:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28907 for ; Mon, 15 Sep 2003 09:42:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytc9-00022i-Tn for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:42:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDg1kQ007853 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:42:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytc9-00022F-9a; Mon, 15 Sep 2003 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytbl-0001zv-LE for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:41:37 -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 JAA28878 for ; Mon, 15 Sep 2003 09:41:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytbj-0007Zs-00 for policy@ietf.org; Mon, 15 Sep 2003 09:41:35 -0400 Received: from mx-relay1.treas.gov ([199.196.144.5] helo=mx-relay1.net.treas.gov) by ietf-mx with esmtp (Exim 4.12) id 19ytbj-0007ZI-00 for policy@ietf.org; Mon, 15 Sep 2003 09:41:35 -0400 Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay1.net.treas.gov (8.12.9/8.12.9) with SMTP id h8FDfUJq007028; Mon, 15 Sep 2003 09:41:30 -0400 (EDT) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay1.treas.gov [199.196.144.5]) with SMTP; 15 Sep 2003 13:41:29 UT Received: from irsbd1.net.treas.gov (localhost [127.0.0.1]) by mailhub-4.net.treas.gov (8.12.9/8.12.9) with ESMTP id h8FDfJiJ022294; Mon, 15 Sep 2003 09:41:20 -0400 (EDT) Received: from no.name.available by irsbd1.net.treas.gov via smtpd (for mailhub.net.treas.gov [10.7.14.14]) with ESMTP; Mon, 15 Sep 2003 13:41:17 +0000 Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by big-al.indy.cr.irs.gov (8.11.2/8.9.3) with ESMTP id h8FDfLf24648; Mon, 15 Sep 2003 08:41:21 -0500 Message-ID: <3F65C181.7010409@parnelli.indy.cr.irs.gov> Date: Mon, 15 Sep 2003 08:41:21 -0500 From: "Larry S. Bartz" Organization: Internal Revenue Service User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pana, Mircea" CC: "'Joel M. Halpern'" , "'policy@ietf.org'" , rmoats@lemurnetworks.net, David McTavish , John Strassner Subject: Re: [Policy] PCLS classes deprecated in PCELS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Pana, Mircea wrote, On 09/12/03 16:10: > So, if I understand correctly, everything would be "OK" if PCELS did: > > 1. Define only subclasses of PCLS classes and, where not possible, > redefine PCLS concepts as new classes (use different names and oid.s). > This is already the case in the currently published ID with the > exception of pcimGroup* that would need to be redefined with a different > name. > > 2. Use "for compliance with PCIMe implementations SHALL use items> instead of for the realization of > " instead of deprecating PCLS classes. This would be added to > a new revision of the ID. > > I'm fine with both. (I hope I did not miss anything) Excellent! > > Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as > long as there are no naming conflicts, I would prefer to avoid it if > possible. Could you live with that? However if we have to do it for one > item we should do it for all. The distinction between PCIM/PCLS (the "core") and PCIMe/PCELS (the "extension") is significant; significant enough to distinguish the work of you and your co-authors by assigning a set of distinctive names to all new and different PCELS attributetypes and objectclasses. If PCELS does not do this, implementers will naturally expect that information components with similar prefixes belong to the same information model. The logical differences between PCIM/PCLS and PCIMe/PCELS preclude this kind of mix and match. PCELS should facilitate implementation by providing its own set of names. One more thing. I agree with John Strassner, who writes: > ..this document changes PCLS in several fundamental ways. I do NOT > think that the word "update" should be used anywhere in this document. Thanks, -- -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz # # voice (317) 226-7060 # FAX (317) 226-6378 #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 10:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27734 for ; Mon, 15 Sep 2003 09:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073D-DV for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG89F026939 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD1-0006xR-GQ; Mon, 15 Sep 2003 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCN-0006sR-Qn for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:24 -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 JAA27667 for ; Mon, 15 Sep 2003 09:15:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCM-00055d-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:22 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCL-00052Z-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:21 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: rmoats@lemurnetworks.net, "Pana, Mircea" Cc: David McTavish , "'policy@ietf.org'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.5338AE40" 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_01C37B8B.5338AE40 Content-Type: text/plain Hmm. Clearly, PCELS classes that are not compatible with PCLS should use their own prefix, a simple and time-honored way to separate class hierarchies. However, I still worry about the rigidity and lack of extensibility if we simply say "Here lies PCLS, and here lies PCELS. May their paths never cross". The example given in my previous note regarding a more generic (AND ABSTRACT) policyConditionAssociation, from which a more specific policyConditionInPolicyRule, as well as a more specific policyConditionInPolicyCondition are subclasses, seems infinitely better. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Friday, September 12, 2003 10:28 AM > To: Pana, Mircea > Cc: David McTavish; 'policy@ietf.org' > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > On Fri, Sep 12, 2003 at 11:15:07AM -0500, Ryan Moats wrote: > | On Fri, Sep 12, 2003 at 11:01:33AM -0500, Pana, Mircea wrote: > | | I would like to understand why you have a problem with PCELS > inserting a new > | | class in the inheritance chain of a PCLS defined class. > | > | Because you've broken the binding between an LDAP object class's > OID and > | an that object class's name. Included in this binding is the > superior > | objectclass. Therefore > | > | ( NAME "pcimRepository" SUP top ) > | > | and > | > | ( NAME "pcimRepository" SUP pcimRulesContainer ) > | > | are *NOT* the same from an LDAP point of view: they require > different > | OID and different names. > | > | Ryan > > Actually, that is a solution for all of the subclass cases: in > PCELS call > tem pcime*, give them different OIDs from what's in PCLS and then > everything > is ok. > > Ryan > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.5338AE40 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

Hmm. Clearly, PCELS classes that are not compatible = with PCLS should use their own prefix, a simple and time-honored way to = separate class hierarchies. However, I still worry about the rigidity = and lack of extensibility if we simply say "Here lies PCLS, and = here lies PCELS. May their paths never cross". The example given = in my previous note regarding a more generic (AND ABSTRACT) = policyConditionAssociation, from which a more specific = policyConditionInPolicyRule, as well as a more specific = policyConditionInPolicyCondition are subclasses, seems infinitely = better.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Friday, September 12, 2003 10:28 = AM
> To: Pana, Mircea
> Cc: David McTavish; 'policy@ietf.org'
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
> On Fri, Sep 12, 2003 at 11:15:07AM -0500, Ryan = Moats wrote:
> | On Fri, Sep 12, 2003 at 11:01:33AM -0500, = Pana, Mircea wrote:
> | | I would like to understand why you have a = problem with PCELS
> inserting a new
> | | class in the inheritance chain of a PCLS = defined class.
> |
> | Because you've broken the binding between an = LDAP object class's
> OID and
> | an that object class's name. Included in this = binding is the
> superior
> | objectclass.  Therefore
> |
> | ( <oid> NAME "pcimRepository" = SUP top )
> |
> | and
> |
> | ( <oid> NAME "pcimRepository" = SUP pcimRulesContainer )
> |
> | are *NOT* the same from an LDAP point of = view: they require
> different
> | OID and different names.
> |
> | Ryan
>
> Actually, that is a solution for all of the = subclass cases: in
> PCELS call
> tem pcime*, give them different OIDs from = what's in PCLS and then
> everything
> is ok.
>
> Ryan
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.5338AE40-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 10:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27735 for ; Mon, 15 Sep 2003 09:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00073H-ER for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG9X9026966 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD2-0006xk-DD; Mon, 15 Sep 2003 09:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCN-0006sT-UG for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:25 -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 JAA27666 for ; Mon, 15 Sep 2003 09:15:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCM-00055a-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:22 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCL-00052W-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:21 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: "Larry S. Bartz" , "'policy@ietf.org'" Cc: rmoats@lemurnetworks.net, David McTavish , "Joel M. Halpern" , "Pana, Mircea" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.53CA18D0" 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_01C37B8B.53CA18D0 Content-Type: text/plain Hear hear! Nicely stated, I absolutely agree. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] > Sent: Friday, September 12, 2003 11:39 AM > To: 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Joel M. Halpern; > Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > Ryan Moats wrote, On 09/12/03 11:27: > [snip} > > > > Actually, that is a solution for all of the subclass cases: in > PCELS call > > tem pcime*, give them different OIDs from what's in PCLS and then > everything > > is ok. > > > > I'll go further and suggest that every component of PCIMe which is > not exactly as defined in PCLS should be prefixed "pcime". If PCELS > simply avoids deprecating, renaming, or redefining anything from > PCLS, there can be no conflict with PCLS. And if everything new > which is introduced by PCELS is prefixed "pcime", there can be no > confusion about which is "core" and which is "extension". > > Such a strategy will ultimately satisfy Joel's concerns, when he > wrote: > > My feeling is that concerns about PCELS should be in the context > of > > support for PCIMe, > and > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > with PCLS, then that would clearly seem desirable > > PCELS should map PCIMe to LDAP in a way which is not INcompatible > with > PCLS, in a way which does not break PCLS. I agree that "concerns > about > PCELS should be in the context of support for PCIMe". I augment > that > by saying that PCELS should not be concerned with recasting PCLS in > any way. > > PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > impact on PCLS. > > > -- > -- > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| > # Larry Bartz > # > # voice (317) 226-7060 > # FAX (317) 226-6378 > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.53CA18D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

Hear hear! Nicely stated, I absolutely agree.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Larry S. Bartz [mailto:lbartz@parnelli.i= ndy.cr.irs.gov]
> Sent: Friday, September 12, 2003 11:39 = AM
> To: 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; = Joel M. Halpern;
> Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
> Ryan Moats wrote, On 09/12/03 11:27:
> [snip}
> >
> > Actually, that is a solution for all of = the subclass cases: in
> PCELS call
> > tem pcime*, give them different OIDs from = what's in PCLS and then
> everything
> > is ok.
> >
>
> I'll go further and suggest that every = component of PCIMe which is
> not exactly as defined in PCLS should be = prefixed "pcime". If PCELS
> simply avoids deprecating, renaming, or = redefining anything from
> PCLS, there can be no conflict with PCLS. And = if everything new
> which is introduced by PCELS is prefixed = "pcime", there can be no
> confusion about which is "core" and = which is "extension".
>
> Such a strategy will ultimately satisfy Joel's = concerns, when he
> wrote:
>  > My feeling is that concerns about = PCELS should be in the context
> of
>  > support for PCIMe,
> and
>  > if one can accurately map PCIMe to = LDAP in a way that is
> compatible
>  > with PCLS, then that would clearly = seem desirable
>
> PCELS should map PCIMe to LDAP in a way which = is not INcompatible
> with
> PCLS, in a way which does not break PCLS. I = agree that "concerns
> about
> PCELS should be in the context of support for = PCIMe". I augment
> that
> by saying that PCELS should not be concerned = with recasting PCLS in
> any way.
>
> PCELS should focus on mapping PCIMe to LDAP. = PCELS should avoid any
> impact on PCLS.
>
>
> --
> --
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
> # Larry Bartz
> #
> #  voice (317) 226-7060
> #  FAX   (317) 226-6378
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
>
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.53CA18D0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 10:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27715 for ; Mon, 15 Sep 2003 09:16:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD7-00072p-BQ for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDG97I026956 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 09:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytD4-0006yU-B7; Mon, 15 Sep 2003 09:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytCQ-0006tW-W9 for policy@optimus.ietf.org; Mon, 15 Sep 2003 09:15:27 -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 JAA27680 for ; Mon, 15 Sep 2003 09:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytCP-00056H-00 for policy@ietf.org; Mon, 15 Sep 2003 09:15:25 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19ytCO-00052l-01 for policy@ietf.org; Mon, 15 Sep 2003 09:15:24 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 07:14:49 -0600 Message-ID: From: John Strassner To: rmoats@lemurnetworks.net, "Pana, Mircea" Cc: "'bwijnen@lucent.com'" , "'policy@ietf.org'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 07:14:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B8B.5296A1E0" 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_01C37B8B.5296A1E0 Content-Type: text/plain Comments inline; please look for ... In general, I think that the prefix "pcim" is misused in PCELS - this implies that PCELS is truly an update and is using the same schema, whereas in reality PCELS is a new design and is building a different schema that in its proposal is incompatible is some important, fundamental ways. So why not use a new prefix - pcime or pcels - to indicate this for the new classes proposed? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Tuesday, September 09, 2003 8:26 AM > To: Pana, Mircea > Cc: 'bwijnen@lucent.com'; 'policy@ietf.org' > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, Mircea wrote: > | PCELS deprecates some of the PCLS classes and attributes for > various > | reasons. In some cases, deprecation could have been avoided but > in other > | cases this was dictated by PCIMe. (details discussed below) I > agree that > | deprecation might create backward compatibility problems where > PCELS and > | PCLS implementations attempt to cooperate. BTW, does anybody out > there have > | such requirements? Given that PCIMe deprecates a significant > number of > | concepts from PCIM, is such cooperation even possible? While it is true that PCIMe did deprecate concepts in PCIM, this was done with interoperability in mind. PCELS seems to have considered the design as a clean slate, as opposed to maximizing interoperability. Also, note that there is a huge difference between RFC3460, which is an information model, and PCELS, which is a data model. > | The classes deprecated by PCELS are discussed below: > | > | 1. The class pcimGroupContainmentAuxClass defined by PCLS > provides a single, > | multi-valued attribute that references a set of pcimGroups. This > unordered > | aggregation mechanism can not be reused in implementations of > PCIMe because > | the model (PCIMe) requires PolicySetComponent associations to be > | prioritized: > | " 5.5. Priorities and Decision Strategies > | [...] Unlike the earlier definition, > | PolicySetComponent.Priority MUST have a unique value when > compared > | with others defined for the same aggregating PolicySet. Thus, > the > | evaluation of rules within a set is deterministically > specified. " > | If PCELS allowed pcimGroupContainmentAuxClass, then it would be > conflicting > | with PCIMe. > | > | 2. The class pcimRuleContainmentAuxClass defined in PCLS is > deprecated by > | PCELS for the same reasons. > > Those are not reason to deprecate classes in the more general > model. That's > a reason to say "in this space, this other class should be used". I agree with Ryan > | 3. The pcimRule* classes defined by PCLS are deprecated and > redefined as > | pcimPolicyRule* in PCELS. According to PCIMe the > PolicyRule.Priority > | property is deprecated. Therefore PCELS redefines the PolicyRule > class > | mainly for removing the Priority attribute. An other option would > have been > | to leave pcimRule* as they are and then PCELS would have had to > specify that > | the pcimRulePriority attribute MUST NOT be used - a less formal > solution > | that does not prevent accidental use of the deprecated attribute. > | > | An other reason for replacing the pcimRule* classes is the > renaming of the > | attributes that serve in the Rule-Condition and Rule-Action > associations. > | pcimRuleConditionList is replaced by pcimConditionList and > | pcimRuleActionList is replaced by pcimActionList. Thus, the new > attributes > | along with the new association classes (discussed below) offer a > generic > | mechanism for aggregating Conditions or Actions. The use the same > | Condition/Action aggregation mechanism for both Policy Rules and > Compound > | Conditions/Action is an optimization in line with the > Policy*Structure > | concepts defined by PCIMe. > > Since you are rethinking subclass/deprication below, I'd argue > rethink it > here. I agree with Ryan. This isn't an update as much as it is a redesign. > | The deprecation of the pcimRule* classes is certainly not the > only option > | but based on our experience implementing PCIMe this one seemed an > acceptable > | compromise. However, any opinions or suggestions from the WG > based on their > | experience would be greatly appreciated. I'd like to know why you think deprecating an existing class and introducing incompatibility with existing implementations is better? > | 4. The class pcimRuleConditionAssociation defined by PCLS has > probably less > | reasons to be deprecated. It was done simply to keep the > Condition > | aggregation (into rules or compound conditions) limited to a > single > | association class. Now, looking from this different prospective, > I think > | that it is a good idea to retain it. > | > | So, I suggest the modification of the > pcimRuleConditionAssociation to become > | a subclass of the pcimConditionAssociation already defined in > PCELS. The > | attributes of the pcimRuleConditionAssociation, all inherited > from its > | superclass, would end up being the same ones as previously > defined by PCLS. > | Thus, for aggregating Conditions into a Policy Rule, one would > have the > | choice of using pcimConditionAssociation or > pcimRuleConditionAssociation > | while Condition aggregation into a Compound Condition would be > realized only > | through the pcimConditionAssociation class. This is confusing. You've changed the name of the LDAP class but kept the name of its attributes! You've therefore broken the LDAP class, as its OID is related to its class name, and further confused things by trying to move already assigned OIDs of attributes in the original definition of the class to a new class. This needs to be fixed. In addition, you're assuming that the semantics of aggregating a condition inside a condition are the same as the semantics of aggregating a condition inside a rule. Even if that is correct (which I'm not sure it is) this is a dangerous assumption, because in subsequent implementations if this does change, you can't accommodate these changes. > | 5. pcimRuleActionAssociation - same suggestion as for the > | pcimRuleConditionAssociation class > > This is a much better solution... I disagree with Ryan here - see above > | 6. The pcimRepository class defined by PCLS is deprecated by > PCELS for > | reasons described in PCIMe: > | " Because of the potential for confusion with the Policy > Framework > | component Policy Repository (from the four-box picture: Policy > | Management Tool, Policy Repository, PDP, PEP), > "PolicyRepository" is > | a bad name for the PCIM class representing a container of > reusable > | policy elements. Thus the class PolicyRepository is being > replaced > | with the class ReusablePolicyContainer." > > This could also be handled with a subclass. To be honest, I've never agreed with that reasoning, since the four-box picture represents an unrealistic, simplistic architecture. But if you are going to do this, handling this with a subclass as Ryan suggests would be acceptable. > Ryan > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy ------_=_NextPart_001_01C37B8B.5296A1E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

Comments inline; please look for = <js>..</js>. In general, I think that the prefix = "pcim" is misused in PCELS - this implies that PCELS is truly = an update and is using the same schema, whereas in reality PCELS is a = new design and is building a different schema that in its proposal is = incompatible is some important, fundamental ways. So why not use a new = prefix - pcime or pcels - to indicate this for the new classes = proposed?

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Tuesday, September 09, 2003 8:26 = AM
> To: Pana, Mircea
> Cc: 'bwijnen@lucent.com'; = 'policy@ietf.org'
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
> On Thu, Sep 04, 2003 at 05:09:46PM -0500, Pana, = Mircea wrote:
> | PCELS deprecates some of the PCLS classes and = attributes for
> various
> | reasons. In some cases, deprecation could = have been avoided but
> in other
> | cases this was dictated by PCIMe. (details = discussed below) I
> agree that
> | deprecation might create backward = compatibility problems where
> PCELS and
> | PCLS implementations attempt to cooperate. = BTW, does anybody out
> there have
> | such requirements? Given that PCIMe = deprecates a significant
> number of
> | concepts from PCIM, is such cooperation even = possible?

<js> While it is true that PCIMe did deprecate = concepts in PCIM, this was done with interoperability in mind. PCELS = seems to have considered the design as a clean slate, as opposed to = maximizing interoperability. Also, note that there is a huge difference = between RFC3460, which is an information model, and PCELS, which is a = data model. </js>

> | The classes deprecated by PCELS are discussed = below:
> |
> | 1. The class pcimGroupContainmentAuxClass = defined by PCLS
> provides a single,
> | multi-valued attribute that references a set = of pcimGroups. This
> unordered
> | aggregation mechanism can not be reused in = implementations of
> PCIMe because
> | the model (PCIMe) requires PolicySetComponent = associations to be
> | prioritized:
> | "  5.5. Priorities and Decision = Strategies
> |    [...] Unlike the earlier = definition,
> |    PolicySetComponent.Priority = MUST have a unique value when
> compared
> |    with others defined for the = same aggregating PolicySet.  Thus,
> the
> |    evaluation of rules within = a set is deterministically
> specified. "
> | If PCELS allowed = pcimGroupContainmentAuxClass, then it would be
> conflicting
> | with PCIMe.
> |
> | 2. The class pcimRuleContainmentAuxClass = defined in PCLS is
> deprecated by
> | PCELS for the same reasons.
>
> Those are not reason to deprecate classes in = the more general
> model.  That's
> a reason to say "in this space, this other = class should be used".

<js> I agree with Ryan </js>

> | 3. The pcimRule* classes defined by PCLS are = deprecated and
> redefined as
> | pcimPolicyRule* in PCELS. According to PCIMe = the
> PolicyRule.Priority
> | property is deprecated. Therefore PCELS = redefines the PolicyRule
> class
> | mainly for removing the Priority attribute. = An other option would
> have been
> | to leave pcimRule* as they are and then PCELS = would have had to
> specify that
> | the pcimRulePriority attribute MUST NOT be = used - a less formal
> solution
> | that does not prevent accidental use of the = deprecated attribute.
> |
> | An other reason for replacing the pcimRule* = classes is the
> renaming of the
> | attributes that serve in the Rule-Condition = and Rule-Action
> associations.
> | pcimRuleConditionList is replaced by = pcimConditionList and
> | pcimRuleActionList is replaced by = pcimActionList. Thus, the new
> attributes
> | along with the new association classes = (discussed below) offer a
> generic
> | mechanism for aggregating Conditions or = Actions. The use the same
> | Condition/Action aggregation mechanism for = both Policy Rules and
> Compound
> | Conditions/Action is an optimization in line = with the
> Policy*Structure
> | concepts defined by PCIMe.
>
> Since you are rethinking subclass/deprication = below, I'd argue
> rethink it
> here.

<js> I agree with Ryan. This isn't an update as = much as it is a redesign. </js>

> | The deprecation of the pcimRule* classes is = certainly not the
> only option
> | but based on our experience implementing = PCIMe this one seemed an
> acceptable
> | compromise. However, any opinions or = suggestions from the WG
> based on their
> | experience would be greatly = appreciated.

<js> I'd like to know why you think deprecating = an existing class and introducing incompatibility with existing = implementations is better? </js>

> | 4. The class pcimRuleConditionAssociation = defined by PCLS has
> probably less
> | reasons to be deprecated. It was done simply = to keep the
> Condition
> | aggregation (into rules or compound = conditions) limited to a
> single
> | association class. Now, looking from this = different prospective,
> I think
> | that it is a good idea to retain it.
> |
> | So, I suggest the modification of the
> pcimRuleConditionAssociation to become
> | a subclass of the pcimConditionAssociation = already defined in
> PCELS. The
> | attributes of the = pcimRuleConditionAssociation, all inherited
> from its
> | superclass, would end up being the same ones = as previously
> defined by PCLS.
> | Thus, for aggregating Conditions into a = Policy Rule, one would
> have the
> | choice of using pcimConditionAssociation = or
> pcimRuleConditionAssociation
> | while Condition aggregation into a Compound = Condition would be
> realized only
> | through the pcimConditionAssociation = class.

<js> This is confusing. You've changed the name = of the LDAP class but kept the name of its attributes! You've therefore = broken the LDAP class, as its OID is related to its class name, and = further confused things by trying to move already assigned OIDs of = attributes in the original definition of the class to a new class. This = needs to be fixed. In addition, you're assuming that the semantics of = aggregating a condition inside a condition are the same as the = semantics of aggregating a condition inside a rule. Even if that is = correct (which I'm not sure it is) this is a dangerous assumption, = because in subsequent implementations if this does change, you can't = accommodate these changes. </js>

> | 5. pcimRuleActionAssociation - same suggestion = as for the
> | pcimRuleConditionAssociation class
>
> This is a much better solution...

<js> I disagree with Ryan here - see above = </js>

> | 6. The pcimRepository class defined by PCLS is = deprecated by
> PCELS for
> | reasons described in PCIMe:
> | "   Because of the potential = for confusion with the Policy
> Framework
> |    component Policy Repository = (from the four-box picture: Policy
> |    Management Tool, Policy = Repository, PDP, PEP),
> "PolicyRepository" is
> |    a bad name for the PCIM = class representing a container of
> reusable
> |    policy elements.  Thus = the class PolicyRepository is being
> replaced
> |    with the class = ReusablePolicyContainer."
>
> This could also be handled with a = subclass.

<js> To be honest, I've never agreed with that = reasoning, since the four-box picture represents an unrealistic, = simplistic architecture. But if you are going to do this, handling this = with a subclass as Ryan suggests would be acceptable. = </js>

> Ryan
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy

------_=_NextPart_001_01C37B8B.5296A1E0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 11:26:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07267 for ; Mon, 15 Sep 2003 11:26:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvEr-0006Rv-9a for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 11:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FFQ5bc024787 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 11:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvEo-0006RC-Ue; Mon, 15 Sep 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yvDj-0006JW-Pc for policy@optimus.ietf.org; Mon, 15 Sep 2003 11:25:00 -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 LAA07090 for ; Mon, 15 Sep 2003 11:24:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yvDi-0002Qj-00 for policy@ietf.org; Mon, 15 Sep 2003 11:24:54 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19yvDh-0002My-00 for policy@ietf.org; Mon, 15 Sep 2003 11:24:54 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 09:24:21 -0600 Message-ID: From: John Strassner To: "'Larry S. Bartz'" , "'Pana, Mircea'" Cc: "'Joel M. Halpern'" , "'policy@ietf.org'" , "'rmoats@lemurnetworks.net'" , "'David McTavish'" , John Strassner Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 09:24:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B9D.701AC3B0" 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_01C37B9D.701AC3B0 Content-Type: text/plain I very much agree with Larry about naming. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com > -----Original Message----- > From: Larry S. Bartz [mailto:lbartz@parnelli.indy.cr.irs.gov] > Sent: Monday, September 15, 2003 7:41 AM > To: Pana, Mircea > Cc: 'Joel M. Halpern'; 'policy@ietf.org'; rmoats@lemurnetworks.net; > David McTavish; John Strassner > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > Pana, Mircea wrote, On 09/12/03 16:10: > > So, if I understand correctly, everything would be "OK" if PCELS > did: > > > > 1. Define only subclasses of PCLS classes and, where not > possible, > > redefine PCLS concepts as new classes (use different names and > oid.s). > > This is already the case in the currently published ID with the > > exception of pcimGroup* that would need to be redefined with a > different > > name. > > > > 2. Use "for compliance with PCIMe implementations SHALL use schema > > items> instead of for the realization of > > " instead of deprecating PCLS classes. This would be > added to > > a new revision of the ID. > > > > I'm fine with both. (I hope I did not miss anything) > > > Excellent! > > > > > > Wrt. naming PCELS classes and attributes pcime* instead of pcim*, > as > > long as there are no naming conflicts, I would prefer to avoid it > if > > possible. Could you live with that? However if we have to do it > for one > > item we should do it for all. > > > The distinction between PCIM/PCLS (the "core") and PCIMe/PCELS (the > "extension") is significant; significant enough to distinguish the > work of you and your co-authors by assigning a set of distinctive > names > to all new and different PCELS attributetypes and objectclasses. If > PCELS does not do this, implementers will naturally expect that > information components with similar prefixes belong to the same > information model. The logical differences between PCIM/PCLS and > PCIMe/PCELS preclude this kind of mix and match. PCELS should > facilitate implementation by providing its own set of names. > > One more thing. I agree with John Strassner, who writes: > > ..this document changes PCLS in several fundamental ways. I do > NOT > > think that the word "update" should be used anywhere in this > document. > > Thanks, > > -- > -- > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| > # Larry Bartz > # > # voice (317) 226-7060 > # FAX (317) 226-6378 > #:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::| ------_=_NextPart_001_01C37B9D.701AC3B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

I very much agree with Larry about naming.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com


> -----Original Message-----
> From: Larry S. Bartz [mailto:lbartz@parnelli.i= ndy.cr.irs.gov]
> Sent: Monday, September 15, 2003 7:41 AM
> To: Pana, Mircea
> Cc: 'Joel M. Halpern'; 'policy@ietf.org'; = rmoats@lemurnetworks.net;
> David McTavish; John Strassner
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
> Pana, Mircea wrote, On 09/12/03 16:10:
> > So, if I understand correctly, everything = would be "OK" if PCELS
> did:
> >
> > 1. Define only subclasses of PCLS classes = and, where not
> possible,
> > redefine PCLS concepts as new classes (use = different names and
> oid.s).
> > This is already the case in the currently = published ID with the
> > exception of pcimGroup* that would need to = be redefined with a
> different
> > name.
> >
> > 2. Use "for compliance with PCIMe = implementations SHALL use <list
> schema
> > items> instead of <list of schema = items> for the realization of
> > <concepts>" instead of = deprecating PCLS classes. This would be
> added to
> > a new revision of the ID.
> >
> > I'm fine with both. (I hope I did not miss = anything)
>
>
> Excellent!
>
>
> >
> > Wrt. naming PCELS classes and attributes = pcime* instead of pcim*,
> as
> > long as there are no naming conflicts, I = would prefer to avoid it
> if
> > possible. Could you live with that? = However if we have to do it
> for one
> > item we should do it for all.
>
>
> The distinction between PCIM/PCLS (the = "core") and PCIMe/PCELS (the
> "extension") is significant; = significant enough to distinguish the
> work of you and your co-authors by assigning a = set of distinctive
> names
> to all new and different PCELS attributetypes = and objectclasses. If
> PCELS does not do this, implementers will = naturally expect that
> information components with similar prefixes = belong to the same
> information model. The logical differences = between PCIM/PCLS and
> PCIMe/PCELS preclude this kind of mix and = match. PCELS should
> facilitate implementation by providing its own = set of names.
>
> One more thing. I agree with John Strassner, = who writes:
>  > ..this document changes PCLS in = several fundamental ways. I do
> NOT
>  > think that the word = "update" should be used anywhere in this
> document. </js>
>
> Thanks,
>
> --
> --
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|
> # Larry Bartz
> #
> #  voice (317) 226-7060
> #  FAX   (317) 226-6378
> = #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::|

------_=_NextPart_001_01C37B9D.701AC3B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 15 18:26:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29987 for ; Mon, 15 Sep 2003 18:26:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1nP-0007h2-T6 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 18:26:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FMQB7S029572 for policy-archive@odin.ietf.org; Mon, 15 Sep 2003 18:26:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1nG-0007gX-OK; Mon, 15 Sep 2003 18:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z1n7-0007fn-Ic for policy@optimus.ietf.org; Mon, 15 Sep 2003 18:25:55 -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 SAA29972 for ; Mon, 15 Sep 2003 18:25:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z1n4-0007Du-00 for policy@ietf.org; Mon, 15 Sep 2003 18:25:50 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19z1n3-0007DQ-00 for policy@ietf.org; Mon, 15 Sep 2003 18:25:49 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Mon, 15 Sep 2003 17:29:41 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'Joel M. Halpern'" , "Larry S. Bartz" , "'policy@ietf.org'" Cc: rmoats@lemurnetworks.net, David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Mon, 15 Sep 2003 17:20:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37BD7.A1272C70" 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_01C37BD7.A1272C70 Content-Type: text/plain; charset="iso-8859-1" John, Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list. There are a few clarifications that I'd like to ask for. See below in ... -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Monday, September 15, 2003 9:15 AM To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? With respect to the second point, that's much better. I will provide comments on the schema itself next week. With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts. I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse. Thanks, Mircea. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37BD7.A1272C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

John,

Thanks for the detailed comments and suggestions. = This is greatly appreciated. As already noted, there will be a PCELS = revision shortly. This revision will take into account the suggestions = that you and the other participants made on the list.

There are a few clarifications that I'd like to ask = for. See below in <mircea>..</mircea>.


-----Original Message-----
From: John Strassner [mailto:John.Strassner@inte= lliden.com]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; = 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in = PCELS


With respect to your first point, PCELS does NOT = already do this everywhere - for example, there are cases where you've = changed the name of the PCLS class but kept the names of its = attributes. That's very bad and will result in some NASTY errors. =

<mircea>
Can you please give an example from the current = PCELS? I don't understand what you mean by "changed the name of = the PCLS class". Except for pcimGroup* and the PCLS classes marked = as deprecated (that will be changed as noted) there are concepts that = have been redefined (i.e. new classes introduced by PCELS with new = OIDs). Some use attributes defined by PCLS. Do you see anything wrong = with that?</mircea>

With respect to the second point, that's much better. = I will provide comments on the schema itself next week.

With respect to naming, I don't understand the = problem. You have build a new design, not an update of an existing = design. Thus, new concepts should be assigned a new prefix (and I'd = prefer pcels, instead of pcime) whereas existing concepts should be = assigned the pcim prefix. Thus, it is not a "everything or = nothing" decision but instead a judicious application of new = (pcels) vs old (pcim) concepts.

<mircea>
I have heard valid arguments for using a different = naming prefix in PCELS than the one used by PCLS. These arguments are = based on the view that PCIM/PCLS is the "core" while = PCIMe/PCELS is an "extension". This is one point of view. = Mine is that PCIM/PCLS alone is incomplete and that only *together* = with PCIMe/PCELS it provides THE Framework for the development of = domain specific submodels. Both produced by the same WG btw. (I'm not = going to argue that though - it seems to be a sore spot!) For me, the = naming prefix is a minor issue and I can live with a different prefix = if people are so strongly against reuse.

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com] =
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; = 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in = PCELS

So, if I understand correctly, everything would be = "OK" if PCELS did:
1. Define only subclasses of PCLS classes and, where = not possible, redefine PCLS concepts as new classes (use different = names and oid.s). This is already the case in the currently published = ID with the exception of pcimGroup* that would need to be redefined = with a different name. 

2. Use "for compliance with PCIMe = implementations SHALL use <list schema items> instead of <list = of schema items> for the realization of <concepts>" = instead of deprecating PCLS classes. This would be added to a new = revision of the ID.

I'm fine with both. (I hope I did not miss anything) =
Wrt. naming PCELS classes and attributes pcime* = instead of pcim*, as long as there are no naming conflicts, I would = prefer to avoid it if possible. Could you live with that? However if we = have to do it for one item we should do it for all.

Thanks,
Mircea.



> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com] =
> Sent: Friday, September 12, 2003 1:50 PM =
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; = Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
>
> Ryan as just nicely explained this to me in a = way that got it
> through my
> thick skull.  You both are correct.  = We can not move existing classes.
>
> Hence, one needs to create new classes, and = include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with = class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience = explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz = wrote:
> >Ryan Moats wrote, On 09/12/03 11:27: =
> >[snip}
> >>Actually, that is a solution for all of = the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs = from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every = component of PCIMe which is
> >not exactly as defined in PCLS should be = prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or rede= fining anything from
> >PCLS, there can be no conflict with PCLS. = And if everything new
> >which is introduced by PCELS is prefixed = "pcime", there can be no
> >confusion about which is "core" = and which is "extension".
> >
> >Such a strategy will ultimately satisfy = Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about = PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to = LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly = seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way = which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I = agree that
> "concerns about
> >PCELS should be in the context of support = for PCIMe". I augment that
> >by saying that PCELS should not be = concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to = LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> = >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: =
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) 226-6378 =
> = >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: =
> ::::::::::|
>
>
>
> _______________________________________________ =
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy =
>

------_=_NextPart_001_01C37BD7.A1272C70-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 16 23:23:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26234 for ; Tue, 16 Sep 2003 23:23:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zSuJ-00068l-LW for policy-archive@odin.ietf.org; Tue, 16 Sep 2003 23:23:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8H3N72x023599 for policy-archive@odin.ietf.org; Tue, 16 Sep 2003 23:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zSuD-00068H-25; Tue, 16 Sep 2003 23:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zStq-00066U-JD for policy@optimus.ietf.org; Tue, 16 Sep 2003 23:22:38 -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 XAA26216 for ; Tue, 16 Sep 2003 23:22:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zSto-0007KR-00 for policy@ietf.org; Tue, 16 Sep 2003 23:22:36 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19zStn-0007KH-00 for policy@ietf.org; Tue, 16 Sep 2003 23:22:36 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 21:21:59 -0600 Message-ID: From: John Strassner To: "'Pana, Mircea'" , John Strassner , "'Joel M. Halpern'" , "'Larry S. Bartz'" , "'policy@ietf.org'" Cc: "'rmoats@lemurnetworks.net'" , "'David McTavish'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Tue, 16 Sep 2003 21:21:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37CCA.D938EB50" 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_01C37CCA.D938EB50 Content-Type: text/plain Hi there... regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 15, 2003 4:21 PM To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS John, Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list. There are a few clarifications that I'd like to ask for. See below in ... -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com ] Sent: Monday, September 15, 2003 9:15 AM To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? With respect to the second point, that's much better. I will provide comments on the schema itself next week. With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts. I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse. I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations. I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations. Thanks, Mircea. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com ] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com ] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37CCA.D938EB50 Content-Type: text/html RE: [Policy] PCLS classes deprecated in PCELS

Hi there...

 

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

John,

Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list.

There are a few clarifications that I'd like to ask for. See below in <mircea>..</mircea>.

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js>

With respect to the second point, that's much better. I will provide comments on the schema itself next week.

With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts.

<mircea>
I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse.

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations. I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations.
</js>

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be "OK" if PCELS did:
1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 

2. Use "for compliance with PCIMe implementations SHALL use <list schema items> instead of <list of schema items> for the realization of <concepts>" instead of deprecating PCLS classes. This would be added to a new revision of the ID.

I'm fine with both. (I hope I did not miss anything)
Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all.

Thanks,
Mircea.

 

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
>
>
> Ryan as just nicely explained this to me in a way that got it
> through my
> thick skull.  You both are correct.  We can not move existing classes.
>
> Hence, one needs to create new classes, and include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote:
> >Ryan Moats wrote, On 09/12/03 11:27:
> >[snip}
> >>Actually, that is a solution for all of the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every component of PCIMe which is
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or redefining anything from
> >PCLS, there can be no conflict with PCLS. And if everything new
> >which is introduced by PCELS is prefixed "pcime", there can be no
> >confusion about which is "core" and which is "extension".
> >
> >Such a strategy will ultimately satisfy Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I agree that
> "concerns about
> >PCELS should be in the context of support for PCIMe". I augment that
> >by saying that PCELS should not be concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) 226-6378
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
>
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37CCA.D938EB50-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 17 12:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18919 for ; Wed, 17 Sep 2003 12:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zesb-00056O-UP for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 12:10:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HGA9Cd019606 for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 12:10:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zesV-00055o-E6; Wed, 17 Sep 2003 12:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zesA-00055P-TM for policy@optimus.ietf.org; Wed, 17 Sep 2003 12:09:48 -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 MAA18880 for ; Wed, 17 Sep 2003 12:09:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zes9-0000Xk-00 for policy@ietf.org; Wed, 17 Sep 2003 12:09:41 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19zes8-0000XS-00 for policy@ietf.org; Wed, 17 Sep 2003 12:09:40 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Sep 2003 11:13:35 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'Joel M. Halpern'" , "'Larry S. Bartz'" , "'policy@ietf.org'" Cc: "'rmoats@lemurnetworks.net'" , "'David McTavish'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Wed, 17 Sep 2003 11:03:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D35.30641570" 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_01C37D35.30641570 Content-Type: text/plain; charset="iso-8859-1" John, see .. Thanks, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 16, 2003 11:22 PM To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: RE: [Policy] PCLS classes deprecated in PCELS Hi there... regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 15, 2003 4:21 PM To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS John, Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list. There are a few clarifications that I'd like to ask for. See below in ... -----Original Message----- From: John Strassner [ mailto:John.Strassner@intelliden.com ] Sent: Monday, September 15, 2003 9:15 AM To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. With respect to the second point, that's much better. I will provide comments on the schema itself next week. With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts. I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse. I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations. I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations. Peace! I totally agree that, to the extent posible, interoperability with the original schema and a peaceful coexistence should be (and will be) the goals of PCELS ;-) Thanks, Mircea. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [ mailto:mpana@metasolv.com ] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [ mailto:joel@stevecrocker.com ] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37D35.30641570 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
John,
 
see <mircea2>..</mircea2>
Thanks,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 16, 2003 11:22 PM
To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

Hi there...

 

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

John,

Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list.

There are a few clarifications that I'd like to ask for. See below in <mircea>..</mircea>.

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

With respect to the second point, that's much better. I will provide comments on the schema itself next week.

With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts.

<mircea>
I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse.

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations.   I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations.
</js> 

<mircea2>Peace! I totally agree that, to the extent posible, interoperability with the original schema and a peaceful coexistence should be (and will be) the goals of PCELS ;-)</mircea2>   

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be "OK" if PCELS did:
1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 

2. Use "for compliance with PCIMe implementations SHALL use <list schema items> instead of <list of schema items> for the realization of <concepts>" instead of deprecating PCLS classes. This would be added to a new revision of the ID.

I'm fine with both. (I hope I did not miss anything)
Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all.

Thanks,
Mircea.

 

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
>
>
> Ryan as just nicely explained this to me in a way that got it
> through my
> thick skull.  You both are correct.  We can not move existing classes.
>
> Hence, one needs to create new classes, and include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote:
> >Ryan Moats wrote, On 09/12/03 11:27:
> >[snip}
> >>Actually, that is a solution for all of the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every component of PCIMe which is
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or redefining anything from
> >PCLS, there can be no conflict with PCLS. And if everything new
> >which is introduced by PCELS is prefixed "pcime", there can be no
> >confusion about which is "core" and which is "extension".
> >
> >Such a strategy will ultimately satisfy Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I agree that
> "concerns about
> >PCELS should be in the context of support for PCIMe". I augment that
> >by saying that PCELS should not be concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) 226-6378
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
>
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37D35.30641570-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 17 16:49:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28863 for ; Wed, 17 Sep 2003 16:49:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjEa-0005zU-No for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 16:49:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HKn8sa023024 for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 16:49:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjET-0005yG-NX; Wed, 17 Sep 2003 16:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjER-0005xS-6H for policy@optimus.ietf.org; Wed, 17 Sep 2003 16:48:59 -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 QAA28792 for ; Wed, 17 Sep 2003 16:48:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjEP-0003Jh-00 for policy@ietf.org; Wed, 17 Sep 2003 16:48:57 -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 19zjEN-0003Ja-00 for policy@ietf.org; Wed, 17 Sep 2003 16:48:56 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 16:48:49 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , "'John Strassner'" , "'Joel M. Halpern'" , "'Larry S. Bartz'" , "'policy@ietf.org'" Cc: "'rmoats@lemurnetworks.net'" , David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Wed, 17 Sep 2003 16:48:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D5D.17E044B0" 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_01C37D5D.17E044B0 Content-Type: text/plain; charset="iso-8859-1" I'm getting the feeling that we are drifting from the original objective that the schema MUST NOT be deprecated in PCELS, but rather, extended. It would be nice if we could outline that a requirement of the PCELS is that no prior schema from PCIM is deprecated. I can't stress enough that deprecating schema in LDAP is on parallel to a cardinal sin, it should nearly be never done. I'm not trying to critique anybody's experience, but am only adding my extensive experience gained from working with LDAP hands-on, and with PCIM in particular. From practice, and having an LDAP-implemented PCIM solution in the field for almost a year now, it has come to our conclusion that if schema is designed incorrectly in the past, it is left as-is, and new schema is created to make up for the deficiency (unless we're adding new attributes to an object class). My interest in PCELS is solely from the perspective to protect our existing investment in PCIM and PCLS. Not to say that I don't appreciate what is occurring here, as I do, but there needs to be some level of formality going forward that appreciates the effort of the initial implementation (PCIM and PCLS), and parties using it. If PCIMe/PCELS is allowed to hijack the previous effort, then the point of having a "standard" is moot. There will be no standard, only a series of forked implementations. If the changes in PCIMe ARE necessary (I will argue that not all of them are later), then I suggest that we deprecate the current RFC dedicated to PCIM and PCLS and re-submit the standard as version 2.0. After debating these changes, my curiosity was piqued further to try to have a firmer understanding of why these changes need to come about in PCIMe/PCELS. Reviewing the Feb-2004 draft, I'm of the opinion that 50% of the document is duplicating existing PCIM implementation by renaming classes, and the other half is providing new functionality. I believe that changing class names for the sole sake of renaming the class is bad from a design standpoint, and worse from the perspective of existing implementations. (ie: all pcimRuleConditionList -> pcimConditionList changes should be outright dismissed and removed from the document). So that I can understand better, I've listed all of the new functionality proposed by PCIMe/PCELS. Please feel free to supplement with what I may have overlooked: - groups behave more like rules and inherit the following properties (priority, pcimRoles) - rules and groups have new properties (pcimDecisionStrategy) - rules have new property (pcimExecutionStrategy) - new pcimSimpleConditionAuxClass enables reusable variables and values - new pcimCompoundConditionAuxClass enables reusable collection of conditions - new pcimCompoundFilterAuxClass enables ??? - new pcimSimpleActionAuxClass enables reusable variables and values - new pcimCompoundActionAuxClass enables resuable collection of actions - new pcimVariable class - new pcimExplicitVariableAuxClass * as far as I can tell, an effort was made to make a somewhat exhaustive collection of AuxClass and pcimType objects to be included with Condition and Action instances. I appreciate the effort put into this, but wonder if the AuxClass instances are a little overboard? In most cases, people who are extending PCIM and PCIMe, will most likely want to have their own *ConditionAuxClass that extends from the VendorAuxClass in PCIM and add their appropriate fields as desired. ie: SandvineFilterConditionAuxClass extends VendorAuxClass and MAY { labelledURI, ipHostNumber }. Seeming as you can only inherit from one object class, I think preference should be left with the original PCIM implementation to extend from Vendor, instead of adding a large number of AuxClasses to a condition to provide the desired attribute types. We have to remember that this is only the core model of which implementations are going to be based, not the final product of implementation. That is for other standards like QoS to push forth and outline the exact format for conditions and actions to be implemented. Also, it would be nice to see some effort go into re-using existing IETF standardized LDAP "attributes", like labelledURI and ipServicePort (defined in RFC2307). I believe that interdependence on existing standards only solidifies the reason for existence of both standards. From what I believe is a duplicate of effort: - pcimPolicySet ~= pcimGroup - pcimPolicySetList = pcimRulesAuxContainedSet + pcimGroupsAuxContainedSet - pcimPolicySetAssociation ~= pcimGroupInstance + pcimRuleContainmentAuxClass + pcimGroupContainmentAuxClass - pcimReusableContainer == pcimRepository - pcimReusableContainerAuxClass == pcimRepositoryAuxClass - pcimReusableContainerInstace == pcimRepositoryInstance Things I disagree with: 5.6 pcimPolicyRule "If a pcimPolicyRule instance has a pcimConditionAuxClass attached to it then the attribute pcimConditionList SHOULD NOT be present in the same entry for the purpose of associating other conditions to the rule. However, when such situations occur the referenced conditions MUST NOT be considered as associated to the rule." - this means that re-usable conditions are not easily used in conjuction with customized conditions. ie: we use PCIM to specify rules for policy-based filtering. For instance, we may have a pre-defined condition that is linked through the pcimConditionList, but the individual user may update their policy so that the rule contains a TimePeriodCondition that specifies it only is valid between the hours of 9-5. With the above language, this sort of amalgamation of conditions is not valid. I believe the configuration SHOULD be correct, and the evaluation of the conditions are done on a priority-based level. Regards, d. ------_=_NextPart_001_01C37D5D.17E044B0 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
 
I'm getting the feeling that we are drifting from the original objective that the schema MUST NOT be deprecated in PCELS, but rather, extended. It would be nice if we could outline that a requirement of the PCELS is that no prior schema from PCIM is deprecated. I can't stress enough that deprecating schema in LDAP is on parallel to a cardinal sin, it should nearly be never done. I'm not trying to critique anybody's experience, but am only adding my extensive experience gained from working with LDAP hands-on, and with PCIM in particular.
From practice, and having an LDAP-implemented PCIM solution in the field for almost a year now, it has come to our conclusion that if schema is designed incorrectly in the past, it is left as-is, and new schema is created to make up for the deficiency (unless we're adding new attributes to an object class).  My interest in PCELS is solely from the perspective to protect our existing investment in PCIM and PCLS. Not to say that I don't appreciate what is occurring here, as I do, but there needs to be some level of formality going forward that appreciates the effort of the initial implementation (PCIM and PCLS), and parties using it. If PCIMe/PCELS is allowed to hijack the previous effort, then the point of having a "standard" is moot. There will be no standard, only a series of forked implementations.  If the changes in PCIMe ARE necessary (I will argue that not all of them are later), then I suggest that we deprecate the current RFC dedicated to PCIM and PCLS and re-submit the standard as version 2.0.
 
After debating these changes, my curiosity was piqued further to try to have a firmer understanding of why these changes need to come about in PCIMe/PCELS.  Reviewing the Feb-2004 draft, I'm of the opinion that 50% of the document is duplicating existing PCIM implementation by renaming classes, and the other half is providing new functionality. I believe that changing class names for the sole sake of renaming the class is bad from a design standpoint, and worse from the perspective of existing implementations. (ie: all pcimRuleConditionList -> pcimConditionList changes should be outright dismissed and removed from the document).
 
So that I can understand better, I've listed all of the new functionality proposed by PCIMe/PCELS. Please feel free to supplement with what I may have overlooked:
 - groups behave more like rules and inherit the following properties (priority, pcimRoles)
 - rules and groups have new properties (pcimDecisionStrategy)
 - rules have new property (pcimExecutionStrategy)
 - new pcimSimpleConditionAuxClass enables reusable variables and values
 - new pcimCompoundConditionAuxClass enables reusable collection of conditions
 - new pcimCompoundFilterAuxClass enables ???
 - new pcimSimpleActionAuxClass enables reusable variables and values
 - new pcimCompoundActionAuxClass enables resuable collection of actions
 - new pcimVariable class
 - new pcimExplicitVariableAuxClass
 * as far as I can tell, an effort was made to make a somewhat exhaustive collection of AuxClass and pcimType objects to be included with Condition and Action instances.  I appreciate the effort put into this, but wonder if the AuxClass instances are a little overboard? In most cases, people who are extending PCIM and PCIMe, will most likely want to have their own *ConditionAuxClass that extends from the VendorAuxClass in PCIM and add their appropriate fields as desired. ie: SandvineFilterConditionAuxClass extends VendorAuxClass and MAY { labelledURI, ipHostNumber }. Seeming as you can only inherit from one object class, I think preference should be left with the original PCIM implementation to extend from Vendor, instead of adding a large number of AuxClasses to a condition to provide the desired attribute types. We have to remember that this is only the core model of which implementations are going to be based, not the final product of implementation. That is for other standards like QoS to push forth and outline the exact format for conditions and actions to be implemented.
 
Also, it would be nice to see some effort go into re-using existing IETF standardized LDAP "attributes", like labelledURI and ipServicePort (defined in RFC2307). I believe that interdependence on existing standards only solidifies the reason for existence of both standards.
 
From what I believe is a duplicate of effort:
 - pcimPolicySet ~= pcimGroup
 - pcimPolicySetList = pcimRulesAuxContainedSet + pcimGroupsAuxContainedSet
 - pcimPolicySetAssociation ~= pcimGroupInstance + pcimRuleContainmentAuxClass + pcimGroupContainmentAuxClass
 - pcimReusableContainer == pcimRepository
 - pcimReusableContainerAuxClass == pcimRepositoryAuxClass
 - pcimReusableContainerInstace == pcimRepositoryInstance
 
 
Things I disagree with:
5.6 pcimPolicyRule "If a pcimPolicyRule instance has a pcimConditionAuxClass attached to it then the attribute pcimConditionList SHOULD NOT be present in the same entry for the purpose of associating other conditions to the rule. However, when such situations occur the referenced conditions MUST NOT be considered as associated to the rule."
 - this means that re-usable conditions are not easily used in conjuction with customized conditions. ie: we use PCIM to specify rules for policy-based filtering. For instance, we may have a pre-defined condition that is linked through the pcimConditionList, but the individual user may update their policy so that the rule contains a TimePeriodCondition that specifies it only is valid between the hours of 9-5. With the above language, this sort of amalgamation of conditions is not valid. I believe the configuration SHOULD be correct, and the evaluation of the conditions are done on a priority-based level.
 
 
Regards,
d.
 
 
 
 
------_=_NextPart_001_01C37D5D.17E044B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 17 22:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09885 for ; Wed, 17 Sep 2003 22:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoHC-0007KM-VO for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 22:12:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I2CAY0028162 for policy-archive@odin.ietf.org; Wed, 17 Sep 2003 22:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zoH4-0007Jv-RV; Wed, 17 Sep 2003 22:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zgKb-0008Ep-Ts for policy@optimus.ietf.org; Wed, 17 Sep 2003 13:43:12 -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 NAA21477 for ; Wed, 17 Sep 2003 13:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zgKZ-0001Sb-00 for policy@ietf.org; Wed, 17 Sep 2003 13:43:07 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 19zgKY-0001SN-00 for policy@ietf.org; Wed, 17 Sep 2003 13:43:06 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Sep 2003 11:42:35 -0600 Message-ID: From: John Strassner To: "Pana, Mircea" , "'John Strassner'" , "'Joel M. Halpern'" , "'Larry S. Bartz'" , "'policy@ietf.org'" Cc: "'rmoats@lemurnetworks.net'" , "'David McTavish'" Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Date: Wed, 17 Sep 2003 11:42:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37D43.134A1990" 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_01C37D43.134A1990 Content-Type: text/plain Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. :-) John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Wednesday, September 17, 2003 10:03 AM To: 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: RE: [Policy] PCLS classes deprecated in PCELS John, see .. Thanks, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 16, 2003 11:22 PM To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: RE: [Policy] PCLS classes deprecated in PCELS Hi there... regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 15, 2003 4:21 PM To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS John, Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list. There are a few clarifications that I'd like to ask for. See below in ... -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com ] Sent: Monday, September 15, 2003 9:15 AM To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. With respect to the second point, that's much better. I will provide comments on the schema itself next week. With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts. I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse. I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations. I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations. Peace! I totally agree that, to the extent posible, interoperability with the original schema and a peaceful coexistence should be (and will be) the goals of PCELS ;-) Thanks, Mircea. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com ] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org' Cc: rmoats@lemurnetworks.net; David McTavish Subject: RE: [Policy] PCLS classes deprecated in PCELS So, if I understand correctly, everything would be "OK" if PCELS did: 1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 2. Use "for compliance with PCIMe implementations SHALL use instead of for the realization of " instead of deprecating PCLS classes. This would be added to a new revision of the ID. I'm fine with both. (I hope I did not miss anything) Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all. Thanks, Mircea. > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com ] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; 'policy@ietf.org' > Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > Ryan as just nicely explained this to me in a way that got it > through my > thick skull. You both are correct. We can not move existing classes. > > Hence, one needs to create new classes, and include text that > says "use > this instead of the old thing". > > Unfortunate, but really a common problem with class naming / > inheritance > (not specific to just LDAP). > > As I said to Ryan, thanks for the patience explaining this. > Joel > > At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: > >Ryan Moats wrote, On 09/12/03 11:27: > >[snip} > >>Actually, that is a solution for all of the subclass cases: > in PCELS call > >>tem pcime*, give them different OIDs from what's in PCLS > and then everything > >>is ok. > > > >I'll go further and suggest that every component of PCIMe which is > >not exactly as defined in PCLS should be prefixed "pcime". If PCELS > >simply avoids deprecating, renaming, or redefining anything from > >PCLS, there can be no conflict with PCLS. And if everything new > >which is introduced by PCELS is prefixed "pcime", there can be no > >confusion about which is "core" and which is "extension". > > > >Such a strategy will ultimately satisfy Joel's concerns, > when he wrote: > > > My feeling is that concerns about PCELS should be in the > context of > > > support for PCIMe, > >and > > > if one can accurately map PCIMe to LDAP in a way that is > compatible > > > with PCLS, then that would clearly seem desirable > > > >PCELS should map PCIMe to LDAP in a way which is not > INcompatible with > >PCLS, in a way which does not break PCLS. I agree that > "concerns about > >PCELS should be in the context of support for PCIMe". I augment that > >by saying that PCELS should not be concerned with recasting PCLS in > >any way. > > > >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any > >impact on PCLS. > > > > > >-- > >-- > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > ># Larry Bartz > ># > ># voice (317) 226-7060 > ># FAX (317) 226-6378 > >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > ::::::::::| > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37D43.134A1990 Content-Type: text/html RE: [Policy] PCLS classes deprecated in PCELS

Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.

I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.
</js>

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Wednesday, September 17, 2003 10:03 AM
To: 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

John,

 

see <mircea2>..</mircea2>

Thanks,

Mircea.

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 16, 2003 11:22 PM
To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

Hi there...

 

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

John,

Thanks for the detailed comments and suggestions. This is greatly appreciated. As already noted, there will be a PCELS revision shortly. This revision will take into account the suggestions that you and the other participants made on the list.

There are a few clarifications that I'd like to ask for. See below in <mircea>..</mircea>.

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Monday, September 15, 2003 9:15 AM
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

 

With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

With respect to the second point, that's much better. I will provide comments on the schema itself next week.

With respect to naming, I don't understand the problem. You have build a new design, not an update of an existing design. Thus, new concepts should be assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas existing concepts should be assigned the pcim prefix. Thus, it is not a "everything or nothing" decision but instead a judicious application of new (pcels) vs old (pcim) concepts.

<mircea>
I have heard valid arguments for using a different naming prefix in PCELS than the one used by PCLS. These arguments are based on the view that PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one point of view. Mine is that PCIM/PCLS alone is incomplete and that only *together* with PCIMe/PCELS it provides THE Framework for the development of domain specific submodels. Both produced by the same WG btw. (I'm not going to argue that though - it seems to be a sore spot!) For me, the naming prefix is a minor issue and I can live with a different prefix if people are so strongly against reuse.

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have already heard that many people have built implementations.   I think that the goal has to be interoperability and peaceful coexistence between PCLS and PCELS implementations.
</js> 

<mircea2>Peace! I totally agree that, to the extent posible, interoperability with the original schema and a peaceful coexistence should be (and will be) the goals of PCELS ;-)</mircea2>   

Thanks,
Mircea.
</mircea>

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Friday, September 12, 2003 3:11 PM
To: 'Joel M. Halpern'; Larry S. Bartz; 'policy@ietf.org'
Cc: rmoats@lemurnetworks.net; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

So, if I understand correctly, everything would be "OK" if PCELS did:
1. Define only subclasses of PCLS classes and, where not possible, redefine PCLS concepts as new classes (use different names and oid.s). This is already the case in the currently published ID with the exception of pcimGroup* that would need to be redefined with a different name. 

2. Use "for compliance with PCIMe implementations SHALL use <list schema items> instead of <list of schema items> for the realization of <concepts>" instead of deprecating PCLS classes. This would be added to a new revision of the ID.

I'm fine with both. (I hope I did not miss anything)
Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as there are no naming conflicts, I would prefer to avoid it if possible. Could you live with that? However if we have to do it for one item we should do it for all.

Thanks,
Mircea.

 

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Friday, September 12, 2003 1:50 PM
> To: Larry S. Bartz; 'policy@ietf.org'
> Cc: rmoats@lemurnetworks.net; David McTavish; Pana, Mircea
> Subject: Re: [Policy] PCLS classes deprecated in PCELS
>
>
> Ryan as just nicely explained this to me in a way that got it
> through my
> thick skull.  You both are correct.  We can not move existing classes.
>
> Hence, one needs to create new classes, and include text that
> says "use
> this instead of the old thing".
>
> Unfortunate, but really a common problem with class naming /
> inheritance
> (not specific to just LDAP).
>
> As I said to Ryan, thanks for the patience explaining this.
> Joel
>
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote:
> >Ryan Moats wrote, On 09/12/03 11:27:
> >[snip}
> >>Actually, that is a solution for all of the subclass cases:
> in PCELS call
> >>tem pcime*, give them different OIDs from what's in PCLS
> and then everything
> >>is ok.
> >
> >I'll go further and suggest that every component of PCIMe which is
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS
> >simply avoids deprecating, renaming, or redefining anything from
> >PCLS, there can be no conflict with PCLS. And if everything new
> >which is introduced by PCELS is prefixed "pcime", there can be no
> >confusion about which is "core" and which is "extension".
> >
> >Such a strategy will ultimately satisfy Joel's concerns,
> when he wrote:
> > > My feeling is that concerns about PCELS should be in the
> context of
> > > support for PCIMe,
> >and
> > > if one can accurately map PCIMe to LDAP in a way that is
> compatible
> > > with PCLS, then that would clearly seem desirable
> >
> >PCELS should map PCIMe to LDAP in a way which is not
> INcompatible with
> >PCLS, in a way which does not break PCLS. I agree that
> "concerns about
> >PCELS should be in the context of support for PCIMe". I augment that
> >by saying that PCELS should not be concerned with recasting PCLS in
> >any way.
> >
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any
> >impact on PCLS.
> >
> >
> >--
> >--
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
> ># Larry Bartz
> >#
> >#  voice (317) 226-7060
> >#  FAX   (317) 226-6378
> >#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::|
>
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37D43.134A1990-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 18 13:02:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23595 for ; Thu, 18 Sep 2003 13:02:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02AT-00087C-LF for policy-archive@odin.ietf.org; Thu, 18 Sep 2003 13:02:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IH29jP031187 for policy-archive@odin.ietf.org; Thu, 18 Sep 2003 13:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02AM-00086B-Br; Thu, 18 Sep 2003 13:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A029o-00083C-EY for policy@optimus.ietf.org; Thu, 18 Sep 2003 13:01:28 -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 NAA23566 for ; Thu, 18 Sep 2003 13:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A029m-0003Mu-00 for policy@ietf.org; Thu, 18 Sep 2003 13:01:26 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A029m-0003KX-00 for policy@ietf.org; Thu, 18 Sep 2003 13:01:26 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Thu, 18 Sep 2003 12:05:25 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'policy@ietf.org'" Date: Thu, 18 Sep 2003 11:56:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E05.CC8F5E70" Subject: [Policy] RE: Trouble with attributes 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_01C37E05.CC8F5E70 Content-Type: text/plain; charset="iso-8859-1" John, I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time. Respectfully, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. :-) John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. Yet Mircea replies: BTW: I am commenting on PCELS -03 published in August 2003. On (1) above: The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error. On (2) above: - LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse. - An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set. Respectfully, Mircea. ------_=_NextPart_001_01C37E05.CC8F5E70 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
John,
 
I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time.
 
Respectfully,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS

Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.

I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.
</js> 

 

Yet Mircea replies: 

<mircea3>

BTW: I am commenting on PCELS -03 published in August 2003.

On (1) above:

 The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error.

On (2) above:

- LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse.

- An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set.

</mircea3> 

 

Respectfully,
Mircea.
------_=_NextPart_001_01C37E05.CC8F5E70-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Thu Sep 18 13:31:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24558 for ; Thu, 18 Sep 2003 13:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02cR-0002SE-Gd for policy-archive@odin.ietf.org; Thu, 18 Sep 2003 13:31:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IHV303009434 for policy-archive@odin.ietf.org; Thu, 18 Sep 2003 13:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02cP-0002RX-VO; Thu, 18 Sep 2003 13:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02bg-0002Me-IU for policy@optimus.ietf.org; Thu, 18 Sep 2003 13:30:16 -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 NAA24502 for ; Thu, 18 Sep 2003 13:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A02be-0005cJ-00 for policy@ietf.org; Thu, 18 Sep 2003 13:30:14 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A02bd-0005Zp-00 for policy@ietf.org; Thu, 18 Sep 2003 13:30:13 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 11:29:41 -0600 Message-ID: From: John Strassner To: "'Pana, Mircea'" , John Strassner , "'policy@ietf.org'" Date: Thu, 18 Sep 2003 11:29:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E0A.70E8BEE0" Subject: [Policy] RE: Trouble with attributes 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_01C37E0A.70E8BEE0 Content-Type: text/plain Mircea, Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that. Trust me, I know how to write an LDAP filter. :-) But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Thursday, September 18, 2003 10:56 AM To: 'John Strassner'; 'policy@ietf.org' Subject: RE: Trouble with attributes John, I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time. Respectfully, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. :-) John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. Yet Mircea replies: BTW: I am commenting on PCELS -03 published in August 2003. On (1) above: The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error. On (2) above: - LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse. - An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set. Respectfully, Mircea. ------_=_NextPart_001_01C37E0A.70E8BEE0 Content-Type: text/html RE: [Policy] PCLS classes deprecated in PCELS

Mircea,

 

Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that.

 

Trust me, I know how to write an LDAP filter. J  But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense?

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; 'policy@ietf.org'
Subject: RE: Trouble with attributes

 

John,

 

I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time.

 

Respectfully,

Mircea.

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS

Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.

I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.
</js> 

 

Yet Mircea replies: 

<mircea3>

BTW: I am commenting on PCELS -03 published in August 2003.

On (1) above:

 The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error.

On (2) above:

- LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse.

- An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set.

</mircea3> 

 

Respectfully,

Mircea.

------_=_NextPart_001_01C37E0A.70E8BEE0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 19 21:36:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00192 for ; Fri, 19 Sep 2003 21:36:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9n020140 for ; Fri, 19 Sep 2003 21:36:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TKkOB7012862 for policy-archive@odin.ietf.org; Fri, 29 Aug 2003 16:46:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snve-0005PE-TJ; Fri, 29 Aug 2003 14:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skxx-0004yR-Go for policy@optimus.ietf.org; Fri, 29 Aug 2003 11:15: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 LAA01798 for ; Fri, 29 Aug 2003 11:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skxw-0005Mb-00 for policy@ietf.org; Fri, 29 Aug 2003 11:15:08 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19skxw-0005ME-00 for policy@ietf.org; Fri, 29 Aug 2003 11:15:08 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7TFEYC15923 for ; Fri, 29 Aug 2003 10:14:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Fri, 29 Aug 2003 17:14:33 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550233144C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: policy@ietf.org Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt Date: Fri, 29 Aug 2003 17:14:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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: , What an underwhelming interest in this document. When I start reading it, I see in the abstract: This document defines a number of changes and extensions to the Policy Core LDAP Schema [PCLS] based on the specifications of the Policy Core Information Model Extensions [PCIM_EXT]. The changes include additional object classes previously not covered, deprecation of some object classes and changes to the object class hierarchy defined in [PCLS]. And so I immediately wonder... is it really OK that this document deprecates some object classes ?? Possibly so... but I'd like to hear some of the PCIM, PCIM-EXT and PCLS authors/ediotrs to explicitly say so. PLEASE! Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: vrijdag 15 augustus 2003 11:45 > To: policy@ietf.org > Subject: RE: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > Joel asked from the WG: > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > Sent: woensdag 6 augustus 2003 17:33 > > To: policy@ietf.org > > Subject: [Policy] Re: draft-reyes-policy-core-ext-schema-03.txt > > > > > > The revised Internet draft is now available in the I-D repository: > > http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ex > > t-schema-03.txt > > > > I believe it is appropriate for this document to go forward as an > > individual contribution that has been reviewed by a (our) > working group. > > As such, I will give folks one more chance to comment > before indicating > > that the author's can (and should) contact the AD for this. > > Please respond by August 20 (preferably sooner) with any comments, > > concerns, issues, etc. It would even be helpful if folks > would merely > > indicate that they had read and liked the document. > > > > So did anyone actually READ (or even BROWSE) the document??? > > PLEASE be active and participate! > > Bert > > Thank you, > > Joel M. Halpern > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 19 21:36:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00120 for ; Fri, 19 Sep 2003 21:36:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1Vh9Z020140 for ; Fri, 19 Sep 2003 21:36:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CG750g024566 for policy-archive@odin.ietf.org; Fri, 12 Sep 2003 12:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRs-0006Nn-Db; Fri, 12 Sep 2003 12:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xqRS-0006JS-Qg for policy@optimus.ietf.org; Fri, 12 Sep 2003 12:06:42 -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 MAA29770 for ; Fri, 12 Sep 2003 12:06:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xqRR-0000lv-00 for policy@ietf.org; Fri, 12 Sep 2003 12:06:37 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 19xqRP-0000kJ-00 for policy@ietf.org; Fri, 12 Sep 2003 12:06:36 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Fri, 12 Sep 2003 11:10:05 -0500 Message-ID: From: "Pana, Mircea" To: "'rmoats@lemurnetworks.net'" , David McTavish Cc: "'policy@ietf.org'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Fri, 12 Sep 2003 11:01:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37947.2300A6B0" 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_01C37947.2300A6B0 Content-Type: text/plain; charset="iso-8859-1" I would like to understand why you have a problem with PCELS inserting a new class in the inheritance chain of a PCLS defined class. Let's take #6 for example: PCELS defines a new class pcimReusableContainer and makes the existing pcimRepository a subclass of the new one. Thus, once/if the PCELS schema is (incrementally) applied to the Directory server: A. a PCLS implementation continues to handle pcimRepository entries just like it did before B. because a pcimRepository is also a pcimReusableContainer, a PCELS implementation can also handle such entry correctly (i.e. as a container of reusable policy components) C. for a PCELS implementation, the presence of the pcimRepository class in a pcimReusableContainer entry can trigger additional safeguards to allow the entry to continue to be compatible with PCLS D. a PCELS implementation that intends to comply with PCIMe would create pcimReusableContainer entries that are not pcimRepository. IMO, if it was the other way around (pcimReusableContainer defined as subclass of pcimRepository) then D. would never be possible because a pcimReusableContainer would also be a pcimRepository therefore violating the PCIMe recommendation. What situation did you have in mind when you stated that such change would break PCLS or existing implementations? Thanks, Mircea. > -----Original Message----- > From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > Sent: Thursday, September 11, 2003 8:21 PM > To: David McTavish > Cc: Pana, Mircea; 'policy@ietf.org'; 'bwijnen@lucent.com' > Subject: Re: [Policy] PCLS classes deprecated in PCELS > > > On Thu, Sep 11, 2003 at 07:36:05PM -0400, David McTavish wrote: > | I agree with Ryan for all points except point 6, although, > I believe that > | this change would be easier to manage than in the initial proposal. > | > | d. > > David is right, I misread #6. That has the same problem as #3-5. > > Ryan > > | -----Original Message----- > | From: Ryan Moats [mailto:rmoats@lemurnetworks.net] > | Sent: Thursday, September 11, 2003 7:07 PM > | To: Pana, Mircea > | Cc: 'policy@ietf.org'; 'bwijnen@lucent.com' > | Subject: Re: [Policy] PCLS classes deprecated in PCELS > | > | > | On Thu, Sep 11, 2003 at 05:21:42PM -0500, Pana, Mircea wrote: > | | IMO the usage of schema items corresponding to deprecated > concepts would > | be > | | in conflict with the model (in this case PCIMe). However, > a "peaceful > | | co-existence" would be a very good reason for compromise. > The following > | | proposal gets PCELS out of the "policing business" and > where compliance > | with > | | PCIMe requires PCLS classes or attributes not to be used, > this is noted > | with > | | the specific indication "for compliance with PCIMe implementations > | | shall/shall not use ..." (or rather SHALL / SHALL NOT). I > hope you will > | find > | | the following acceptable: > | | > | | 1. Replace the pcimGroupContainmentAuxClass class > deprecation with a > | | paragraph to indicate that "for compliance with PCIMe, > implementations > | shall > | | use the pcimPolicySet.pcimPolicySetComponentList attribute and a > | | subordinated pcimPolicySetAssociation entry instead of an attached > | | pcimGroupContainmentAuxClass to aggregate Policy Groups > in a Policy Group, > | | Rule or System". > | | > | | 2. Replace the pcimRuleContainmentAuxClass class > deprecation with a > | | paragraph to indicate that "for compliance with PCIMe, > implementations > | | shall use the pcimPolicySet.pcimPolicySetComponentList > attribute and a > | | subordinated pcimPolicySetAssociation entry instead of an attached > | | pcimRuleContainmentAuxClass to aggregate Policy Rules in > a Policy Group, > | | Rule or System". > | > | I can live with these two... > | > | | 3. The pcimRule* classes would not be deprecated. > Instead, the abstract > | | class pcimRule would be modified to become a subclass of > the abstract > | class > | | pcimPolicyRule defined in PCELS. A note would be added to > indicate that > | "for > | | compliance with PCIMe, implementations shall not use the > | | pcimRule.pcimRulePriority attribute". See also Note_1 below. > | | > | | 4. The class pcimRuleConditionAssociation would be > modified to become > | | subclass of the pcimConditionAssociation class. > | | > | | 5. The class pcimRuleActionAssociation would be modified to become > | subclass > | | of the pcimActionAssociation class. > | > | I can't live with these three: they would require me to > change my working > | implementation and change the PCLS schema. > | > | If you are going to do a subclass here and not break PCLS > or existing > | implementations, you have to go the other way: > | pcimPolicyRule is a subclass of pcimRule, > pcimConditionAssociation as a > | subclass of pcimRuleConditionAssociation, etc. This > changes Note #1 to > | what are the issues for pcimPolicyRule... > | > | | 6. The pcimRepository* classes would not be deprecated. > Instead the > | abstract > | | class pcimRepository would be modified to become subclass > of the abstract > | | class pcimReusableContainer defined in PCELS. PCELS would > indicate that > | "for > | | compliance with PCIMe, the pcimReusableContainer* classes > shall be used > | | instead of the pcimRepository* classes". > | > | Again, I can live with #6. > | > | Ryan > | > | _______________________________________________ > | Policy mailing list > | Policy@ietf.org > | https://www1.ietf.org/mailman/listinfo/policy > | > | _______________________________________________ > | Policy mailing list > | Policy@ietf.org > | https://www1.ietf.org/mailman/listinfo/policy > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > ------_=_NextPart_001_01C37947.2300A6B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] PCLS classes deprecated in PCELS

I would like to understand why you have a problem = with PCELS inserting a new class in the inheritance chain of a PCLS = defined class.

 
Let's take #6 for example: PCELS defines a new class = pcimReusableContainer and makes the existing pcimRepository a subclass = of the new one. Thus, once/if the PCELS schema is (incrementally) = applied to the Directory server:

A. a PCLS implementation continues to handle = pcimRepository entries just like it did before
B. because a pcimRepository is also a = pcimReusableContainer, a PCELS implementation can also handle such = entry correctly (i.e. as a container of reusable policy = components)

C. for a PCELS implementation, the presence of the = pcimRepository class in a pcimReusableContainer entry can trigger = additional safeguards to allow the entry to continue to be compatible = with PCLS

D. a PCELS implementation that intends to comply with = PCIMe would create pcimReusableContainer entries that are not = pcimRepository.

IMO, if it was the other way around = (pcimReusableContainer defined as subclass of pcimRepository) then D. = would never be possible because a pcimReusableContainer would also be a = pcimRepository therefore violating the PCIMe recommendation.

What situation did you have in mind when you stated = that such change would break PCLS or existing implementations?

Thanks,
Mircea.




> -----Original Message-----
> From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> Sent: Thursday, September 11, 2003 8:21 = PM
> To: David McTavish
> Cc: Pana, Mircea; 'policy@ietf.org'; = 'bwijnen@lucent.com'
> Subject: Re: [Policy] PCLS classes deprecated = in PCELS
>
>
> On Thu, Sep 11, 2003 at 07:36:05PM -0400, David = McTavish wrote:
> | I agree with Ryan for all points except point = 6, although,
> I believe that
> | this change would be easier to manage than in = the initial proposal.
> |
> | d.
>
> David is right, I misread #6.  That has = the same problem as #3-5.
>
> Ryan
>
> | -----Original Message-----
> | From: Ryan Moats [mailto:rmoats@lemurnetworks.net= ]
> | Sent: Thursday, September 11, 2003 7:07 = PM
> | To: Pana, Mircea
> | Cc: 'policy@ietf.org'; = 'bwijnen@lucent.com'
> | Subject: Re: [Policy] PCLS classes deprecated = in PCELS
> |
> |
> | On Thu, Sep 11, 2003 at 05:21:42PM -0500, = Pana, Mircea wrote:
> | | IMO the usage of schema items corresponding = to deprecated
> concepts would
> | be
> | | in conflict with the model (in this case = PCIMe). However,
> a "peaceful
> | | co-existence" would be a very good = reason for compromise.
> The following
> | | proposal gets PCELS out of the = "policing business" and
> where compliance
> | with
> | | PCIMe requires PCLS classes or attributes = not to be used,
> this is noted
> | with
> | | the specific indication "for = compliance with PCIMe implementations
> | | shall/shall not use ..." (or rather = SHALL / SHALL NOT). I
> hope you will
> | find
> | | the following acceptable:
> | |
> | | 1. Replace the pcimGroupContainmentAuxClass = class
> deprecation with a
> | | paragraph to indicate that "for = compliance with PCIMe,
> implementations
> | shall
> | | use the = pcimPolicySet.pcimPolicySetComponentList attribute and a
> | | subordinated pcimPolicySetAssociation entry = instead of an attached
> | | pcimGroupContainmentAuxClass to aggregate = Policy Groups
> in a Policy Group,
> | | Rule or System".
> | |
> | | 2. Replace the pcimRuleContainmentAuxClass = class
> deprecation with a
> | | paragraph to indicate that "for = compliance with PCIMe, 
> implementations
> | | shall use the = pcimPolicySet.pcimPolicySetComponentList
> attribute and a
> | | subordinated pcimPolicySetAssociation entry = instead of an attached
> | | pcimRuleContainmentAuxClass to aggregate = Policy Rules in
> a Policy Group,
> | | Rule or System".
> |
> | I can live with these two...
> |
> | | 3. The pcimRule* classes would not be = deprecated.
> Instead, the abstract
> | | class pcimRule would be modified to become = a subclass of
> the abstract
> | class
> | | pcimPolicyRule defined in PCELS. A note = would be added to
> indicate that
> | "for
> | | compliance with PCIMe, implementations = shall not use the
> | | pcimRule.pcimRulePriority attribute". = See also Note_1 below.
> | |
> | | 4. The class pcimRuleConditionAssociation = would be
> modified to become
> | | subclass of the pcimConditionAssociation = class.
> | |
> | | 5. The class pcimRuleActionAssociation = would be modified to become
> | subclass
> | | of the pcimActionAssociation class.
> |
> | I can't live with these three: they would = require me to
> change my working
> | implementation and change the PCLS schema. =
> |
> | If you are going to do a subclass here and = not break PCLS
> or existing
> | implementations, you have to go the other = way:
> | pcimPolicyRule is a subclass of pcimRule, =
> pcimConditionAssociation as a
> | subclass of pcimRuleConditionAssociation, = etc.  This
> changes Note #1 to
> | what are the issues for = pcimPolicyRule...
> |
> | | 6. The pcimRepository* classes would not be = deprecated.
> Instead the
> | abstract
> | | class pcimRepository would be modified to = become subclass
> of the abstract
> | | class pcimReusableContainer defined in = PCELS. PCELS would
> indicate that
> | "for
> | | compliance with PCIMe, the = pcimReusableContainer* classes
> shall be used
> | | instead of the pcimRepository* = classes".
> |
> | Again, I can live with #6.
> |
> | Ryan
> |
> | = _______________________________________________
> | Policy mailing list
> | Policy@ietf.org
> | https://www1.ietf.org/mailman/listinfo/policy
> |
> | = _______________________________________________
> | Policy mailing list
> | Policy@ietf.org
> | https://www1.ietf.org/mailman/listinfo/policy
>
> = _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>

------_=_NextPart_001_01C37947.2300A6B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sat Sep 20 09:53:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04300 for ; Sat, 20 Sep 2003 09:53:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P6H-00053A-S1 for policy-archive@odin.ietf.org; Fri, 19 Sep 2003 13:31:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHVLjh019408 for policy-archive@odin.ietf.org; Fri, 19 Sep 2003 13:31:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0P5z-000516-D3; Fri, 19 Sep 2003 13:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OkF-0001V2-Lw for policy@optimus.ietf.org; Fri, 19 Sep 2003 13:08:35 -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 MAA08184 for ; Fri, 19 Sep 2003 12:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A05c2-0006Wn-00 for policy@ietf.org; Thu, 18 Sep 2003 16:42:50 -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 1A05Q9-0005RI-00 for policy@ietf.org; Thu, 18 Sep 2003 16:30:33 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 16:30:28 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , "'John Strassner'" , "'policy@ietf.org'" Subject: RE: [Policy] RE: Trouble with attributes Date: Thu, 18 Sep 2003 16:30:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E23.B0B23510" 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_01C37E23.B0B23510 Content-Type: text/plain; charset="iso-8859-1" I've decided to supplement my previous email with some in-depth analysis of the proposed PCELS to act as a guide in how to bridge the two standards. Please note, that this is not an extensive review, as sections 5.25 through 5.31 warrant an alternate thread altogether (in which I would argue that alot of these characteristics should inherit from RFC 2307 with some careful extensions), and I'd prefer to open that can of worms at a later date. :) Please discuss the following suggestions, as I believe they encompass what PCIMe is trying to accomplish, while preserving prior effort from PCIM. I apologize that I haven't outlined WHY I'm suggesting the following, as I'm hoping that review of the suggestions against both drafts will explain. However, if anyone has any questions in regard to some of the tactics I'm suggesting (proposing to use auxiliary classes to extend existing PCIM classes instead of deprecating and creating a new class), please direct to the list to flesh these ideas out. 5.1 pcimPolicySet - use existing pcimGroup object pcimPolicySetName - use existing pcimGroupName attr pcimPriority - use new pcimGroupPriority attr pcimPolicySetList - use combination of existing pcimGroupsAuxContainedSet and pcimRulesAuxContainedSet pcimDecisionStrategy pcimGroupPriorityAuxClass pcimGroupPriority pcimDecisionStrategyAuxClass pcimGroupRolesAuxClass { IANA-ASSIGNED-OID.1.x NAME 'pcimGroupPriorityAuxClass' DESC 'Auxiliary class that represents a level of priority for a particular group.' SUP pcimGroup AUXILIARY MAY { pcimGroupPriority } } { IANA-ASSIGNED-OID.2.x NAME 'pcimGroupPriority' DESC 'Group priority.' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) { IANA-ASSIGNED-OID.1.x NAME 'pcimDecisionStrategyAuxClass' DESC 'Auxiliary class that enables a rule or group to contain decision and execution strategy symantecs.' SUP pcimPolicy AUXILIARY MAY { pcimDecisionStrategy } } { IANA-ASSIGNED-OID.1.x NAME 'pcimGroupRolesAuxClass' DESC 'Auxiliary class that enables a group to contain role-based information.' SUP pcimGroup AUXILIARY MAY { pcimRoles } } 5.2 pcimPolicySetAssociation - use existing pcimGroupInstance object pcimPriority - use suggested pcimGroupPriority as above pcimPolicySetDN - use 5.3 5.4 5.5 5.6 pcimPolicyRule - use existing pcimRule object pcimPolicyRuleAuxClass - use existing pcimRuleAuxClass pcimPolicyRuleInstance - use existing pcimRuleInstance pcimConditionListType - use existing pcimRuleConditionListType pcimConditionList - use existing pcimRuleConditionList pcimActionList - use existing pcimRuleActionList pcimSequencedActions - use existing pcimRuleSequencedActions pcimExecutionStrategy pcimExecutionStrategyAuxClass { IANA-ASSIGNED-OID.1.x NAME 'pcimExecutionStrategyAuxClass' DESC 'Auxiliary class that enables a rule to contain execution strategy information.' SUP pcimRule AUXILIARY MAY { pcimExecutionStrategy } } 5.7 pcimConditionAssociation - use existing pcimRuleConditionAssociation 5.8 pcimActionAssociation - use existing pcimRuleActionAssociation 5.9 5.10 5.11 5.12 pcimSimpleConditionAuxClass 5.13 pcimCompoundConditionAuxClass 5.14 pcimCompoundFilterConditionAuxClass although, I'd like some explanation of what this is for... 5.15 pcimSimpleActionAuxClass 5.16 pcimCompoundActionAuxClass 5.17 pcimVariable 5.18 pcimExplicitVariableAuxClass 5.19 pcimImplicitVariableAuxClass 5.20 is merged with 5.19 to follow pattern of previous sections containing attributes pcim*AuxClass 5.21 5.22 5.23 pcimReusableContainer - use existing pcimRepository pcimReusableContainerAuxClass - use existing pcimRepositoryAuxClass pcimReusableContainerInstance - use existing pcimRepositoryInstance pcimReusableContainerName - use existing pcimRepositoryName pcimReusableContainerList - use new pcimRepositoryList pcimRepositoryContainmentAuxClass pcimRepositoryList { IANA-ASSIGNED-OID.1.x NAME 'pcimRepositoryContainmentAuxClass' DESC 'Auxiliary class that enables an object to aggregate reusable repository containers.' SUP pcimRepositoryAuxClass AUXILIARY MAY { pcimRepositoryList } } { IANA-ASSIGNED-OID.1.x NAME 'pcimRepositoryList' DESC 'blah blah blah...' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE } 5.24 Regards, d. ------_=_NextPart_001_01C37E23.B0B23510 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
I've decided to supplement my previous email with some in-depth analysis of the proposed PCELS to act as a guide in how to bridge the two standards. Please note, that this is not an extensive review, as sections 5.25 through 5.31 warrant an alternate thread altogether (in which I would argue that alot of these characteristics should inherit from RFC 2307 with some careful extensions), and I'd prefer to open that can of worms at a later date. :)
 
Please discuss the following suggestions, as I believe they encompass what PCIMe is trying to accomplish, while preserving prior effort from PCIM. I apologize that I haven't outlined WHY I'm suggesting the following, as I'm hoping that review of the suggestions against both drafts will explain.  However, if anyone has any questions in regard to some of the tactics I'm suggesting (proposing to use auxiliary classes to extend existing PCIM classes instead of deprecating and creating a new class), please direct to the list to flesh these ideas out.
 
5.1 pcimPolicySet <removed>            - use existing pcimGroup object
    pcimPolicySetName <removed>        - use existing pcimGroupName attr
    pcimPriority <removed>             - use new pcimGroupPriority attr
    pcimPolicySetList <removed>        - use combination of existing pcimGroupsAuxContainedSet and pcimRulesAuxContainedSet
    pcimDecisionStrategy <retained>
    pcimGroupPriorityAuxClass <added>
    pcimGroupPriority <added>
    pcimDecisionStrategyAuxClass <added>
    pcimGroupRolesAuxClass <added>
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimGroupPriorityAuxClass'
    DESC 'Auxiliary class that represents a level of priority for a particular group.'
    SUP pcimGroup
    AUXILIARY
    MAY { pcimGroupPriority }
   }
 
{ IANA-ASSIGNED-OID.2.x
    NAME 'pcimGroupPriority'
    DESC 'Group priority.'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE
   )
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimDecisionStrategyAuxClass'
    DESC 'Auxiliary class that enables a rule or group to contain decision and execution strategy symantecs.'
    SUP pcimPolicy
    AUXILIARY
    MAY { pcimDecisionStrategy }
   }
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimGroupRolesAuxClass'
    DESC 'Auxiliary class that enables a group to contain role-based information.'
    SUP pcimGroup
    AUXILIARY
    MAY { pcimRoles }
   }
 
5.2 pcimPolicySetAssociation <removed>    - use existing pcimGroupInstance object
    pcimPriority <removed>                - use suggested pcimGroupPriority as above
    pcimPolicySetDN <removed>             - use
5.3 <removed>
5.4 <removed>
5.5 <removed>
5.6 pcimPolicyRule <removed>              - use existing pcimRule object
    pcimPolicyRuleAuxClass <removed>      - use existing pcimRuleAuxClass
    pcimPolicyRuleInstance <removed>      - use existing pcimRuleInstance
    pcimConditionListType <removed>       - use existing pcimRuleConditionListType
    pcimConditionList <removed>           - use existing pcimRuleConditionList
    pcimActionList <removed>              - use existing pcimRuleActionList
    pcimSequencedActions <removed>        - use existing pcimRuleSequencedActions
    pcimExecutionStrategy <retained>
    pcimExecutionStrategyAuxClass <added>
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimExecutionStrategyAuxClass'
    DESC 'Auxiliary class that enables a rule to contain execution strategy information.'
    SUP pcimRule
    AUXILIARY
    MAY { pcimExecutionStrategy }
   }
 
5.7 pcimConditionAssociation <removed>    - use existing pcimRuleConditionAssociation
5.8 pcimActionAssociation <removed>       - use existing pcimRuleActionAssociation
5.9 <removed>
5.10 <removed>
5.11 <removed>
5.12 pcimSimpleConditionAuxClass <retained>
5.13 pcimCompoundConditionAuxClass <retained>
5.14 pcimCompoundFilterConditionAuxClass <retained> although, I'd like some explanation of what this is for...
5.15 pcimSimpleActionAuxClass <retained>
5.16 pcimCompoundActionAuxClass <retained>
5.17 pcimVariable <retained>
5.18 pcimExplicitVariableAuxClass <retained>
5.19 pcimImplicitVariableAuxClass <retained>
5.20 is merged with 5.19 to follow pattern of previous sections containing attributes
     pcim*AuxClass <removed>
5.21 <retained>
5.22 <retained>
5.23 pcimReusableContainer <removed>         - use existing pcimRepository
     pcimReusableContainerAuxClass <removed> - use existing pcimRepositoryAuxClass
     pcimReusableContainerInstance <removed> - use existing pcimRepositoryInstance
     pcimReusableContainerName <removed>     - use existing pcimRepositoryName
     pcimReusableContainerList <removed>     - use new pcimRepositoryList
     pcimRepositoryContainmentAuxClass <added>
     pcimRepositoryList <added>
 
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimRepositoryContainmentAuxClass'
    DESC 'Auxiliary class that enables an object to aggregate reusable repository containers.'
    SUP pcimRepositoryAuxClass
    AUXILIARY
    MAY { pcimRepositoryList }
   }
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimRepositoryList'
    DESC 'blah blah blah...'
    EQUALITY caseIgnoreMatch
    ORDERING caseIgnoreOrderingMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE
   }
 
5.24 <removed>
 
 
Regards,
d.
 
------_=_NextPart_001_01C37E23.B0B23510-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sat Sep 20 10:48:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09325 for ; Sat, 20 Sep 2003 10:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0j1t-0000LE-0l for policy-archive@odin.ietf.org; Sat, 20 Sep 2003 10:48:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KEm8pv001312 for policy-archive@odin.ietf.org; Sat, 20 Sep 2003 10:48:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0j1l-0000KX-BU; Sat, 20 Sep 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ojz-0001V2-Vh for policy@optimus.ietf.org; Fri, 19 Sep 2003 13:08:35 -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 MAA08559 for ; Fri, 19 Sep 2003 12:08:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A04GI-0006TR-00 for policy@ietf.org; Thu, 18 Sep 2003 15:16:18 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A042T-0005HE-00 for policy@ietf.org; Thu, 18 Sep 2003 15:02:01 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 13:01:30 -0600 Message-ID: From: John Strassner To: John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" Subject: RE: [Policy] RE: Trouble with attributes Date: Thu, 18 Sep 2003 13:01:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37E17.43D02D50" 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_01C37E17.43D02D50 Content-Type: text/plain Resending due to mail delivery failure... regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: John Strassner Sent: Thursday, September 18, 2003 11:30 AM To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org' Subject: [Policy] RE: Trouble with attributes Mircea, Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that. Trust me, I know how to write an LDAP filter. :-) But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Thursday, September 18, 2003 10:56 AM To: 'John Strassner'; 'policy@ietf.org' Subject: RE: Trouble with attributes John, I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time. Respectfully, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. :-) John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. Yet Mircea replies: BTW: I am commenting on PCELS -03 published in August 2003. On (1) above: The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error. On (2) above: - LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse. - An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set. Respectfully, Mircea. ------_=_NextPart_001_01C37E17.43D02D50 Content-Type: text/html RE: [Policy] PCLS classes deprecated in PCELS

Resending due to mail delivery failure...

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: John Strassner
Sent: Thursday, September 18, 2003 11:30 AM
To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org'
Subject: [Policy] RE: Trouble with attributes

 

Mircea,

 

Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that.

 

Trust me, I know how to write an LDAP filter. J  But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense?

 

 

regards,
John

 

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    john.strassner@intelliden.com

 

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; 'policy@ietf.org'
Subject: RE: Trouble with attributes

 

John,

 

I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time.

 

Respectfully,

Mircea.

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS

Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.

I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.
</js> 

 

Yet Mircea replies: 

<mircea3>

BTW: I am commenting on PCELS -03 published in August 2003.

On (1) above:

 The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error.

On (2) above:

- LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse.

- An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set.

</mircea3> 

 

Respectfully,

Mircea.

------_=_NextPart_001_01C37E17.43D02D50-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sat Sep 20 11:20:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10951 for ; Sat, 20 Sep 2003 11:20:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jVs-00033S-8d for policy-archive@odin.ietf.org; Sat, 20 Sep 2003 11:19:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KFJ8Pk011715 for policy-archive@odin.ietf.org; Sat, 20 Sep 2003 11:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jVp-0002zx-GL; Sat, 20 Sep 2003 11:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jIx-0000sX-Vv for policy@optimus.ietf.org; Sat, 20 Sep 2003 11:07:24 -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 RAA22732 for ; Fri, 19 Sep 2003 17:39:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0SyA-0001rg-00 for policy@ietf.org; Fri, 19 Sep 2003 17:39:14 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A0Sy0-0001r6-00 for policy@ietf.org; Fri, 19 Sep 2003 17:39:04 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Fri, 19 Sep 2003 16:42:38 -0500 Message-ID: From: "Pana, Mircea" To: "'policy@ietf.org'" Cc: "'John Strassner'" , "'David McTavish'" , "'Joel M. Halpern'" Date: Fri, 19 Sep 2003 16:33:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37EF5.ACFB1810" Subject: [Policy] 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_01C37EF5.ACFB1810 Content-Type: text/plain; charset="iso-8859-1" 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_01C37EF5.ACFB1810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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_01C37EF5.ACFB1810-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Sun Sep 21 06:17:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21919 for ; Sun, 21 Sep 2003 06:17:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A11H7-00061M-GB for policy-archive@odin.ietf.org; Sun, 21 Sep 2003 06:17:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LAH5oS023145 for policy-archive@odin.ietf.org; Sun, 21 Sep 2003 06:17:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A11H2-00060z-K7; Sun, 21 Sep 2003 06:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A11Fq-00060C-I9 for policy@optimus.ietf.org; Sun, 21 Sep 2003 06:16:21 -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 GAA21876 for ; Sun, 21 Sep 2003 06:15:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A11Fh-0000te-00 for policy@ietf.org; Sun, 21 Sep 2003 06:15:37 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A11FX-0000tF-00 for policy@ietf.org; Sun, 21 Sep 2003 06:15:27 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8LAEQu04334 for ; Sun, 21 Sep 2003 05:14:26 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Sun, 21 Sep 2003 12:14:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155023315EE@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'David McTavish'" , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'John Strassner'" , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Sun, 21 Sep 2003 12:14:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38028.84FC8B3A" 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_01C38028.84FC8B3A Content-Type: text/plain; charset="iso-8859-1" W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38028.84FC8B3A Content-Type: text/html; charset="iso-8859-1" PCELS position
W.r.t.
>  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? 
 
PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.
 
Hope this helps.
Bert
------_=_NextPart_001_01C38028.84FC8B3A-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 10:24:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17067 for ; Mon, 22 Sep 2003 10:24:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rbo-0005wz-8N for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:24:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEOCnX022867 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:24:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rbc-0005vz-VM; Mon, 22 Sep 2003 10:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RaN-0005qr-6E for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:23:04 -0400 Received: from mail.sandvine.com (hidden-user@sandvine.com [199.243.201.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16967 for ; Mon, 22 Sep 2003 10:22:33 -0400 (EDT) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 10:21:50 -0400 Message-ID: From: David McTavish To: "'Wijnen, Bert (Bert)'" , David McTavish , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'John Strassner'" , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Mon, 22 Sep 2003 10:21:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38114.DC3A1970" 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_01C38114.DC3A1970 Content-Type: text/plain; charset="iso-8859-1" With this knowledge, is it appropriate to push PCIMe back to the foreground and determine aspects of this document that are not congruent with PCIM? For starters, I believe section 3.1 "How to Change an Information Model" should be re-evaluated, which could make a huge impact on the rest of the document. I'm not against deprecation in principal, however, I don't believe that it should be considered as a primary option. From other models, deprecation is usually reserved as a last resort, and even then, is fazed in over a period of releases to allow for migration. I don't believe that a model that is extending from an existing model should have the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand deprecation being used, but as it stands, I am not sure this is the correct course of action. I'll review PCIMe document further and provide specific arguments for each section that I believe violates the principal of PCIM, and hopefully provide suggestions for discussion. Regards, d. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38114.DC3A1970 Content-Type: text/html; charset="iso-8859-1" PCELS position
With this knowledge, is it appropriate to push PCIMe back to the foreground and determine aspects of this document that are not congruent with PCIM?
For starters, I believe section 3.1 "How to Change an Information Model" should be re-evaluated, which could make a huge impact on the rest of the document.  I'm not against deprecation in principal, however, I don't believe that it should be considered as a primary option. From other models, deprecation is usually reserved as a last resort, and even then, is fazed in over a period of releases to allow for migration.  I don't believe that a model that is extending from an existing model should have the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand deprecation being used, but as it stands, I am not sure this is the correct course of action.
I'll review PCIMe document further and provide specific arguments for each section that I believe violates the principal of PCIM, and hopefully provide suggestions for discussion.
 
 
Regards,
d.
 
 
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.
>  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? 
 
PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.
 
Hope this helps.
Bert
------_=_NextPart_001_01C38114.DC3A1970-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 10:30:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17486 for ; Mon, 22 Sep 2003 10:30:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RhT-0006DZ-DD for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:30:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEU3me023875 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:30:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RhS-0006Cm-HF; Mon, 22 Sep 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rgo-0006BR-N8 for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:29:22 -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 KAA17324 for ; Mon, 22 Sep 2003 10:29:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Rgm-0007dV-00 for policy@ietf.org; Mon, 22 Sep 2003 10:29:20 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A1Rgb-0007dC-00 for policy@ietf.org; Mon, 22 Sep 2003 10:29:09 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8MESVd15208 for ; Mon, 22 Sep 2003 09:28:31 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Mon, 22 Sep 2003 16:28:29 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502331616@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'David McTavish'" , "Wijnen, Bert (Bert)" , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'John Strassner'" , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Mon, 22 Sep 2003 16:27:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38115.859A7276" 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_01C38115.859A7276 Content-Type: text/plain; charset="iso-8859-1" However, let me add that it is probably not OK (but that is the WG chairs who decide) to re-open issues that have been beated to dead in the past and for which there is no new data to consider. I probably should have said that with my earlier email. Thanks, Bert -----Original Message----- From: David McTavish [mailto:dmctavish@sandvine.com] Sent: maandag 22 september 2003 16:22 To: 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position With this knowledge, is it appropriate to push PCIMe back to the foreground and determine aspects of this document that are not congruent with PCIM? For starters, I believe section 3.1 "How to Change an Information Model" should be re-evaluated, which could make a huge impact on the rest of the document. I'm not against deprecation in principal, however, I don't believe that it should be considered as a primary option. From other models, deprecation is usually reserved as a last resort, and even then, is fazed in over a period of releases to allow for migration. I don't believe that a model that is extending from an existing model should have the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand deprecation being used, but as it stands, I am not sure this is the correct course of action. I'll review PCIMe document further and provide specific arguments for each section that I believe violates the principal of PCIM, and hopefully provide suggestions for discussion. Regards, d. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38115.859A7276 Content-Type: text/html; charset="iso-8859-1" PCELS position
However, let me add that it is probably not OK (but that is the WG chairs who
decide) to re-open issues that have been beated to dead in the past and for
which there is no new data to consider.
 
I probably should have said that with my earlier email.
 

Thanks,
Bert

-----Original Message-----
From: David McTavish [mailto:dmctavish@sandvine.com]
Sent: maandag 22 september 2003 16:22
To: 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

With this knowledge, is it appropriate to push PCIMe back to the foreground and determine aspects of this document that are not congruent with PCIM?
For starters, I believe section 3.1 "How to Change an Information Model" should be re-evaluated, which could make a huge impact on the rest of the document.  I'm not against deprecation in principal, however, I don't believe that it should be considered as a primary option. From other models, deprecation is usually reserved as a last resort, and even then, is fazed in over a period of releases to allow for migration.  I don't believe that a model that is extending from an existing model should have the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand deprecation being used, but as it stands, I am not sure this is the correct course of action.
I'll review PCIMe document further and provide specific arguments for each section that I believe violates the principal of PCIM, and hopefully provide suggestions for discussion.
 
 
Regards,
d.
 
 
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.
>  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? 
 
PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.
 
Hope this helps.
Bert
------_=_NextPart_001_01C38115.859A7276-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 10:32:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17781 for ; Mon, 22 Sep 2003 10:32:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RjO-0006Tn-Jp for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEW2jp024863 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RjO-0006Sv-Aa; Mon, 22 Sep 2003 10:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rip-0006Pr-Ni for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:31:27 -0400 Received: from srvmaddog.metasolv.com (mail.metasolv.com [12.105.131.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17643 for ; Mon, 22 Sep 2003 10:31:17 -0400 (EDT) Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Sep 2003 09:30:03 -0500 Message-ID: From: "Pana, Mircea" To: "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "Pana, Mircea" , "'policy@ietf.org'" Cc: "'John Strassner'" , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Mon, 22 Sep 2003 09:20:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38114.B848BE90" 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_01C38114.B848BE90 Content-Type: text/plain; charset="iso-8859-1" Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38114.B848BE90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] RE: PCELS position

Maybe there is no need for such drastic measures. = Maybe it is only a matter of interpretation of the PCIMe = recommendations. After all PCIMe is quite lenient wrt. that is and what = is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make = it difficult for PCELS to be interoperable with PCLS. These are as = follows:

1. PCIMe defines a new abstract class, PolicySet, and = makes it a superclass of the already defined PolicyRule and = PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been = deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the = new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to = interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping = of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping = of the modified PolicyGroup. Implementations can use (the equivalent = of) a PolicyRule with no Actions or Conditions for PolicyGroup = objects.

C. implementations SHOULD (as opposed to MUST) use = the relative priority mechanism instead of the absolute priority = attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but = it is acceptable for instances of this class to occur through = inheritance.

So, the question is whether the statements A. through = D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; = 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position


W.r.t.
>  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? =

PCIMe is at Proposed Standard. If, for example = because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should = not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then = recycle at Proposed Standard.
That is part of the normal standars track process. = That is, we get something to PS, then we start
using/implementing (the "using" part is = reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec = work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major = issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C38114.B848BE90-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 10:33:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17878 for ; Mon, 22 Sep 2003 10:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RkL-0006gL-KJ for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:33:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEX1Mr025648 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RkL-0006fa-AD; Mon, 22 Sep 2003 10:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RkF-0006eM-Iq for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:32:55 -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 KAA17809 for ; Mon, 22 Sep 2003 10:32:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1RkD-0007ew-00 for policy@ietf.org; Mon, 22 Sep 2003 10:32:53 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1A1Rjs-0007eJ-00 for policy@ietf.org; Mon, 22 Sep 2003 10:32:32 -0400 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5490520; Mon, 22 Sep 2003 10:30:49 -0400 Message-Id: <5.1.0.14.0.20030922102554.021f2d90@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Sep 2003 10:30:30 -0400 To: David McTavish , "'Wijnen, Bert (Bert)'" , "'Pana, Mircea'" , "'policy@ietf.org'" From: "Joel M. Halpern" Subject: RE: [Policy] RE: PCELS position Cc: "'John Strassner'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , We need to be very clear about the separation of issues. We are having a useful discussion about how to best represent PCIMe in LDAP. There are a number of properties of LDAP that affect this representation. At the same time it should be understood by all participants that the working group made an explicit decision to make some incompatible model changes in crafting PCIMe. While not everyone agreed with either the problems that prompted this decision or the decision itself, it did represent the rough consensus of the working group. LDAP issues are not a primary driver for model structure. Hence, I would not tend to consider LDAP issues to be a driver for reopening the discussion about changing the core model. If there are model level issues that were not known or discussed at the time the decision was made, we can look into re-opening the discussion. However, if we do this I will need to attempt to bring back into the discussion the other interested parties who brought forward concerns at the time (for example IPSP.) Yours, Joel M. Halpern, speaking as co-chair. At 10:21 AM 9/22/2003 -0400, David McTavish wrote: >With this knowledge, is it appropriate to push PCIMe back to the >foreground and determine aspects of this document that are not congruent >with PCIM? >For starters, I believe section 3.1 "How to Change an Information Model" >should be re-evaluated, which could make a huge impact on the rest of the >document. I'm not against deprecation in principal, however, I don't >believe that it should be considered as a primary option. From other >models, deprecation is usually reserved as a last resort, and even then, >is fazed in over a period of releases to allow for migration. I don't >believe that a model that is extending from an existing model should have >the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would >better understand deprecation being used, but as it stands, I am not sure >this is the correct course of action. >I'll review PCIMe document further and provide specific arguments for each >section that I believe violates the principal of PCIM, and hopefully >provide suggestions for discussion. > > >Regards, >d. > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Sunday, September 21, 2003 6:14 AM >To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' >Cc: 'John Strassner'; 'Joel M. Halpern' >Subject: RE: [Policy] RE: PCELS position > >W.r.t. > > 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? > >PCIMe is at Proposed Standard. If, for example because of this effort to >try and MAP it onto LDAP, we >find that we did some things in PCIMe that we should not have done, then, >with WG consensus, >we can make incompatible changes to PCIMe and then recycle at Proposed >Standard. >That is part of the normal standars track process. That is, we get >something to PS, then we start >using/implementing (the "using" part is reusing PCIMe definitions in otehr >CIM docs (like the >other docs we did in Policy, and like the IPsec work, the "implementing" >is sort of mapping onto for >example LDAP I think)... and if we find major issues, then we fix and >recycle at PS. If we do not >find major issues, we may advance to DS. > >Hope this helps. >Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 11:00:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19065 for ; Mon, 22 Sep 2003 11:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SAV-0008GQ-Jk for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 11:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MF03Xk031719 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 11:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SAU-0008FT-C5; Mon, 22 Sep 2003 11:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9X-000894-SC for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:59:03 -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 KAA18951 for ; Mon, 22 Sep 2003 10:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1S9Q-00007a-00 for policy@ietf.org; Mon, 22 Sep 2003 10:58:56 -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 1A1S9F-00007O-00 for policy@ietf.org; Mon, 22 Sep 2003 10:58:45 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 10:58:17 -0400 Message-ID: From: David McTavish To: "'Joel M. Halpern'" , David McTavish , "'Wijnen, Bert (Bert)'" , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'John Strassner'" Subject: RE: [Policy] RE: PCELS position Date: Mon, 22 Sep 2003 10:58:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , "LDAP issues are not a primary driver for model structure. Hence, I would not tend to consider LDAP issues to be a driver for reopening the discussion about changing the core model." --- I agree, and that is the root of my issue. I no longer believe that the LDAP issues are driving this, but are in fact a side-effect of the existing proposal. In my opinion, the implementation details are possibly unearthing an underlying flaw in the original PCIMe proposal. "If there are model level issues that were not known or discussed at the time the decision was made, we can look into re-opening the discussion. However, if we do this I will need to attempt to bring back into the discussion the other interested parties who brought forward concerns at the time (for example IPSP.)" --- Is this a viable course of action? I believe that the issue should be reconsidered, if possible. I will search through the WG archives to understand the process and consideration extended to address these issues. I do not wish to disjoint the effort and thought already invested into the proposal, but at the same time, I do wish that further discussion and pursual of alternatives can be supported to achieve the best outcome. My primary concern is that there are viable alternatives within PCIMe that could address all of its concerns, without the need to deprecate the existing model, that may have not been pursued. For example, the deprecation of the PcimRepository and all of its sub-classes may possibly have been averted. Referring to section 3.2.1 entitled "Changes to PolicyRepository", I understand that there MAY be confusion about the use of the term "Repository", however, the first course of action, IMO, would not be to deprecate schema to address this problem. I believe that this is solely a documentation issue, that can be directly addressed through an update to the documentation by providing a concise explanation of the use of repository objects and their interactions. I find that deprecating an entire model to rename "Repository" to "ReusableContainer" is addressing the problem from a more extreme vantage point than is entirely necessary. This is only my initial analysis for PCIMe, and it seems evident to me that further investigation may be warranted, if it is conceivable that such drastic measures can be avoided with fresh thinking. Regards, d. -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, September 22, 2003 10:31 AM To: David McTavish; 'Wijnen, Bert (Bert)'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner' Subject: RE: [Policy] RE: PCELS position We need to be very clear about the separation of issues. We are having a useful discussion about how to best represent PCIMe in LDAP. There are a number of properties of LDAP that affect this representation. At the same time it should be understood by all participants that the working group made an explicit decision to make some incompatible model changes in crafting PCIMe. While not everyone agreed with either the problems that prompted this decision or the decision itself, it did represent the rough consensus of the working group. LDAP issues are not a primary driver for model structure. Hence, I would not tend to consider LDAP issues to be a driver for reopening the discussion about changing the core model. If there are model level issues that were not known or discussed at the time the decision was made, we can look into re-opening the discussion. However, if we do this I will need to attempt to bring back into the discussion the other interested parties who brought forward concerns at the time (for example IPSP.) Yours, Joel M. Halpern, speaking as co-chair. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 13:21:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26223 for ; Mon, 22 Sep 2003 13:21:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1UN0-00056H-Hu for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 13:21:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MHL6TH019601 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 13:21:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1UMv-00055O-Mq; Mon, 22 Sep 2003 13:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1UM3-0004uI-H0 for policy@optimus.ietf.org; Mon, 22 Sep 2003 13:20:12 -0400 Received: from srvmaddog.metasolv.com (mail.metasolv.com [12.105.131.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26161 for ; Mon, 22 Sep 2003 13:19:54 -0400 (EDT) Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Mon, 22 Sep 2003 12:18:40 -0500 Message-ID: From: "Pana, Mircea" To: John Strassner , "'policy@ietf.org'" Date: Mon, 22 Sep 2003 12:09:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3812C.450D4EB0" Subject: [Policy] RE: Trouble with attributes 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_01C3812C.450D4EB0 Content-Type: text/plain; charset="iso-8859-1" John, There are many design techniques that lead to attribute "mixtures" within a same entry and the possilities for something to go wrong are countless. I don't see why attribute re-use would be evil ;-) while subclasses or aux. class attachment would not. We just need to design our applications in the idea that a shared repository is always a source of surprises. Regards, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Thursday, September 18, 2003 1:30 PM To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org' Subject: RE: Trouble with attributes Mircea, Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that. Trust me, I know how to write an LDAP filter. J But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Thursday, September 18, 2003 10:56 AM To: 'John Strassner'; 'policy@ietf.org' Subject: RE: Trouble with attributes John, I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time. Respectfully, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. Yet Mircea replies: BTW: I am commenting on PCELS -03 published in August 2003. On (1) above: The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error. On (2) above: - LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse. - An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set. Respectfully, Mircea. ------_=_NextPart_001_01C3812C.450D4EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Trouble with attributes

John,

There are many design techniques that lead to = attribute "mixtures" within a same entry and the possilities = for something to go wrong are countless. I don't see why attribute = re-use would be evil ;-) while subclasses or aux. class attachment = would not. We just need to design our applications in the idea that a = shared repository is always a source of surprises.

Regards,
Mircea.

 -----Original Message-----
From: John Strassner [mailto:John.Strassner@inte= lliden.com]
Sent: Thursday, September 18, 2003 1:30 PM
To: 'Pana, Mircea'; John Strassner; = 'policy@ietf.org'
Subject: RE: Trouble with attributes


Mircea,

Perhaps I should have been clearer. I agree, there's = nothing in LDAP or X.500 that prevents you doing what you've done. My = point was that in my opinion, it is a poor design to do = that.

Trust me, I know how to write an LDAP filter. J  = But you're putting all of the burden on the client in your approach. = Furthermore, how are you going to write your schema? PCELS is, in my = opinion, not an extension but rather a redesign. This is fine, but in = this case I would have expected to see a stand-alone schema for PCELS. = Does that make sense?


regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     = +1.719.785.0644
email:    = john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com] =
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; 'policy@ietf.org'
Subject: RE: Trouble with attributes

John,

I feel obliged to respond to this message since I = have a very different opinion. Feel free to ignore it if you consider = this a waste of your time.

Respectfully,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@inte= lliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. = Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David = McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] = PCLS classes deprecat ed in PCELS
Since it is now one point, I'm bringing that up = immediately below this sentence so people can find it. J
John originally wrote:
With respect to your first point, PCELS does NOT = already do this everywhere - for example, there are cases where you've = changed the name of the PCLS class but kept the names of its = attributes. That's very bad and will result in some NASTY errors. =

Mircea replied:
<mircea>
Can you please give an example from the current = PCELS? I don't understand what you mean by "changed the name of = the PCLS class". Except for pcimGroup* and the PCLS classes marked = as deprecated (that will be changed as noted) there are concepts that = have been redefined (i.e. new classes introduced by PCELS with new = OIDs). Some use attributes defined by PCLS. Do you see anything wrong = with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional = attributes. PCELS defines pcimPolicyRule with a set of 10 optional = attributes. Of these, five of the PCELS attributes have the same name = as the corresponding PCLS attributes, yet you have deprecated pcimRule. = How is that possible?

</js>
Mircea replied back:
<mircea2>The five attributes with the same = name are the ones defined by PCLS. They are NOT redefined by PCELS, = they are reused in their original form and with their original = semantics. PCELS provides replacement for the pcimRule class and 5 of = its 11 attributes. (The currently published revision of PCELS = explicitly deprecates the class and five of its 11 attributes and the = next revision will replace that with a note explicitly listing the = replaced items, as discussed). Of the remaining 6 attributes of = pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by = pcimPolicySet.</mircea2>

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply = reference the PCLS definition, not repeat it, and (2) you have the same = attribute defined by two different object classes. Servers that have = already implemented PCLS will find this a conflict, and react in = strange and wonderful ways. For example, if you search for one of the = original 5 PCLS attributes, you will get hits from the PCLS class = (which you deprecated) and the PCELS class. Servers don't understand = deprecation. Worse, if you don't scope your search correctly, and = deleted old instances of the PCLS class, you'll still get hits but they = won't be able to trace what the object class was since it was = deleted.

I strongly recommend that you do NOT do this. If you = make a new object class, make a new attribute. And add text in the = descriptions that say that something was deprecated for something = else.

</js>

Yet Mircea replies:
<mircea3>
BTW: I am commenting on PCELS -03 published in = August 2003.
On (1) above:
 The attributes/classes defined in PCLS and = used in PCELS are referenced, NOT repeated. See for example: "Its = attributes are defined in the section 5.4 of the [PCLS]." on page = 27 of PCELS. I admit that there might be places where PCELS fails to = make explicit references but any repetition of PCLS definitions in = PCELS is unintentional and should be considered an editorial = error.

On (2) above:
- LDAP attributes are not defined by classes. LDAP = Attributes are used by classes and they can be used by any number of = classes. LDAP attributes defined by standard schemas may be (and are) = reused by a number of standard LDAP classes ('cn' would the trivial = example). I am not aware of any restriction imposed by the LDAP or = X.500 standards at this level. On the contrary, I think that the intent = was to encourage attribute reuse.

- An application that searches for entries with a = specific attribute and expects to be able to make sense of all the = entries returned in the search results is a poorly designed application.= At the minimum, this application should check for the appropriate = objectclass either by including it in the search filter or by filtering = out non-matching entries from the result set.

</mircea3>

Respectfully,
Mircea.

------_=_NextPart_001_01C3812C.450D4EB0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 13:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27447 for ; Mon, 22 Sep 2003 13:52:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Uqy-0008Sy-9U for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 13:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MHq4gb032529 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 13:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Uqu-0008Ry-Qe; Mon, 22 Sep 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Uqh-0008Qk-25 for policy@optimus.ietf.org; Mon, 22 Sep 2003 13:51:57 -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 NAA27410 for ; Mon, 22 Sep 2003 13:51:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1UqZ-0001ZN-00 for policy@ietf.org; Mon, 22 Sep 2003 13:51:39 -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 1A1UqP-0001Ag-00 for policy@ietf.org; Mon, 22 Sep 2003 13:51:29 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 13:46:14 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , John Strassner , "'policy@ietf.org'" Subject: RE: [Policy] RE: Trouble with attributes Date: Mon, 22 Sep 2003 13:46:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38131.6AA366A0" 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_01C38131.6AA366A0 Content-Type: text/plain; charset="iso-8859-1" I agree with Mircea in this regard. I have no problem with a particular LDAP class having multiple auxiliary classes which may have overlapping attributes. Searching LDAP should focus on matching the desired objectClass instead of on an attribute level. The only problem I could foresee is if each auxiliary class inferred a different meaning into the values specified in the overlapping attribute, but seeming that the description for the attribute is embedded directly to the attribute, this should not be the case. d. -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 1:09 PM To: John Strassner; 'policy@ietf.org' Subject: [Policy] RE: Trouble with attributes John, There are many design techniques that lead to attribute "mixtures" within a same entry and the possilities for something to go wrong are countless. I don't see why attribute re-use would be evil ;-) while subclasses or aux. class attachment would not. We just need to design our applications in the idea that a shared repository is always a source of surprises. Regards, Mircea. -----Original Message----- From: John Strassner [ mailto:John.Strassner@intelliden.com ] Sent: Thursday, September 18, 2003 1:30 PM To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org' Subject: RE: Trouble with attributes Mircea, Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that. Trust me, I know how to write an LDAP filter. J But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense? regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.791.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Pana, Mircea [ mailto:mpana@metasolv.com ] Sent: Thursday, September 18, 2003 10:56 AM To: 'John Strassner'; 'policy@ietf.org' Subject: RE: Trouble with attributes John, I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time. Respectfully, Mircea. -----Original Message----- From: John Strassner [ mailto:John.Strassner@intelliden.com ] Sent: Wednesday, September 17, 2003 1:43 PM To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org' Cc: 'rmoats@lemurnetworks.net'; 'David McTavish' Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J John originally wrote: With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors. Mircea replied: Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that? John replied back: PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible? Mircea replied back: The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet. John's hopefully final reply: This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted. I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else. Yet Mircea replies: BTW: I am commenting on PCELS -03 published in August 2003. On (1) above: The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error. On (2) above: - LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse. - An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set. Respectfully, Mircea. ------_=_NextPart_001_01C38131.6AA366A0 Content-Type: text/html; charset="iso-8859-1" RE: Trouble with attributes
I agree with Mircea in this regard. I have no problem with a particular LDAP class having multiple auxiliary classes which may have overlapping attributes. Searching LDAP should focus on matching the desired objectClass instead of on an attribute level. The only problem I could foresee is if each auxiliary class inferred a different meaning into the values specified in the overlapping attribute, but seeming that the description for the attribute is embedded directly to the attribute, this should not be the case.
 
d.
 
 
 
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 1:09 PM
To: John Strassner; 'policy@ietf.org'
Subject: [Policy] RE: Trouble with attributes

John,

There are many design techniques that lead to attribute "mixtures" within a same entry and the possilities for something to go wrong are countless. I don't see why attribute re-use would be evil ;-) while subclasses or aux. class attachment would not. We just need to design our applications in the idea that a shared repository is always a source of surprises.

Regards,
Mircea.

 -----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Thursday, September 18, 2003 1:30 PM
To: 'Pana, Mircea'; John Strassner; 'policy@ietf.org'
Subject: RE: Trouble with attributes


Mircea,

Perhaps I should have been clearer. I agree, there's nothing in LDAP or X.500 that prevents you doing what you've done. My point was that in my opinion, it is a poor design to do that.

Trust me, I know how to write an LDAP filter. J  But you're putting all of the burden on the client in your approach. Furthermore, how are you going to write your schema? PCELS is, in my opinion, not an extension but rather a redesign. This is fine, but in this case I would have expected to see a stand-alone schema for PCELS. Does that make sense?


regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  +1.791.785.0648
  fax:     +1.719.785.0644
email:    john.strassner@intelliden.com

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; 'policy@ietf.org'
Subject: RE: Trouble with attributes

John,

I feel obliged to respond to this message since I have a very different opinion. Feel free to ignore it if you consider this a waste of your time.

Respectfully,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; 'policy@ietf.org'
Cc: 'rmoats@lemurnetworks.net'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS
Since it is now one point, I'm bringing that up immediately below this sentence so people can find it. J
John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere - for example, there are cases where you've changed the name of the PCLS class but kept the names of its attributes. That's very bad and will result in some NASTY errors.

Mircea replied:
<mircea>
Can you please give an example from the current PCELS? I don't understand what you mean by "changed the name of the PCLS class". Except for pcimGroup* and the PCLS classes marked as deprecated (that will be changed as noted) there are concepts that have been redefined (i.e. new classes introduced by PCELS with new OIDs). Some use attributes defined by PCLS. Do you see anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines pcimPolicyRule with a set of 10 optional attributes. Of these, five of the PCELS attributes have the same name as the corresponding PCLS attributes, yet you have deprecated pcimRule. How is that possible?

</js>
Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by PCLS. They are NOT redefined by PCELS, they are reused in their original form and with their original semantics. PCELS provides replacement for the pcimRule class and 5 of its 11 attributes. (The currently published revision of PCELS explicitly deprecates the class and five of its 11 attributes and the next revision will replace that with a note explicitly listing the replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2>

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS definition, not repeat it, and (2) you have the same attribute defined by two different object classes. Servers that have already implemented PCLS will find this a conflict, and react in strange and wonderful ways. For example, if you search for one of the original 5 PCLS attributes, you will get hits from the PCLS class (which you deprecated) and the PCELS class. Servers don't understand deprecation. Worse, if you don't scope your search correctly, and deleted old instances of the PCLS class, you'll still get hits but they won't be able to trace what the object class was since it was deleted.

I strongly recommend that you do NOT do this. If you make a new object class, make a new attribute. And add text in the descriptions that say that something was deprecated for something else.

</js>

Yet Mircea replies:
<mircea3>
BTW: I am commenting on PCELS -03 published in August 2003.
On (1) above:
 The attributes/classes defined in PCLS and used in PCELS are referenced, NOT repeated. See for example: "Its attributes are defined in the section 5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places where PCELS fails to make explicit references but any repetition of PCLS definitions in PCELS is unintentional and should be considered an editorial error.

On (2) above:
- LDAP attributes are not defined by classes. LDAP Attributes are used by classes and they can be used by any number of classes. LDAP attributes defined by standard schemas may be (and are) reused by a number of standard LDAP classes ('cn' would the trivial example). I am not aware of any restriction imposed by the LDAP or X.500 standards at this level. On the contrary, I think that the intent was to encourage attribute reuse.

- An application that searches for entries with a specific attribute and expects to be able to make sense of all the entries returned in the search results is a poorly designed application. At the minimum, this application should check for the appropriate objectclass either by including it in the search filter or by filtering out non-matching entries from the result set.

</mircea3>

Respectfully,
Mircea.

------_=_NextPart_001_01C38131.6AA366A0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Mon Sep 22 14:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28846 for ; Mon, 22 Sep 2003 14:26:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VNu-0003sA-9E for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 14:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MIQ6T7014879 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 14:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VNp-0003rL-3e; Mon, 22 Sep 2003 14:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VMy-0003mI-PR for policy@optimus.ietf.org; Mon, 22 Sep 2003 14:25:34 -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 OAA28797 for ; Mon, 22 Sep 2003 14:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1VMw-0004B6-00 for policy@ietf.org; Mon, 22 Sep 2003 14:25:06 -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 1A1VMl-0004Ah-00 for policy@ietf.org; Mon, 22 Sep 2003 14:24:55 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 14:24:50 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , "'Wijnen, Bert (Bert)'" , David McTavish , "'policy@ietf.org'" Cc: "'John Strassner'" , "'Joel M. Halpern'" Date: Mon, 22 Sep 2003 14:24:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38136.CEC12F50" Subject: [Policy] Mircea's suggestions 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_01C38136.CEC12F50 Content-Type: text/plain; charset="iso-8859-1" Some good suggestions here Mircea, but I believe that they will also inevitably require modifications to the underlying PCIMe document. Hopefully, we can pursue these options to find some common ground. A.B. From first glance, I'm not sure about A or B, but if this could be implemented through "inferrence", then I'm all for it. However, reviewing PCIMe, it seems that the document intends to dictate the underlying implementation strategy via the class inheritence diagram. If the relationship between Rules/Groups and PolicySets can be abstracted out in PCELS, then I believe this would remove the necessity to deprecate pcimRule and pcimGroup objects. However, I am not sure if this was the intent of the document, and will leave for others to discuss, as obviously, I'm somewhat biased. :) C. My opinion, from PCIMe is that C violates in its current form. In particular, I'd be concerned with the following quotations from PCIMe: Section 3.2.3: "Drawing from both QPIM and ICPM, the Priority property has been deprecated in PolicyRule, and placed instead on the aggregation PolicySetComponent. ... With the removal of the Priority property from PolicyRule, a new modeling dependency is introduced." I believe if this was rephrased such that the last sentence permitted the existence of the Priority property within the PolicyRule object instead of calling for its outright removal, then the proposal would preserve room for backwards compatibility. Section 5.5 "PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet" This means that Priority MUST have a unique value for all rules/groups, which means existing PCIM implementations would be non-compliant. In order for this to be backwards compatible, it needs to be relaxed to allow for a default of zero (or non-existence), and process accordingly. I believe that PCIMe needs to be reworked in this capacity to have more leniency. D. I'm not quite sure which direction you were inferring for the inheritence... are you inferring that a ReusableContainer object would extend from the current Repository object class? This could be a more practical approach, but I still get the feeling that we are just patching an object to change the name, and the existing problem is maintained because the object dependency must be fully qualified within LDAP. (ie: a ReusableContainer object in ldap would have the following objectclasses defined {top, pcimPolicy, pcimRepository, pcimReusableContainer, pcimReusableContainerInstance}). Regards, d. -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 10:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38136.CEC12F50 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] RE: PCELS position
Some good suggestions here Mircea, but I believe that they will also inevitably require modifications to the underlying PCIMe document. Hopefully, we can pursue these options to find some common ground.
 
A.B. From first glance, I'm not sure about A or B, but if this could be implemented through "inferrence", then I'm all for it. However, reviewing PCIMe, it seems that the document intends to dictate the underlying implementation strategy via the class inheritence diagram. If the relationship between Rules/Groups and PolicySets can be abstracted out in PCELS, then I believe this would remove the necessity to deprecate pcimRule and pcimGroup objects. However, I am not sure if this was the intent of the document, and will leave for others to discuss, as obviously, I'm somewhat biased. :)
 
C. My opinion, from PCIMe is that C violates in its current form. In particular, I'd be concerned with the following quotations from PCIMe:
Section 3.2.3:
"Drawing from both QPIM and ICPM, the Priority property has been
   deprecated in PolicyRule, and placed instead on the aggregation
   PolicySetComponent.  ...  With the removal of the Priority property from
   PolicyRule, a new modeling dependency is introduced."
I believe if this was rephrased such that the last sentence permitted the existence of the Priority property within the PolicyRule object instead of calling for its outright removal, then the proposal would preserve room for backwards compatibility.
Section 5.5
"PolicySetComponent.Priority MUST have a unique value when compared with others defined for the same aggregating PolicySet"
This means that Priority MUST have a unique value for all rules/groups, which means existing PCIM implementations would be non-compliant. In order for this to be backwards compatible, it needs to be relaxed to allow for a default of zero (or non-existence), and process accordingly. I believe that PCIMe needs to be reworked in this capacity to have more leniency.
 
D. I'm not quite sure which direction you were inferring for the inheritence... are you inferring that a ReusableContainer object would extend from the current Repository object class?  This could be a more practical approach, but I still get the feeling that we are just patching an object to change the name, and the existing problem is maintained because the object dependency must be fully qualified within LDAP. (ie: a ReusableContainer object in ldap would have the following objectclasses defined {top, pcimPolicy, pcimRepository, pcimReusableContainer, pcimReusableContainerInstance}).
 
Regards,
d.
 
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 10:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position


W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C38136.CEC12F50-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 12:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23637 for ; Tue, 23 Sep 2003 12:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qGk-0006gy-Qj for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 12:44:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NGi6jR025720 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 12:44:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qGe-0006gJ-BC; Tue, 23 Sep 2003 12:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qGc-0006fz-R7 for policy@optimus.ietf.org; Tue, 23 Sep 2003 12:43:59 -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 MAA23594 for ; Tue, 23 Sep 2003 12:43:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qGb-0002ty-00 for policy@ietf.org; Tue, 23 Sep 2003 12:43:57 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1qGa-0002sz-00 for policy@ietf.org; Tue, 23 Sep 2003 12:43:56 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 10:43:19 -0600 Message-ID: From: John Strassner To: "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: John Strassner , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 10:43:19 -0600 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C381F1.CB654920" 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_01C381F1.CB654920 Content-Type: text/plain I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models. 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 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 4:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C381F1.CB654920 Content-Type: text/html PCELS position

I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models.

 

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

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.

>  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? 

 

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we

find that we did some things in PCIMe that we should not have done, then, with WG consensus,

we can make incompatible changes to PCIMe and then recycle at Proposed Standard.

That is part of the normal standars track process. That is, we get something to PS, then we start

using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the

other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for

example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not

find major issues, we may advance to DS.

 

Hope this helps.

Bert

------_=_NextPart_001_01C381F1.CB654920-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 13:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24520 for ; Tue, 23 Sep 2003 13:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qa1-0007Zd-Mr for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:04:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NH41QL029112 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qa1-0007Ys-2q; Tue, 23 Sep 2003 13:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qZu-0007YE-22 for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:03:54 -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 NAA24486 for ; Tue, 23 Sep 2003 13:03:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qZs-0003Bf-00 for policy@ietf.org; Tue, 23 Sep 2003 13:03:52 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1qZr-0003BN-00 for policy@ietf.org; Tue, 23 Sep 2003 13:03:51 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 11:03:21 -0600 Message-ID: From: John Strassner To: "'Pana, Mircea'" , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: John Strassner , "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 11:03:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C381F4.94D7A670" 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_01C381F4.94D7A670 Content-Type: text/plain Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C381F4.94D7A670 Content-Type: text/html RE: [Policy] RE: PCELS position

Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.

 

Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.

 

So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier.

 

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C381F4.94D7A670-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 13:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26155 for ; Tue, 23 Sep 2003 13:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qxM-0001ec-GO for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHS5Mq006276 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qxI-0001cz-BZ; Tue, 23 Sep 2003 13:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qx6-0001cH-JQ for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:27:52 -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 NAA26092 for ; Tue, 23 Sep 2003 13:27:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qx4-0003iL-00 for policy@ietf.org; Tue, 23 Sep 2003 13:27:50 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1A1qx3-0003hK-00 for policy@ietf.org; Tue, 23 Sep 2003 13:27:49 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8NHQpxw184284; Tue, 23 Sep 2003 13:26:51 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8NHQWaE203656; Tue, 23 Sep 2003 11:26:33 -0600 In-Reply-To: Subject: RE: [Policy] RE: PCELS position To: John Strassner Cc: "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'Joel M. Halpern'" , John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Robert Moore Date: Tue, 23 Sep 2003 13:26:23 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/23/2003 11:26:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , >Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class >bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different >attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. John, I'll have to say that I'm missing the essence of your argument here. Formally (as you've acknowledged), LDAP falls into the same category as X.500 and CMIP: attributes are defined, and maintain their identity, independent of the classes in which they appear. (Digression for those who haven't worked in the DMTF: CIM works the opposite way -- an attribute's identity is tied to the class in which it is defined, so that it's possible to have two attributes with identical names defined in two different CIM classes. This is, of course, a potential source of confusion, so there were DMTF guidelines saying "Don't do this." But these provided an artificial overlay of global scope on attributes whose identity was inherently scoped by the classes that defined them.) I don't have specific experience with X.500 and LDAP, but I do know that in the CMIP case it was perfectly good practice (in fact, it was typical) to define attributes without regard to the classes that would include them. I'm don't see why X.500 and LDAP should be any different. But your use of the wording "... the original class baz that defined foo" suggests that you see some non-formal, but nevertheless significant sense in which LDAP attributes *are* defined relative to the (first?) class that contains them. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com John Strassner , "'Wijnen, Bert (Bert)'" lliden.com> , "'David McTavish'" , "'policy@ietf.org'" Sent by: policy-admin@ietf.or cc: John Strassner , "'Joel M. Halpern'" g Subject: RE: [Policy] RE: PCELS position 09/23/2003 01:03 PM Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 13:42:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26895 for ; Tue, 23 Sep 2003 13:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rAo-0002QE-T7 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHg2Nr009306 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rAn-0002Pn-SK; Tue, 23 Sep 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rA0-0002Od-NZ for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:41:12 -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 NAA26818 for ; Tue, 23 Sep 2003 13:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1r9y-0003wJ-00 for policy@ietf.org; Tue, 23 Sep 2003 13:41:10 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1A1r9x-0003vB-00 for policy@ietf.org; Tue, 23 Sep 2003 13:41:09 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h8NHeFPK363856; Tue, 23 Sep 2003 13:40:15 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h8NHeB9f168988; Tue, 23 Sep 2003 11:40:11 -0600 In-Reply-To: Subject: RE: [Policy] RE: PCELS position To: David McTavish Cc: "'Wijnen, Bert (Bert)'" , David McTavish , "'Joel M. Halpern'" , John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Robert Moore Date: Tue, 23 Sep 2003 13:40:07 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/23/2003 11:40:11 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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: , David, Yes, that's exactly what I was saying. What I don't understand is this: if LDAP attributes are globally unique, what's the problem with reusing them in multiple classes (with the same syntax and semantics, of course)? This was a desirable thing in CMIP, but John is suggesting that it's to be avoided in LDAP. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com David McTavish cc: "'Wijnen, Bert (Bert)'" , David McTavish 09/23/2003 01:33 , "'Joel M. Halpern'" , John Strassner PM , "'Pana, Mircea'" , "'policy@ietf.org'" , policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position Hi Bob, Unfortunately, in LDAP, attributes must be globally unique. So, if an attribute is defined as "foo" in one objectclass as a boolean, and as an integer in another class, this causes an incompatibility. In some cases (OpenLDAP), this prevents the server from even starting. It's not the most elegant implementation, but something you get used to when working on LDAP. Hope this is informational, d. -----Original Message----- From: Robert Moore [mailto:remoore@us.ibm.com] Sent: Tuesday, September 23, 2003 1:26 PM To: John Strassner Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position >Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class >bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different >attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. John, I'll have to say that I'm missing the essence of your argument here. Formally (as you've acknowledged), LDAP falls into the same category as X.500 and CMIP: attributes are defined, and maintain their identity, independent of the classes in which they appear. (Digression for those who haven't worked in the DMTF: CIM works the opposite way -- an attribute's identity is tied to the class in which it is defined, so that it's possible to have two attributes with identical names defined in two different CIM classes. This is, of course, a potential source of confusion, so there were DMTF guidelines saying "Don't do this." But these provided an artificial overlay of global scope on attributes whose identity was inherently scoped by the classes that defined them.) I don't have specific experience with X.500 and LDAP, but I do know that in the CMIP case it was perfectly good practice (in fact, it was typical) to define attributes without regard to the classes that would include them. I'm don't see why X.500 and LDAP should be any different. But your use of the wording "... the original class baz that defined foo" suggests that you see some non-formal, but nevertheless significant sense in which LDAP attributes *are* defined relative to the (first?) class that contains them. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com John Strassner , "'Wijnen, Bert (Bert)'" lliden.com> , "'David McTavish'" , "'policy@ietf.org'" Sent by: policy-admin@ietf.or cc: John Strassner , "'Joel M. Halpern'" g Subject: RE: [Policy] RE: PCELS position 09/23/2003 01:03 PM Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 13:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27625 for ; Tue, 23 Sep 2003 13:57:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rPN-0003Cb-NI for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:57:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHv558012286 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rPI-0003BT-Ku; Tue, 23 Sep 2003 13:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rOt-0003B0-Ez for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:56:35 -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 NAA27582 for ; Tue, 23 Sep 2003 13:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rOr-0004AQ-00 for policy@ietf.org; Tue, 23 Sep 2003 13:56:33 -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 1A1rOo-0004AM-00 for policy@ietf.org; Tue, 23 Sep 2003 13:56:30 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:56:29 -0400 Message-ID: From: David McTavish To: "'John Strassner'" , "'Wijnen, Bert (Bert)'" , David McTavish , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:56:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C381FC.02D4AD60" 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_01C381FC.02D4AD60 Content-Type: text/plain; charset="iso-8859-1" John, I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced. My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM. My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it. My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction. By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters. The core key issues that limit compatibility between PCIM and PCIMe are as follows: - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM. If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM. Regards, d. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 12:43 PM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Importance: High I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models. 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 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 4:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C381FC.02D4AD60 Content-Type: text/html; charset="iso-8859-1" PCELS position
John,
 
I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced.  My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM.  My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it.  My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction.  By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters.
 
The core key issues that limit compatibility between PCIM and PCIMe are as follows:
 - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults
 - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment
 - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility
 
You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM.
 
If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM.
 
Regards,
d.
 
 
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position
Importance: High

I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models.

 

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

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.

>  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? 

 

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we

find that we did some things in PCIMe that we should not have done, then, with WG consensus,

we can make incompatible changes to PCIMe and then recycle at Proposed Standard.

That is part of the normal standars track process. That is, we get something to PS, then we start

using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the

other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for

example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not

find major issues, we may advance to DS.

 

Hope this helps.

Bert

------_=_NextPart_001_01C381FC.02D4AD60-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 15:05:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00979 for ; Tue, 23 Sep 2003 15:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1sTB-000782-0V for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:05:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NJ54XV027402 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1sT7-00077Q-Vx; Tue, 23 Sep 2003 15:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1sSy-000776-Gl for policy@optimus.ietf.org; Tue, 23 Sep 2003 15:04:53 -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 PAA00891 for ; Tue, 23 Sep 2003 15:04:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1sSv-0005Ae-00 for policy@ietf.org; Tue, 23 Sep 2003 15:04:49 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1sSu-0005AR-00 for policy@ietf.org; Tue, 23 Sep 2003 15:04:48 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 14:08:57 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:59:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38204.D5721750" 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_01C38204.D5721750 Content-Type: text/plain; charset="iso-8859-1" John, I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem. However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that. Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 1:03 PM To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38204.D5721750 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] RE: PCELS position
John,
 
I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem.
 
However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that.
 
Mircea.
 
 
 
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.

 

Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.

 

So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier.

 

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C38204.D5721750-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 15:13:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02021 for ; Tue, 23 Sep 2003 15:13:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1saq-0007ar-HU for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:13:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NJD0ou029172 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1saq-0007aA-4L; Tue, 23 Sep 2003 15:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1saD-0007ZR-2z for policy@optimus.ietf.org; Tue, 23 Sep 2003 15:12:21 -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 PAA01878 for ; Tue, 23 Sep 2003 15:12:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1saB-0005Ie-00 for policy@ietf.org; Tue, 23 Sep 2003 15:12:19 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1saA-0005IF-00 for policy@ietf.org; Tue, 23 Sep 2003 15:12:18 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:11:46 -0600 Message-ID: From: John Strassner To: "'Pana, Mircea'" , John Strassner , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:11:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38206.826F9030" 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_01C38206.826F9030 Content-Type: text/plain Mircea, The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem. I disagree because: 1) the semantics of the two defining classes are different 2) the derivation of the two defining classes are different It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer? 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Tuesday, September 23, 2003 1:00 PM To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position John, I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem. However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that. Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 1:03 PM To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38206.826F9030 Content-Type: text/html RE: [Policy] RE: PCELS position

Mircea,

 

The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem.

 

I disagree because:

 

1)       the semantics of the two defining classes are different

2)       the derivation of the two defining classes are different

 

It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer?

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Tuesday, September 23, 2003 1:00 PM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

John,

 

I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem.

 

However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that.

 

Mircea.

 

 

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.

 

Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.

 

So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier.

 

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C38206.826F9030-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 15:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03043 for ; Tue, 23 Sep 2003 15:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1snT-0008Ru-F2 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NJQ30Y032478 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1snS-0008RK-8F; Tue, 23 Sep 2003 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1smm-0008QF-Sl for policy@optimus.ietf.org; Tue, 23 Sep 2003 15:25:20 -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 PAA02926 for ; Tue, 23 Sep 2003 15:25:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1sml-0005Wm-00 for policy@ietf.org; Tue, 23 Sep 2003 15:25:19 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1smk-0005WF-00 for policy@ietf.org; Tue, 23 Sep 2003 15:25:18 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:24:47 -0600 Message-ID: From: John Strassner To: "'David McTavish'" , John Strassner , "'Wijnen, Bert (Bert)'" , "'Pana, Mircea'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:24:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38208.5357D440" 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_01C38208.5357D440 Content-Type: text/plain Hi David, Thanks for a thoughtful response, even if my original posting wasn't directed specifically at you. :-) I believe that the root of the problem lies in the wording of PCIMe. I note that in PCLS, the dreaded priority rule attribute is NOT mandatory, viz: ( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule' DESC 'The base class for representing the "If Condition then Action" semantics associated with a policy rule.' SUP pcimPolicy ABSTRACT MAY ( pcimRuleName $ pcimRuleEnabled $ pcimRuleConditionListType $ pcimRuleConditionList $ pcimRuleActionList $ pcimRuleValidityPeriodList $ pcimRuleUsage $ pcimRulePriority $ pcimRuleMandatory $ pcimRuleSequencedActions $ pcimRoles ) ) Hopefully, we've already agreed that deprecation is a Bad Thing in a schema. And I completely agree with your third issue - as a co-author of PCIMe, I voted against this change as I couldn't understand the logic, but was out voted. I note that this falls under the area of Bert's "don't bring it up again". At this point, I need to reread your thorough analyses and possibly 3460 and 3060 to see what went wrong. Although I hope that the PCELS authors will reply before me, especially since my time is rather limited this week. 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 -----Original Message----- From: David McTavish [mailto:dmctavish@sandvine.com] Sent: Tuesday, September 23, 2003 11:56 AM To: 'John Strassner'; 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position John, I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced. My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM. My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it. My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction. By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters. The core key issues that limit compatibility between PCIM and PCIMe are as follows: - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM. If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM. Regards, d. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 12:43 PM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Importance: High I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models. 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 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 4:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38208.5357D440 Content-Type: text/html PCELS position

Hi David,

 

Thanks for a thoughtful response, even if my original posting wasn't directed specifically at you. J

 

I believe that the root of the problem lies in the wording of PCIMe. I note that in PCLS, the dreaded priority rule attribute is NOT mandatory, viz:

 

     ( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule'

            DESC 'The base class for representing the "If Condition

                  then Action" semantics associated with a policy rule.'

            SUP pcimPolicy           

            ABSTRACT

            MAY ( pcimRuleName $ pcimRuleEnabled $

                  pcimRuleConditionListType $ pcimRuleConditionList $ 

                  pcimRuleActionList $ pcimRuleValidityPeriodList $ 

                  pcimRuleUsage $ pcimRulePriority $ 

                  pcimRuleMandatory $ pcimRuleSequencedActions $ 

                  pcimRoles )

     )

 

Hopefully, we've already agreed that deprecation is a Bad Thing in a schema. And I completely agree with your third issue - as a co-author of PCIMe, I voted against this change as I couldn't understand the logic, but was out voted. I note that this falls under the area of Bert's "don't bring it up again".

 

At this point, I need to reread your thorough analyses and possibly 3460 and 3060 to see what went wrong. Although I hope that the PCELS authors will reply before me, especially since my time is rather limited this week.

 

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

-----Original Message-----
From: David McTavish [mailto:dmctavish@sandvine.com]
Sent: Tuesday, September 23, 2003 11:56 AM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

John,

 

I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced.  My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM.  My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it.  My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction.  By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters.

 

The core key issues that limit compatibility between PCIM and PCIMe are as follows:

 - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults

 - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment

 - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility

 

You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM.

 

If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM.

 

Regards,

d.

 

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position
Importance: High

I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models.

 

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

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.

>  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? 

 

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we

find that we did some things in PCIMe that we should not have done, then, with WG consensus,

we can make incompatible changes to PCIMe and then recycle at Proposed Standard.

That is part of the normal standars track process. That is, we get something to PS, then we start

using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the

other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for

example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not

find major issues, we may advance to DS.

 

Hope this helps.

Bert

------_=_NextPart_001_01C38208.5357D440-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 15:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03879 for ; Tue, 23 Sep 2003 15:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tFa-0001Sw-Ie for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:55:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NJt6QE005610 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 15:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tFW-0001S4-UR; Tue, 23 Sep 2003 15:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tFE-0001Rk-KZ for policy@optimus.ietf.org; Tue, 23 Sep 2003 15:54:44 -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 PAA03853 for ; Tue, 23 Sep 2003 15:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1tFD-0005r1-00 for policy@ietf.org; Tue, 23 Sep 2003 15:54:43 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1tFC-0005qS-00 for policy@ietf.org; Tue, 23 Sep 2003 15:54:42 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Sep 2003 12:56:28 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8NJrZwn001975; Tue, 23 Sep 2003 12:53:56 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-221.cisco.com [10.82.240.221]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACP80891; Tue, 23 Sep 2003 15:53:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030923154547.01f96d88@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Sep 2003 15:53:33 -0400 To: John Strassner From: John Schnizlein Subject: RE: [Policy] RE: PCELS position Cc: "'policy@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , At 03:11 PM 9/23/2003, John Strassner wrote: >It's like saying that a Hummer and a Boat both have an engine, >so why can't I use the Boat's engine in a Hummer? Aren't Chrysler V-8 engines used in both some boats and SUVs? The transmissions are different, but as long as the external parameters of the object (torque, horsepower, etc.) match, an engine is an engine. John Not sure this helps, but the metaphor seem apt. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 16:00:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04090 for ; Tue, 23 Sep 2003 16:00:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tKQ-0001sv-5R for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 16:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NK04Uw007143 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 16:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tKN-0001qr-4Q; Tue, 23 Sep 2003 16:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1tJX-0001ja-Ft for policy@optimus.ietf.org; Tue, 23 Sep 2003 15:59:11 -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 PAA04039 for ; Tue, 23 Sep 2003 15:59:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1tJV-0005ud-00 for policy@ietf.org; Tue, 23 Sep 2003 15:59:09 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1tJV-0005u8-00 for policy@ietf.org; Tue, 23 Sep 2003 15:59:09 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:58:39 -0600 Message-ID: From: John Strassner To: "'John Schnizlein'" , John Strassner Cc: "'policy@ietf.org'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:58:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3820D.13B1A1E0" 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_01C3820D.13B1A1E0 Content-Type: text/plain That only obfuscates the problem, which is violating OO design principles. 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 > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Tuesday, September 23, 2003 1:54 PM > To: John Strassner > Cc: 'policy@ietf.org' > Subject: RE: [Policy] RE: PCELS position > > At 03:11 PM 9/23/2003, John Strassner wrote: > > >It's like saying that a Hummer and a Boat both have an engine, > >so why can't I use the Boat's engine in a Hummer? > > Aren't Chrysler V-8 engines used in both some boats and SUVs? > The transmissions are different, but as long as the external > parameters of the object (torque, horsepower, etc.) match, > an engine is an engine. > > John > > Not sure this helps, but the metaphor seem apt. ------_=_NextPart_001_01C3820D.13B1A1E0 Content-Type: text/html RE: [Policy] RE: PCELS position

That only obfuscates the problem, which is violating OO design principles.

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


> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Tuesday, September 23, 2003 1:54 PM
> To: John Strassner
> Cc: 'policy@ietf.org'
> Subject: RE: [Policy] RE: PCELS position
>
> At 03:11 PM 9/23/2003, John Strassner wrote:
>
> >It's like saying that a Hummer and a Boat both have an engine,
> >so why can't I use the Boat's engine in a Hummer?
>
> Aren't Chrysler V-8 engines used in both some boats and SUVs?
> The transmissions are different, but as long as the external
> parameters of the object (torque, horsepower, etc.) match,
> an engine is an engine.
>
> John
>
> Not sure this helps, but the metaphor seem apt.

------_=_NextPart_001_01C3820D.13B1A1E0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09427 for ; Tue, 23 Sep 2003 18:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vGR-0000kS-Pk for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:04:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NM47Wc002870 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:04:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vGL-0000jz-1A; Tue, 23 Sep 2003 18:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vGG-0000jn-FJ for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:03:56 -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 SAA09315 for ; Tue, 23 Sep 2003 18:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1vGD-0007ew-00 for policy@ietf.org; Tue, 23 Sep 2003 18:03:53 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1vGC-0007eO-00 for policy@ietf.org; Tue, 23 Sep 2003 18:03:52 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 17:07:39 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 16:58:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3821D.CB5C9290" 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_01C3821D.CB5C9290 Content-Type: text/plain; charset="iso-8859-1" John, IMO an LDAP attribute is not defined *for* a class. An LDAP attribute defined in the global context and then *used* by LDAP object classes. An attribute has a syntax and (basic) semantics of its own and these are carried over in any class that use the attribute. Then, in the context of a class an attribute may have additional semantics. The semantics associated by the class to an attribute are not necessarely shared with other classes that use the attribute. Such semantics belog to the class not the attribute. For example, a fictional attribute "ipv4Addresses" may be a list of ip addresses in the x.x.x.x notation. In a "mailServer" class this attribute may be used to store the ip addresses of this mail server. In an "ingressFilter" class however, the same attribute may be used to match source/dest ip addresses of ingress ip packets. Same attribute - different class semantics. So, it's like saying that a Hummer and a Boat have the same type of engine even though they use this engine in different ways (one connected to the weels, the other to the propeller). Regards, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 3:12 PM To: 'Pana, Mircea'; John Strassner; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Mircea, The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem. I disagree because: 1) the semantics of the two defining classes are different 2) the derivation of the two defining classes are different It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer? 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Tuesday, September 23, 2003 1:00 PM To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position John, I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem. However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that. Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 1:03 PM To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C3821D.CB5C9290 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] RE: PCELS position
John,
 
IMO an LDAP attribute is not defined *for* a class. An LDAP attribute defined in the global context and then *used* by LDAP object classes. An attribute has a syntax and (basic) semantics of its own and these are carried over in any class that use the attribute. Then, in the context of a class an attribute may have additional semantics. The semantics associated by the class to an attribute are not necessarely shared with other classes that use the attribute. Such semantics belog to the class not the attribute.
 
For example, a fictional attribute "ipv4Addresses" may be a list of ip addresses in the x.x.x.x notation. In a "mailServer" class this attribute may be used to store the ip addresses of this mail server. In an "ingressFilter" class however, the same attribute may be used to match source/dest ip addresses of ingress ip packets. Same attribute - different class semantics.
 
So, it's like saying that a Hummer and a Boat have the same type of engine even though they use this engine in different ways (one connected to the weels, the other to the propeller).
 
Regards,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 3:12 PM
To: 'Pana, Mircea'; John Strassner; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Mircea,

 

The pcimRuleEnabled attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled attribute is defined for the pcimPolicyRule. You claim that since the definition of pcimRuleEnabled is the same, there should be no problem.

 

I disagree because:

 

1)       the semantics of the two defining classes are different

2)       the derivation of the two defining classes are different

 

It's like saying that a Hummer and a Boat both have an engine, so why can't I use the Boat's engine in a Hummer?

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Tuesday, September 23, 2003 1:00 PM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

John,

 

I agree with you that an attribute should not be used in classes where it would shift semantics. For example, the RulePriority attribute defined in PCLS and used there by the Rule class, is not reused in PCELS. Instead, PCELS defined a new Priority attribute for use in the realization of PolicySetComponent and PolicySetInSystem.

 

However, the attribute RuleEnabled defined in PCLS is reused in the PolicyRule class defined by PCELS. In both classes the attribute has identical semantics. I see nothing wrong with that.

 

Mircea.

 

 

 

-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.

 

Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.

 

So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier.

 

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C3821D.CB5C9290-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10906 for ; Tue, 23 Sep 2003 18:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vTu-0001Yb-Ab for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMI2V8005968 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vTt-0001Xu-6b; Tue, 23 Sep 2003 18:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vTf-0001Xb-KV for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:17:47 -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 SAA10892 for ; Tue, 23 Sep 2003 18:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1vTc-00001g-00 for policy@ietf.org; Tue, 23 Sep 2003 18:17:44 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1vTc-00001J-00 for policy@ietf.org; Tue, 23 Sep 2003 18:17:44 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 17:21:54 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 17:12:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3821F.C98CC9B0" 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_01C3821F.C98CC9B0 Content-Type: text/plain; charset="iso-8859-1" I agree with John. The mapping of an information model to a data model has its own chalenges and the chalenges will be different from one technology to an other. That does not mean that we have to revisit the model each time. I am not trying to say that PCIMe is perfect and that it should never be revisited, but I do not see (so far) enough reasons for re-opening such discussions. Regards, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 12:43 PM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Importance: High I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models. 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 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 4:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C3821F.C98CC9B0 Content-Type: text/html; charset="iso-8859-1" PCELS position
I agree with John. The mapping of an information model to a data model has its own chalenges and the chalenges will be different from one technology to an other. That does not mean that we have to revisit the model each time.
 
I am not trying to say that PCIMe is perfect and that it should never be revisited, but I do not see (so far) enough reasons for re-opening such discussions. 
 
Regards,
Mircea.
 
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position
Importance: High

I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models.

 

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

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.

>  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? 

 

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we

find that we did some things in PCIMe that we should not have done, then, with WG consensus,

we can make incompatible changes to PCIMe and then recycle at Proposed Standard.

That is part of the normal standars track process. That is, we get something to PS, then we start

using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the

other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for

example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not

find major issues, we may advance to DS.

 

Hope this helps.

Bert

------_=_NextPart_001_01C3821F.C98CC9B0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:35:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11413 for ; Tue, 23 Sep 2003 18:35:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vkM-0002Q3-G3 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:35:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMZ24W009300 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vkL-0002Ph-D5; Tue, 23 Sep 2003 18:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vk1-0002PF-MY for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:34:41 -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 SAA11400 for ; Tue, 23 Sep 2003 18:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1vjy-0000Cq-00 for policy@ietf.org; Tue, 23 Sep 2003 18:34:38 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A1vjy-0000Cg-00 for policy@ietf.org; Tue, 23 Sep 2003 18:34:38 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8NMY5u12462 for ; Tue, 23 Sep 2003 17:34:05 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 24 Sep 2003 00:34:04 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC2B0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Policy (E-mail)" Cc: "Ted Hardie (E-mail)" Date: Wed, 24 Sep 2003 00:34:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] RE: draft-reyes-policy-core-ext-schema-03.txt 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 doc has been in RFC-Editor queue for a long time because it had a normative reference to a ID that had too much trouble getting approved: >2002/11/04 draft-ietf-policy-core-schema-16.txt >REF draft-zeilenga-ldap-user-schema-06.txt A new document (containing a proper subset of the above) have been created and has now been approved by IESG: draft-zeilenga-ldap-user-schema-mr-00.txt So with that new doc in the RFC-Editor queue (any day now) we hope that this policy-core-schema doc can also be published soon. Thanks, Bert -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: dinsdag 3 juni 2003 20:25 To: Wijnen, Bert (Bert); Larry S. Bartz; Joel M. Halpern Cc: policy@ietf.org; Randy Bush; Ed Ellesson; Wijnen, Bert (Bert) Subject: RE: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-co re-schema-16.txt] > > > According to the IETF's Internet Draft Status Tracker facility, >> the status of draft-zeilenga-ldap-user-schema has not changed since >> April 17. Is it reasonable for PCLS to wait upon an activity which >> is apparently not making progress? >> > >I can tell you that that doc has been discussed a few times in the IESG >lately and that the responsible AD (Ted Hardie) is trying to work out >a resolution. Ted... any more you want to add? After the review comments, Kurt has come to believe that the current document is actually too much of a grab bag, and that it probably needs to be split to make progress. We have had some discussion on where those splits should be, and it does look likely that one of the "daughter" documents will contain just the matching rules, which will enable this to unstick. We're working through right now where that leaves in terms of process (e.g., do we need to have a new IETF last call, since all of the text in this has previously been last called?). I've updated the tracker to reflect the "new ID needed" state, which is as close as we can come in the current system. Sorry that hadn't been done before, things were in flux enough that I haven't been sure how to mark this. regards, Ted Hardie _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:38:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11528 for ; Tue, 23 Sep 2003 18:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vnH-0002nI-P5 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMc36h010713 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vnG-0002mB-NO; Tue, 23 Sep 2003 18:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vmy-0002k2-PK for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:37:44 -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 SAA11511 for ; Tue, 23 Sep 2003 18:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1vmv-0000Ey-00 for policy@ietf.org; Tue, 23 Sep 2003 18:37:41 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A1vmv-0000Eg-00 for policy@ietf.org; Tue, 23 Sep 2003 18:37:41 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h8NMb6d15173 for ; Tue, 23 Sep 2003 17:37:07 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Wed, 24 Sep 2003 00:37:05 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC2B1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Policy (E-mail)" Cc: "Ted Hardie (E-mail)" Date: Wed, 24 Sep 2003 00:37:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] draft-ietf-policy-co re-schema-16.txt 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: , Sorry, the below of course is about document draft-ietf-policy-co re-schema-16.txt I guess it is time to go get some sleep now. Thanks, Bert -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: woensdag 24 september 2003 0:34 To: Policy (E-mail) Cc: Ted Hardie (E-mail) Subject: [Policy] RE: draft-reyes-policy-core-ext-schema-03.txt This doc has been in RFC-Editor queue for a long time because it had a normative reference to a ID that had too much trouble getting approved: >2002/11/04 draft-ietf-policy-core-schema-16.txt >REF draft-zeilenga-ldap-user-schema-06.txt A new document (containing a proper subset of the above) have been created and has now been approved by IESG: draft-zeilenga-ldap-user-schema-mr-00.txt So with that new doc in the RFC-Editor queue (any day now) we hope that this policy-core-schema doc can also be published soon. Thanks, Bert -----Original Message----- From: hardie@qualcomm.com [mailto:hardie@qualcomm.com] Sent: dinsdag 3 juni 2003 20:25 To: Wijnen, Bert (Bert); Larry S. Bartz; Joel M. Halpern Cc: policy@ietf.org; Randy Bush; Ed Ellesson; Wijnen, Bert (Bert) Subject: RE: PCLS when? [was: Re: [Policy] Approved: draft-ietf-policy-co re-schema-16.txt] > > > According to the IETF's Internet Draft Status Tracker facility, >> the status of draft-zeilenga-ldap-user-schema has not changed since >> April 17. Is it reasonable for PCLS to wait upon an activity which >> is apparently not making progress? >> > >I can tell you that that doc has been discussed a few times in the IESG >lately and that the responsible AD (Ted Hardie) is trying to work out >a resolution. Ted... any more you want to add? After the review comments, Kurt has come to believe that the current document is actually too much of a grab bag, and that it probably needs to be split to make progress. We have had some discussion on where those splits should be, and it does look likely that one of the "daughter" documents will contain just the matching rules, which will enable this to unstick. We're working through right now where that leaves in terms of process (e.g., do we need to have a new IETF last call, since all of the text in this has previously been last called?). I've updated the tracker to reflect the "new ID needed" state, which is as close as we can come in the current system. Sorry that hadn't been done before, things were in flux enough that I haven't been sure how to mark this. regards, Ted Hardie _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:50:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11818 for ; Tue, 23 Sep 2003 18:50:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vyt-0003MX-IB for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMo3Vh012923 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vys-0003M3-Ba; Tue, 23 Sep 2003 18:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1vyp-0003Lc-GG for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:49:59 -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 SAA11803 for ; Tue, 23 Sep 2003 18:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1vym-0000LV-00 for policy@ietf.org; Tue, 23 Sep 2003 18:49:56 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1vyl-0000LI-00 for policy@ietf.org; Tue, 23 Sep 2003 18:49:55 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 17:54:05 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner'" , "Pana, Mircea" , "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'policy@ietf.org'" Cc: "'Joel M. Halpern'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 17:44:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38224.48FD76F0" 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_01C38224.48FD76F0 Content-Type: text/plain; charset="iso-8859-1" I have probably not expressed myself clearly. My intent was to highlight a few areas where PCELS has difficulty mapping PCIMe in a manner that would be compatible with PCLS. Further I crafted an interpretation (in lack of better wording) of the model that, if applied to the LDAP mapping, would alleviate the problem. I was not trying to challenge the model but to find the right interpretation (or compromise I should say). Regards, Mircea. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 1:03 PM To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert ------_=_NextPart_001_01C38224.48FD76F0 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] RE: PCELS position
I have probably not expressed myself clearly. My intent was to highlight a few areas where PCELS has difficulty mapping PCIMe in a manner that would be compatible with PCLS. Further I crafted an interpretation (in lack of better wording) of the model that, if applied to the LDAP mapping, would alleviate the problem. I was not trying to challenge the model but to find the right interpretation (or compromise I should say).
 
Regards,
Mircea.
-----Original Message-----
From: John Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards.

 

Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID.

 

So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier.

 

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

-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows:

1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup

2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects.

C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule

D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

 

W.r.t.
>  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?

PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then, with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed Standard.
That is part of the normal standars track process. That is, we get something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not
find major issues, we may advance to DS.

Hope this helps.
Bert

------_=_NextPart_001_01C38224.48FD76F0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 18:57:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12088 for ; Tue, 23 Sep 2003 18:57:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w5d-0003wX-Pr for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:57:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NMv1MP015148 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 18:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w5c-0003w1-Mm; Tue, 23 Sep 2003 18:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1w51-0003vM-BL for policy@optimus.ietf.org; Tue, 23 Sep 2003 18:56:23 -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 SAA12070 for ; Tue, 23 Sep 2003 18:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1w4t-0000RF-00 for policy@ietf.org; Tue, 23 Sep 2003 18:56:15 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1w4s-0000QV-00 for policy@ietf.org; Tue, 23 Sep 2003 18:56:14 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 18:00:24 -0500 Message-ID: From: "Pana, Mircea" To: "'David McTavish'" Cc: "'policy@ietf.org'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 17:51:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38225.2A14E880" 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_01C38225.2A14E880 Content-Type: text/plain; charset="iso-8859-1" David, Regards, Mircea. > -----Original Message----- > From: David McTavish [mailto:dmctavish@sandvine.com] > Sent: Tuesday, September 23, 2003 1:33 PM > To: 'Robert Moore'; John Strassner > Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John > Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org > Subject: RE: [Policy] RE: PCELS position > > > Hi Bob, > Unfortunately, in LDAP, attributes must be globally unique. I don't think this is unfortunate ;-) > So, if an > attribute is defined as "foo" in one objectclass as a > boolean, and as an > integer in another class, this causes an incompatibility. In This should be prevented from happening but it is a matter of server implementation. To be compliant with LDAP one must stick to the syntax globally defined for the attribute. > some cases > (OpenLDAP), this prevents the server from even starting. It's > not the most > elegant implementation, but something you get used to when > working on LDAP. You make it sound so painful ;-) > > Hope this is informational, > d. > > > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: Tuesday, September 23, 2003 1:26 PM > To: John Strassner > Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John > Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org > Subject: RE: [Policy] RE: PCELS position > > > > > > > >Furthermore, the argument that you are "reusing" an > attribute foo in a new > class bar is completely specious, because the new class >bar > is different > than the original class baz that defined foo. The differences are very > fundamental - different hierarchies, different >attributes, and worse > (e.g., the definition of priority). This isn't reuse, this is simply > stealing an OID. > > John, I'll have to say that I'm missing the essence of your > argument here. > Formally (as you've acknowledged), LDAP falls into the same > category as > X.500 and CMIP: attributes are defined, and maintain their identity, > independent of the classes in which they appear. (Digression > for those who > haven't worked in the DMTF: CIM works the opposite way -- an > attribute's > identity is tied to the class in which it is defined, so that > it's possible > to have two attributes with identical names defined in two > different CIM > classes. This is, of course, a potential source of > confusion, so there > were DMTF guidelines saying "Don't do this." But these provided an > artificial overlay of global scope on attributes whose identity was > inherently scoped by the classes that defined them.) I don't > have specific > experience with X.500 and LDAP, but I do know that in the > CMIP case it was > perfectly good practice (in fact, it was typical) to define attributes > without regard to the classes that would include them. I'm > don't see why > X.500 and LDAP should be any different. But your use of the > wording "... > the original class baz that defined foo" suggests that you see some > non-formal, but nevertheless significant sense in which LDAP > attributes > *are* defined relative to the (first?) class that contains them. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > > John Strassner > > "'Pana, Mircea'" > , "'Wijnen, Bert (Bert)'" > lliden.com> > , > "'David McTavish'" , "'policy@ietf.org'" > Sent by: > > policy-admin@ietf.or cc: > John Strassner > , "'Joel M. Halpern'" > g > > > Subject: > RE: [Policy] RE: > PCELS position > > > 09/23/2003 01:03 PM > > > > > > > > Again, you are trying to determine the validity of an > information model > based on the concerns of one specific data model. This is backwards. > > Furthermore, the argument that you are "reusing" an attribute > foo in a new > class bar is completely specious, because the new class bar > is different > than the original class baz that defined foo. The differences are very > fundamental - different hierarchies, different attributes, > and worse (e.g., > the definition of priority). This isn't reuse, this is simply > stealing an > OID. > > So, how about defining a NEW set of classes and attributes? And if you > prefixes the new classes and attributes, this would also get > around the > schema problem that I stated earlier. > > > > 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 > -----Original Message----- > From: Pana, Mircea [mailto:mpana@metasolv.com] > Sent: Monday, September 22, 2003 8:21 AM > To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; > 'policy@ietf.org' > Cc: 'John Strassner'; 'Joel M. Halpern' > Subject: RE: [Policy] RE: PCELS position > > > > Maybe there is no need for such drastic measures. Maybe it is > only a matter > of interpretation of the PCIMe recommendations. After all > PCIMe is quite > lenient wrt. that is and what is not used in submodels (see > PCIMe section > 5.10.). > > > Some of the structural changes proposed by PCIMe make it difficult for > PCELS to be interoperable with PCLS. These are as follows: > > > 1. PCIMe defines a new abstract class, PolicySet, and makes > it a superclass > of the already defined PolicyRule and PolicyGroup > > > 2. In PCIMe the PolicyRule.Priority property has been > deprecated in favor > of a new relative priority mechanism. > 3. PolicyRepository is deprecated in favor of the new > ReusablePolicyContainer. > > PCELS could be interoperable with PCLS if it was to interpret > these PCIMe > changes as follows: > A. there is no need to have an explicit LDAP mapping of the abstract > PolicySet. (see also B.) > B. there is no need to have an explicit LDAP mapping of the modified > PolicyGroup. Implementations can use (the equivalent of) a > PolicyRule with > no Actions or Conditions for PolicyGroup objects. > > > C. implementations SHOULD (as opposed to MUST) use the > relative priority > mechanism instead of the absolute priority attribute of PolicyRule > > > D. PolicyRepository SHOULD not be used directly but it is > acceptable for > instances of this class to occur through inheritance. > > > So, the question is whether the statements A. through D. > violate PCIMe or > not. Opinions? > > > Thanks, > Mircea. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, September 21, 2003 6:14 AM > To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' > Cc: 'John Strassner'; 'Joel M. Halpern' > Subject: RE: [Policy] RE: PCELS position > > > > W.r.t. > > 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? > > > PCIMe is at Proposed Standard. If, for example because of > this effort to > try and MAP it onto LDAP, we > find that we did some things in PCIMe that we should not have > done, then, > with WG consensus, > we can make incompatible changes to PCIMe and then recycle at Proposed > Standard. > That is part of the normal standars track process. That is, we get > something to PS, then we start > using/implementing (the "using" part is reusing PCIMe > definitions in otehr > CIM docs (like the > other docs we did in Policy, and like the IPsec work, the > "implementing" is > sort of mapping onto for > example LDAP I think)... and if we find major issues, then we fix and > recycle at PS. If we do not > find major issues, we may advance to DS. > > > Hope this helps. > Bert > > ------_=_NextPart_001_01C38225.2A14E880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] RE: PCELS position

David,

Regards,
Mircea.

> -----Original Message-----
> From: David McTavish [mailto:dmctavish@sandvine.com= ]
> Sent: Tuesday, September 23, 2003 1:33 = PM
> To: 'Robert Moore'; John Strassner
> Cc: 'Wijnen, Bert (Bert)'; David McTavish; = 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; 'policy@ietf.org'; = policy-admin@ietf.org
> Subject: RE: [Policy] RE: PCELS position
>
>
> Hi Bob,
> Unfortunately, in LDAP, attributes must be = globally unique.
I don't think this is unfortunate ;-)

> So, if an
> attribute is defined as "foo" in one = objectclass as a
> boolean, and as an
> integer in another class, this causes an = incompatibility. In
This should be prevented from happening but it is a = matter of server implementation. To be compliant with LDAP one must = stick to the syntax globally defined for the attribute.

 
> some cases
> (OpenLDAP), this prevents the server from even = starting. It's
> not the most
> elegant implementation, but something you get = used to when
> working on LDAP.
You make it sound so painful ;-)

>
> Hope this is informational,
> d.
>
>
> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]=
> Sent: Tuesday, September 23, 2003 1:26 = PM
> To: John Strassner
> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; = 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; 'policy@ietf.org'; = policy-admin@ietf.org
> Subject: RE: [Policy] RE: PCELS position
>
>
>
>
>
>
> >Furthermore, the argument that you are = "reusing" an
> attribute foo in a new
> class bar is completely specious, because the = new class >bar
> is different
> than the original class baz that defined foo. = The differences are very
> fundamental - different hierarchies, different = >attributes, and worse
> (e.g., the definition of priority). This isn't = reuse, this is simply
> stealing an OID.
>
> John, I'll have to say that I'm missing the = essence of your
> argument here.
> Formally (as you've acknowledged), LDAP falls = into the same
> category as
> X.500 and CMIP: attributes are defined, and = maintain their identity,
> independent of the classes in which they = appear.  (Digression
> for those who
> haven't worked in the DMTF: CIM works the = opposite way -- an
> attribute's
> identity is tied to the class in which it is = defined, so that
> it's possible
> to have two attributes with identical names = defined in two
> different CIM
> classes.  This is, of course, a potential = source of
> confusion, so there
> were DMTF guidelines saying "Don't do = this."  But these provided an
> artificial overlay of global scope on = attributes whose identity was
> inherently scoped by the classes that defined = them.)  I don't
> have specific
> experience with X.500 and LDAP, but I do know = that in the
> CMIP case it was
> perfectly good practice (in fact, it was = typical) to define attributes
> without regard to the classes that would = include them.  I'm
> don't see why
> X.500 and LDAP should be any different.  = But your use of the
> wording "...
> the original class baz that defined foo" = suggests that you see some
> non-formal, but nevertheless significant sense = in which LDAP
> attributes
> *are* defined relative to the (first?) class = that contains them.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
> 
>
>          = ;            = ; John Strassner
>
>          = ;            = ; <John.Strassner@inte        = To:      
> "'Pana, Mircea'"
> <mpana@metasolv.com>, "'Wijnen, Bert = (Bert)'"          = ;     
>          = ;            = ; = lliden.com>         &nbs= p;       
> <bwijnen@lucent.com>,
> "'David McTavish'" = <dmctavish@sandvine.com>, "'policy@ietf.org'"
>          = ;            = ; Sent = by:           &nb= sp;         = <policy@ietf.org>
>
>          = ;            = ; policy-admin@ietf.or        = cc:      
> John Strassner
> <John.Strassner@intelliden.com>, = "'Joel M. = Halpern'"         &nbs= p;
>          = ;            = ; = g            = ;            = ;   
> <joel@stevecrocker.com>
>
>          = ;            = ;            = ;            = ;     Subject: 
> RE: [Policy] RE:
> PCELS = position          &nbs= p;           &nbs= p;           &nbs= p;            =
> 
>
>          = ;            = ; 09/23/2003 01:03 PM
>
> 
>
>
>
>
>
> Again, you are trying to determine the validity = of an
> information model
> based on the concerns of one specific data = model. This is backwards.
>
> Furthermore, the argument that you are = "reusing" an attribute
> foo in a new
> class bar is completely specious, because the = new class bar
> is different
> than the original class baz that defined foo. = The differences are very
> fundamental - different hierarchies, different = attributes,
> and worse (e.g.,
> the definition of priority). This isn't reuse, = this is simply
> stealing an
> OID.
>
> So, how about defining a NEW set of classes and = attributes? And if you
> prefixes the new classes and attributes, this = would also get
> around the
> schema problem that I stated earlier.
>
>
>
> 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
> -----Original Message-----
> From: Pana, Mircea [mailto:mpana@metasolv.com]=
> Sent: Monday, September 22, 2003 8:21 AM
> To: 'Wijnen, Bert (Bert)'; 'David McTavish'; = Pana, Mircea;
> 'policy@ietf.org'
> Cc: 'John Strassner'; 'Joel M. Halpern'
> Subject: RE: [Policy] RE: PCELS position
>
>
>
> Maybe there is no need for such drastic = measures. Maybe it is
> only a matter
> of interpretation of the PCIMe recommendations. = After all
> PCIMe is quite
> lenient wrt. that is and what is not used in = submodels (see
> PCIMe section
> 5.10.).
>
>
> Some of the structural changes proposed by = PCIMe make it difficult for
> PCELS to be interoperable with PCLS. These are = as follows:
>
>
> 1. PCIMe defines a new abstract class, = PolicySet, and makes
> it a superclass
> of the already defined PolicyRule and = PolicyGroup
>
>
> 2. In PCIMe the PolicyRule.Priority property = has been
> deprecated in favor
> of a new relative priority mechanism.
> 3. PolicyRepository is deprecated in favor of = the new
> ReusablePolicyContainer.
>
> PCELS could be interoperable with PCLS if it = was to interpret
> these PCIMe
> changes as follows:
> A. there is no need to have an explicit LDAP = mapping of the abstract
> PolicySet. (see also B.)
> B. there is no need to have an explicit LDAP = mapping of the modified
> PolicyGroup. Implementations can use (the = equivalent of) a
> PolicyRule with
> no Actions or Conditions for PolicyGroup = objects.
>
>
> C. implementations SHOULD (as opposed to MUST) = use the
> relative priority
> mechanism instead of the absolute priority = attribute of PolicyRule
>
>
> D. PolicyRepository SHOULD not be used directly = but it is
> acceptable for
> instances of this class to occur through = inheritance.
>
>
> So, the question is whether the statements A. = through D.
> violate PCIMe or
> not. Opinions?
>
>
> Thanks,
> Mircea.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Sunday, September 21, 2003 6:14 AM
> To: 'David McTavish'; 'Pana, Mircea'; = 'policy@ietf.org'
> Cc: 'John Strassner'; 'Joel M. Halpern'
> Subject: RE: [Policy] RE: PCELS position
>
>
>
> W.r.t.
> >  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?
>
>
> PCIMe is at Proposed Standard. If, for example = because of
> this effort to
> try and MAP it onto LDAP, we
> find that we did some things in PCIMe that we = should not have
> done, then,
> with WG consensus,
> we can make incompatible changes to PCIMe and = then recycle at Proposed
> Standard.
> That is part of the normal standars track = process. That is, we get
> something to PS, then we start
> using/implementing (the "using" part = is reusing PCIMe
> definitions in otehr
> CIM docs (like the
> other docs we did in Policy, and like the IPsec = work, the
> "implementing" is
> sort of mapping onto for
> example LDAP I think)... and if we find major = issues, then we fix and
> recycle at PS. If we do not
> find major issues, we may advance to DS.
>
>
> Hope this helps.
> Bert
>
>

------_=_NextPart_001_01C38225.2A14E880-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Tue Sep 23 21:53:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18149 for ; Tue, 23 Sep 2003 21:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1yq3-0005Li-3U for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 21:53:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O1r7TR020547 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 21:53:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ypx-0005L6-Uw; Tue, 23 Sep 2003 21:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ypk-0005Kl-5U for policy@optimus.ietf.org; Tue, 23 Sep 2003 21:52:48 -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 VAA18133 for ; Tue, 23 Sep 2003 21:52:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1yph-0002UQ-00 for policy@ietf.org; Tue, 23 Sep 2003 21:52:45 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A1ypg-0002U8-00 for policy@ietf.org; Tue, 23 Sep 2003 21:52:44 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Tue, 23 Sep 2003 20:56:55 -0500 Message-ID: From: "Pana, Mircea" To: "'John Strassner '" , "''Robert Moore' '" Cc: "''Wijnen, Bert (Bert)' '" , "''David McTavish' '" , "''Joel M. Halpern' '" , "Pana, Mircea" , "''policy@ietf.org' '" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 20:46:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3823D.B8DF3E40" 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_01C3823D.B8DF3E40 Content-Type: text/plain; charset="iso-8859-1" John, > 2) I do not believe that the word "reuse" applies when an > attribute is defined in one class, with one set of > semantics, and then is blopped into a new class with > completely different semantics. That is what I meant > by stealing an OID. I do not understand the difference in semantics that you are referring to. Let's take pcimRuleEnables one more time as example. PCLS defines it as: "An integer indicating whether a policy rule is administratively enabled (value=1), disabled (value=2), or enabled for debug (value=3)". In PCLS this attribute indicates the state of pcimRule, class mapped from PCIM's PolicyRule. In PCELS we use (but not redefine) this attribute preserving its its syntax and semantics to indicate the state of a pcimPolicyRule, class mapped from PCIMe's PolicyRule. Doesn't the attribute (I stress: the attribute not the class that uses it) have the same semantics in these two cases? Regards, Mircea. ------_=_NextPart_001_01C3823D.B8DF3E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Policy] RE: PCELS position

 John,


>  2) I do not believe that the word = "reuse" applies when an
>     attribute is defined in = one class, with one set of
>     semantics, and then is = blopped into a new class with
>     completely different = semantics. That is what I meant
>     by stealing an OID. =

I do not understand the difference in semantics that = you are referring to.

Let's take pcimRuleEnables one more time as example. = PCLS defines it as:
"An integer indicating whether a policy rule is = administratively enabled (value=3D1), disabled (value=3D2), or enabled = for debug (value=3D3)". In PCLS this attribute indicates the state = of pcimRule, class mapped from PCIM's PolicyRule. In PCELS we use (but = not redefine) this attribute preserving its its syntax and semantics to = indicate the state of a pcimPolicyRule, class mapped from PCIMe's = PolicyRule. Doesn't the attribute (I stress: the attribute not the = class that uses it) have the same semantics in these two = cases?

Regards,
Mircea.

------_=_NextPart_001_01C3823D.B8DF3E40-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 24 09:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12935 for ; Wed, 24 Sep 2003 09:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29am-0001pt-LO for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 09:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ODM4CJ007057 for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 09:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29ai-0001pX-LW; Wed, 24 Sep 2003 09:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29a1-0001oS-B3 for policy@optimus.ietf.org; Wed, 24 Sep 2003 09:21:17 -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 JAA12850 for ; Wed, 24 Sep 2003 09:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A29Zw-0003qA-00 for policy@ietf.org; Wed, 24 Sep 2003 09:21:12 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A29Zv-0003p4-00 for policy@ietf.org; Wed, 24 Sep 2003 09:21:11 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Wed, 24 Sep 2003 08:24:48 -0500 Message-ID: From: "Pana, Mircea" To: "'David McTavish'" , "'policy@ietf.org'" Subject: RE: [Policy] PCLS classes deprecated in PCELS Date: Wed, 24 Sep 2003 08:15:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3829D.E3B6CBF0" 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_01C3829D.E3B6CBF0 Content-Type: text/plain; charset="iso-8859-1" David, PCLS recommends: "A policy rule may have its conditions attached to itself and its actions attached to other entries, or it may have its actions attached to itself and its conditions attached to other entries. However, it SHALL NOT have either its conditions or its actions attached both to itself and to other entries, with one exception: a policy rule may reference its validity periods with the pcimRuleValidityPeriodList attribute, but have its other conditions attached to itself." Which implies that if a pcimTPCAuxClass is attached to a pcimRule (because pcimTPCAuxClass is a subclass of pcimConditionAuxClass) then no other conditions shall be aggregated (referenced) by that rule except for other validity periods aggregated through pcimRuleValidityPeriodList references. I am not sure about the reasons behind this limitation introduced by PCLS but in PCELS we have simply re-phrased it to make it clear for implementers. Regards, Mircea. Things I disagree with: 5.6 pcimPolicyRule "If a pcimPolicyRule instance has a pcimConditionAuxClass attached to it then the attribute pcimConditionList SHOULD NOT be present in the same entry for the purpose of associating other conditions to the rule. However, when such situations occur the referenced conditions MUST NOT be considered as associated to the rule." - this means that re-usable conditions are not easily used in conjuction with customized conditions. ie: we use PCIM to specify rules for policy-based filtering. For instance, we may have a pre-defined condition that is linked through the pcimConditionList, but the individual user may update their policy so that the rule contains a TimePeriodCondition that specifies it only is valid between the hours of 9-5. With the above language, this sort of amalgamation of conditions is not valid. I believe the configuration SHOULD be correct, and the evaluation of the conditions are done on a priority-based level. Regards, d. ------_=_NextPart_001_01C3829D.E3B6CBF0 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
David,
 
PCLS recommends:
 "A policy rule may have its conditions attached to itself and its actions
attached to other entries, or it may have its actions attached to itself
and its conditions attached to other entries. However, it SHALL NOT have
either its conditions or its actions attached both to itself and to
other entries, with one exception:  a policy rule may reference its
validity periods with the pcimRuleValidityPeriodList attribute, but have
its other conditions attached to itself."
 
Which implies that if a pcimTPCAuxClass is attached to a pcimRule (because pcimTPCAuxClass is a subclass of pcimConditionAuxClass) then no other conditions shall be aggregated (referenced) by that rule except for other validity periods aggregated through pcimRuleValidityPeriodList references. I am not sure about the reasons behind this limitation introduced by PCLS but in PCELS we have simply re-phrased it to make it clear for implementers.
Regards,
Mircea.
 
 
Things I disagree with:
5.6 pcimPolicyRule "If a pcimPolicyRule instance has a pcimConditionAuxClass attached to it then the attribute pcimConditionList SHOULD NOT be present in the same entry for the purpose of associating other conditions to the rule. However, when such situations occur the referenced conditions MUST NOT be considered as associated to the rule."
 - this means that re-usable conditions are not easily used in conjuction with customized conditions. ie: we use PCIM to specify rules for policy-based filtering. For instance, we may have a pre-defined condition that is linked through the pcimConditionList, but the individual user may update their policy so that the rule contains a TimePeriodCondition that specifies it only is valid between the hours of 9-5. With the above language, this sort of amalgamation of conditions is not valid. I believe the configuration SHOULD be correct, and the evaluation of the conditions are done on a priority-based level.
 
 
Regards,
d.
 
 
 
 
------_=_NextPart_001_01C3829D.E3B6CBF0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 24 11:31:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22236 for ; Wed, 24 Sep 2003 11:31:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bbe-0002UP-Pn for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 11:31:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFV6UE009565 for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 11:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BbZ-0002Tt-PK; Wed, 24 Sep 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bat-0002Sv-Qq for policy@optimus.ietf.org; Wed, 24 Sep 2003 11:30:22 -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 LAA22187 for ; Wed, 24 Sep 2003 11:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Bar-0006Fw-00 for policy@ietf.org; Wed, 24 Sep 2003 11:30:17 -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 1A2Bar-0006Ft-00 for policy@ietf.org; Wed, 24 Sep 2003 11:30:17 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Sep 2003 11:30:12 -0400 Message-ID: From: David McTavish To: "'Pana, Mircea'" , "'John Strassner '" , "''Robert Moore' '" Cc: "''Wijnen, Bert (Bert)' '" , David McTavish , "''Joel M. Halpern' '" , "''policy@ietf.org' '" Subject: RE: [Policy] RE: PCELS position Date: Wed, 24 Sep 2003 11:30:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C382B0.BD3AFB00" 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_01C382B0.BD3AFB00 Content-Type: text/plain; charset="iso-8859-1" One example of attribute re-use is the x500UniqueIdentifier attribute, which is defined in RFC 2256, and again used in inetOrgPerson RFC 2798. d. -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Tuesday, September 23, 2003 9:47 PM To: 'John Strassner '; ''Robert Moore' ' Cc: ''Wijnen, Bert (Bert)' '; ''David McTavish' '; ''Joel M. Halpern' '; Pana, Mircea; ''policy@ietf.org' ' Subject: RE: [Policy] RE: PCELS position John, > 2) I do not believe that the word "reuse" applies when an > attribute is defined in one class, with one set of > semantics, and then is blopped into a new class with > completely different semantics. That is what I meant > by stealing an OID. I do not understand the difference in semantics that you are referring to. Let's take pcimRuleEnables one more time as example. PCLS defines it as: "An integer indicating whether a policy rule is administratively enabled (value=1), disabled (value=2), or enabled for debug (value=3)". In PCLS this attribute indicates the state of pcimRule, class mapped from PCIM's PolicyRule. In PCELS we use (but not redefine) this attribute preserving its its syntax and semantics to indicate the state of a pcimPolicyRule, class mapped from PCIMe's PolicyRule. Doesn't the attribute (I stress: the attribute not the class that uses it) have the same semantics in these two cases? Regards, Mircea. ------_=_NextPart_001_01C382B0.BD3AFB00 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] RE: PCELS position
One example of attribute re-use is the x500UniqueIdentifier attribute, which is defined in RFC 2256, and again used in inetOrgPerson RFC 2798.
 
d.
 
-----Original Message-----
From: Pana, Mircea [mailto:mpana@metasolv.com]
Sent: Tuesday, September 23, 2003 9:47 PM
To: 'John Strassner '; ''Robert Moore' '
Cc: ''Wijnen, Bert (Bert)' '; ''David McTavish' '; ''Joel M. Halpern' '; Pana, Mircea; ''policy@ietf.org' '
Subject: RE: [Policy] RE: PCELS position

 John,


>  2) I do not believe that the word "reuse" applies when an
>     attribute is defined in one class, with one set of
>     semantics, and then is blopped into a new class with
>     completely different semantics. That is what I meant
>     by stealing an OID.

I do not understand the difference in semantics that you are referring to.

Let's take pcimRuleEnables one more time as example. PCLS defines it as:
"An integer indicating whether a policy rule is administratively enabled (value=1), disabled (value=2), or enabled for debug (value=3)". In PCLS this attribute indicates the state of pcimRule, class mapped from PCIM's PolicyRule. In PCELS we use (but not redefine) this attribute preserving its its syntax and semantics to indicate the state of a pcimPolicyRule, class mapped from PCIMe's PolicyRule. Doesn't the attribute (I stress: the attribute not the class that uses it) have the same semantics in these two cases?

Regards,
Mircea.

------_=_NextPart_001_01C382B0.BD3AFB00-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Wed Sep 24 11:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23449 for ; Wed, 24 Sep 2003 11:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bxr-0004Qy-PL for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 11:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OFs3Gr017044 for policy-archive@odin.ietf.org; Wed, 24 Sep 2003 11:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Bxq-0004Pp-79; Wed, 24 Sep 2003 11:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2BxB-0004Os-OT for policy@optimus.ietf.org; Wed, 24 Sep 2003 11:53:21 -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 LAA23321 for ; Wed, 24 Sep 2003 11:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2BxA-0006ZS-00 for policy@ietf.org; Wed, 24 Sep 2003 11:53:20 -0400 Received: from mail.metasolv.com ([12.105.131.5] helo=srvmaddog.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Bx9-0006ZA-00 for policy@ietf.org; Wed, 24 Sep 2003 11:53:20 -0400 Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id ; Wed, 24 Sep 2003 10:57:26 -0500 Message-ID: From: "Pana, Mircea" To: "'David McTavish'" , "'policy@ietf.org'" Date: Wed, 24 Sep 2003 10:47:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C382B3.38AE9BF0" Subject: [Policy] reuse of rfc2307 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_01C382B3.38AE9BF0 Content-Type: text/plain; charset="iso-8859-1" David, While being in favor of LDAP schema reuse, I believe that in PCELS we can not re-use items defined by RFC2307 for two reasons: 1. different syntaxes and semantics (e.g. in rfc2307 ipServicePort is a single-values integer, while in PCELS the Port variables are associated with a list of string representations of integers or integer ranges as recommended by PCIMe) 2. the intended category for PCELS is "standards track" while rfc2307 is "experimental". However, there is nothing that stops implementations from taking advantage of both PCELS and RFC2307. Regards, Mircea. You said in an earlier message: Also, it would be nice to see some effort go into re-using existing IETF standardized LDAP "attributes", like labelledURI and ipServicePort (defined in RFC2307). I believe that interdependence on existing standards only solidifies the reason for existence of both standards. ------_=_NextPart_001_01C382B3.38AE9BF0 Content-Type: text/html; charset="iso-8859-1" RE: [Policy] PCLS classes deprecated in PCELS
David,
 
While being in favor of LDAP schema reuse, I believe that in PCELS we can not re-use items defined by RFC2307 for two reasons:
1. different syntaxes and semantics
(e.g. in rfc2307 ipServicePort is a single-values integer, while in PCELS the Port variables are associated with a list of string representations of integers or integer ranges as recommended by PCIMe)
2. the intended category for PCELS is "standards track" while rfc2307 is "experimental".
 
However, there is nothing that stops implementations from taking advantage of both PCELS and RFC2307.
 
Regards,
Mircea.
You said in an earlier message:
Also, it would be nice to see some effort go into re-using existing IETF standardized LDAP "attributes", like labelledURI and ipServicePort (defined in RFC2307). I believe that interdependence on existing standards only solidifies the reason for existence of both standards.
 
 
------_=_NextPart_001_01C382B3.38AE9BF0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 26 18:26:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27225 for ; Fri, 26 Sep 2003 18:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312O-0005oi-81 for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QMQ8Sn022324 for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312H-0005nA-KS; Fri, 26 Sep 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rK7-0002oC-GU for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:51:39 -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 NAA27335; Tue, 23 Sep 2003 13:51:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rK4-00046K-00; Tue, 23 Sep 2003 13:51:36 -0400 Received: from cosium01.intelliden.net ([12.41.186.248]) by ietf-mx with esmtp (Exim 4.12) id 1A1rK3-00045f-00; Tue, 23 Sep 2003 13:51:35 -0400 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 11:51:02 -0600 Message-ID: From: John Strassner To: "'Robert Moore'" , "'David McTavish'" Cc: "'Wijnen, Bert (Bert)'" , "'David McTavish'" , "'Joel M. Halpern'" , John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" , "'policy-admin@ietf.org'" Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 11:51:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C381FB.40AF98D0" 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_01C381FB.40AF98D0 Content-Type: text/plain I'm saying: 1) that an information model should not be driven by the concerns of a single data model, and 2) I do not believe that the word "reuse" applies when an attribute is defined in one class, with one set of semantics, and then is blopped into a new class with completely different semantics. That is what I meant by stealing an OID. 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 > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: Tuesday, September 23, 2003 11:40 AM > To: David McTavish > Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John > Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org > Subject: RE: [Policy] RE: PCELS position > > > > > > David, > > Yes, that's exactly what I was saying. What I don't understand is > this: if > LDAP attributes are globally unique, what's the problem with > reusing them > in multiple classes (with the same syntax and semantics, of > course)? This > was a desirable thing in CMIP, but John is suggesting that it's to > be > avoided in LDAP. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > David McTavish > Moore/Raleigh/IBM@IBMUS, John Strassner > ne.com> > > cc: "'Wijnen, > Bert (Bert)'" , David McTavish > 09/23/2003 01:33 > , "'Joel M. Halpern'" > , John Strassner > PM > , "'Pana, Mircea'" > , > "'policy@ietf.org'" > , policy-admin@ietf.org > Subject: RE: > [Policy] RE: PCELS position > > > > > > Hi Bob, > Unfortunately, in LDAP, attributes must be globally unique. So, if > an > attribute is defined as "foo" in one objectclass as a boolean, and > as an > integer in another class, this causes an incompatibility. In some > cases > (OpenLDAP), this prevents the server from even starting. It's not > the most > elegant implementation, but something you get used to when working > on LDAP. > > Hope this is informational, > d. > > > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: Tuesday, September 23, 2003 1:26 PM > To: John Strassner > Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; > John > Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org > Subject: RE: [Policy] RE: PCELS position > > > > > > > >Furthermore, the argument that you are "reusing" an attribute foo > in a new > class bar is completely specious, because the new class >bar is > different > than the original class baz that defined foo. The differences are > very > fundamental - different hierarchies, different >attributes, and > worse > (e.g., the definition of priority). This isn't reuse, this is > simply > stealing an OID. > > John, I'll have to say that I'm missing the essence of your > argument here. > Formally (as you've acknowledged), LDAP falls into the same > category as > X.500 and CMIP: attributes are defined, and maintain their > identity, > independent of the classes in which they appear. (Digression for > those who > haven't worked in the DMTF: CIM works the opposite way -- an > attribute's > identity is tied to the class in which it is defined, so that it's > possible > to have two attributes with identical names defined in two > different CIM > classes. This is, of course, a potential source of confusion, so > there > were DMTF guidelines saying "Don't do this." But these provided an > artificial overlay of global scope on attributes whose identity was > inherently scoped by the classes that defined them.) I don't have > specific > experience with X.500 and LDAP, but I do know that in the CMIP case > it was > perfectly good practice (in fact, it was typical) to define > attributes > without regard to the classes that would include them. I'm don't > see why > X.500 and LDAP should be any different. But your use of the > wording "... > the original class baz that defined foo" suggests that you see some > non-formal, but nevertheless significant sense in which LDAP > attributes > *are* defined relative to the (first?) class that contains them. > > Regards, > Bob > > Bob Moore > WebSphere Advanced Design and Technology > WebSphere Platform System House > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > > > John Strassner > > Mircea'" > , "'Wijnen, Bert (Bert)'" > lliden.com> > , > "'David McTavish'" , "'policy@ietf.org'" > Sent by: > > > policy-admin@ietf.or cc: John > Strassner > , "'Joel M. Halpern'" > g > > > Subject: RE: > [Policy] > RE: > PCELS position > > > 09/23/2003 01:03 PM > > > > > > > > Again, you are trying to determine the validity of an information > model > based on the concerns of one specific data model. This is > backwards. > > Furthermore, the argument that you are "reusing" an attribute foo > in a new > class bar is completely specious, because the new class bar is > different > than the original class baz that defined foo. The differences are > very > fundamental - different hierarchies, different attributes, and > worse (e.g., > the definition of priority). This isn't reuse, this is simply > stealing an > OID. > > So, how about defining a NEW set of classes and attributes? And if > you > prefixes the new classes and attributes, this would also get around > the > schema problem that I stated earlier. > > > > 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 > -----Original Message----- > From: Pana, Mircea [mailto:mpana@metasolv.com] > Sent: Monday, September 22, 2003 8:21 AM > To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; > 'policy@ietf.org' > Cc: 'John Strassner'; 'Joel M. Halpern' > Subject: RE: [Policy] RE: PCELS position > > > > Maybe there is no need for such drastic measures. Maybe it is only > a matter > of interpretation of the PCIMe recommendations. After all PCIMe is > quite > lenient wrt. that is and what is not used in submodels (see PCIMe > section > 5.10.). > > > Some of the structural changes proposed by PCIMe make it difficult > for > PCELS to be interoperable with PCLS. These are as follows: > > > 1. PCIMe defines a new abstract class, PolicySet, and makes it a > superclass > of the already defined PolicyRule and PolicyGroup > > > 2. In PCIMe the PolicyRule.Priority property has been deprecated in > favor > of a new relative priority mechanism. > 3. PolicyRepository is deprecated in favor of the new > ReusablePolicyContainer. > > PCELS could be interoperable with PCLS if it was to interpret these > PCIMe > changes as follows: > A. there is no need to have an explicit LDAP mapping of the > abstract > PolicySet. (see also B.) > B. there is no need to have an explicit LDAP mapping of the > modified > PolicyGroup. Implementations can use (the equivalent of) a > PolicyRule with > no Actions or Conditions for PolicyGroup objects. > > > C. implementations SHOULD (as opposed to MUST) use the relative > priority > mechanism instead of the absolute priority attribute of PolicyRule > > > D. PolicyRepository SHOULD not be used directly but it is > acceptable for > instances of this class to occur through inheritance. > > > So, the question is whether the statements A. through D. violate > PCIMe or > not. Opinions? > > > Thanks, > Mircea. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, September 21, 2003 6:14 AM > To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' > Cc: 'John Strassner'; 'Joel M. Halpern' > Subject: RE: [Policy] RE: PCELS position > > > > W.r.t. > > 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? > > > PCIMe is at Proposed Standard. If, for example because of this > effort to > try and MAP it onto LDAP, we > find that we did some things in PCIMe that we should not have done, > then, > with WG consensus, > we can make incompatible changes to PCIMe and then recycle at > Proposed > Standard. > That is part of the normal standars track process. That is, we get > something to PS, then we start > using/implementing (the "using" part is reusing PCIMe definitions > in otehr > CIM docs (like the > other docs we did in Policy, and like the IPsec work, the > "implementing" is > sort of mapping onto for > example LDAP I think)... and if we find major issues, then we fix > and > recycle at PS. If we do not > find major issues, we may advance to DS. > > > Hope this helps. > Bert > > ------_=_NextPart_001_01C381FB.40AF98D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Policy] RE: PCELS position

I'm saying:

  1) that an information model should not be = driven by the
     concerns of a single data = model, and
  2) I do not believe that the word = "reuse" applies when an
     attribute is defined in one = class, with one set of
     semantics, and then is = blopped into a new class with
     completely different = semantics. That is what I meant
     by stealing an OID.

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


> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]=
> Sent: Tuesday, September 23, 2003 11:40 = AM
> To: David McTavish
> Cc: 'Wijnen, Bert (Bert)'; David McTavish; = 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; 'policy@ietf.org'; = policy-admin@ietf.org
> Subject: RE: [Policy] RE: PCELS position
>
>
>
>
>
> David,
>
> Yes, that's exactly what I was saying.  = What I don't understand is
> this: if
> LDAP attributes are globally unique, what's the = problem with
> reusing them
> in multiple classes (with the same syntax and = semantics, of
> course)?  This
> was a desirable thing in CMIP, but John is = suggesting that it's to
> be
> avoided in LDAP.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>
>          = ;            = ; David McTavish
>          = ;            = ; <dmctavish@sandvi        = To:       Robert
> Moore/Raleigh/IBM@IBMUS, John Strassner
>          = ;            = ; ne.com>
> <John.Strassner@intelliden.com>
>          = ;            = ;            = ;            = ;  cc:       "'Wijnen,
> Bert (Bert)'" <bwijnen@lucent.com>, = David McTavish
>          = ;            = ; 09/23/2003 01:33
> <dmctavish@sandvine.com>, "'Joel M. = Halpern'"
> <joel@stevecrocker.com>, John = Strassner
>          = ;            = ; PM
> <John.Strassner@intelliden.com>, = "'Pana, Mircea'"
> <mpana@metasolv.com>,
>          = ;            = ;            = ;            = ;   "'policy@ietf.org'"
> <policy@ietf.org>, = policy-admin@ietf.org
>          = ;            = ;            = ;            = ;  Subject:  RE:
> [Policy] RE: PCELS position
>
>
>
>
>
> Hi Bob,
> Unfortunately, in LDAP, attributes must be = globally unique. So, if
> an
> attribute is defined as "foo" in one = objectclass as a boolean, and
> as an
> integer in another class, this causes an = incompatibility. In some
> cases
> (OpenLDAP), this prevents the server from even = starting. It's not
> the most
> elegant implementation, but something you get = used to when working
> on LDAP.
>
> Hope this is informational,
> d.
>
>
> -----Original Message-----
> From: Robert Moore [mailto:remoore@us.ibm.com]=
> Sent: Tuesday, September 23, 2003 1:26 = PM
> To: John Strassner
> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; = 'Joel M. Halpern';
> John
> Strassner; 'Pana, Mircea'; 'policy@ietf.org'; = policy-admin@ietf.org
> Subject: RE: [Policy] RE: PCELS position
>
>
>
>
>
>
> >Furthermore, the argument that you are = "reusing" an attribute foo
> in a new
> class bar is completely specious, because the = new class >bar is
> different
> than the original class baz that defined foo. = The differences are
> very
> fundamental - different hierarchies, different = >attributes, and
> worse
> (e.g., the definition of priority). This isn't = reuse, this is
> simply
> stealing an OID.
>
> John, I'll have to say that I'm missing the = essence of your
> argument here.
> Formally (as you've acknowledged), LDAP falls = into the same
> category as
> X.500 and CMIP: attributes are defined, and = maintain their
> identity,
> independent of the classes in which they = appear.  (Digression for
> those who
> haven't worked in the DMTF: CIM works the = opposite way -- an
> attribute's
> identity is tied to the class in which it is = defined, so that it's
> possible
> to have two attributes with identical names = defined in two
> different CIM
> classes.  This is, of course, a potential = source of confusion, so
> there
> were DMTF guidelines saying "Don't do = this."  But these provided an
> artificial overlay of global scope on = attributes whose identity was
> inherently scoped by the classes that defined = them.)  I don't have
> specific
> experience with X.500 and LDAP, but I do know = that in the CMIP case
> it was
> perfectly good practice (in fact, it was = typical) to define
> attributes
> without regard to the classes that would = include them.  I'm don't
> see why
> X.500 and LDAP should be any different.  = But your use of the
> wording "...
> the original class baz that defined foo" = suggests that you see some
> non-formal, but nevertheless significant sense = in which LDAP
> attributes
> *are* defined relative to the (first?) class = that contains them.
>
> Regards,
> Bob
>
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>
>
>          = ;            = ; John Strassner
>
>          = ;            = ; <John.Strassner@inte        = To:       "'Pana,
> Mircea'"
> <mpana@metasolv.com>, "'Wijnen, Bert = (Bert)'"
>          = ;            = ; lliden.com>
> <bwijnen@lucent.com>,
> "'David McTavish'" = <dmctavish@sandvine.com>, "'policy@ietf.org'"
>          = ;            = ; Sent by:
> <policy@ietf.org>
>
>          = ;            = ; policy-admin@ietf.or        = cc:       John
> Strassner
> <John.Strassner@intelliden.com>, = "'Joel M. Halpern'"
>          = ;            = ; g
> <joel@stevecrocker.com>
>
>          = ;            = ;            = ;            = ;     Subject:  RE:
> [Policy]
> RE:
> PCELS position
>
>
>          = ;            = ; 09/23/2003 01:03 PM
>
>
>
>
>
>
>
> Again, you are trying to determine the validity = of an information
> model
> based on the concerns of one specific data = model. This is
> backwards.
>
> Furthermore, the argument that you are = "reusing" an attribute foo
> in a new
> class bar is completely specious, because the = new class bar is
> different
> than the original class baz that defined foo. = The differences are
> very
> fundamental - different hierarchies, different = attributes, and
> worse (e.g.,
> the definition of priority). This isn't reuse, = this is simply
> stealing an
> OID.
>
> So, how about defining a NEW set of classes and = attributes? And if
> you
> prefixes the new classes and attributes, this = would also get around
> the
> schema problem that I stated earlier.
>
>
>
> 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
> -----Original Message-----
> From: Pana, Mircea [mailto:mpana@metasolv.com]=
> Sent: Monday, September 22, 2003 8:21 AM
> To: 'Wijnen, Bert (Bert)'; 'David McTavish'; = Pana, Mircea;
> 'policy@ietf.org'
> Cc: 'John Strassner'; 'Joel M. Halpern'
> Subject: RE: [Policy] RE: PCELS position
>
>
>
> Maybe there is no need for such drastic = measures. Maybe it is only
> a matter
> of interpretation of the PCIMe recommendations. = After all PCIMe is
> quite
> lenient wrt. that is and what is not used in = submodels (see PCIMe
> section
> 5.10.).
>
>
> Some of the structural changes proposed by = PCIMe make it difficult
> for
> PCELS to be interoperable with PCLS. These are = as follows:
>
>
> 1. PCIMe defines a new abstract class, = PolicySet, and makes it a
> superclass
> of the already defined PolicyRule and = PolicyGroup
>
>
> 2. In PCIMe the PolicyRule.Priority property = has been deprecated in
> favor
> of a new relative priority mechanism.
> 3. PolicyRepository is deprecated in favor of = the new
> ReusablePolicyContainer.
>
> PCELS could be interoperable with PCLS if it = was to interpret these
> PCIMe
> changes as follows:
> A. there is no need to have an explicit LDAP = mapping of the
> abstract
> PolicySet. (see also B.)
> B. there is no need to have an explicit LDAP = mapping of the
> modified
> PolicyGroup. Implementations can use (the = equivalent of) a
> PolicyRule with
> no Actions or Conditions for PolicyGroup = objects.
>
>
> C. implementations SHOULD (as opposed to MUST) = use the relative
> priority
> mechanism instead of the absolute priority = attribute of PolicyRule
>
>
> D. PolicyRepository SHOULD not be used directly = but it is
> acceptable for
> instances of this class to occur through = inheritance.
>
>
> So, the question is whether the statements A. = through D. violate
> PCIMe or
> not. Opinions?
>
>
> Thanks,
> Mircea.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=
> Sent: Sunday, September 21, 2003 6:14 AM
> To: 'David McTavish'; 'Pana, Mircea'; = 'policy@ietf.org'
> Cc: 'John Strassner'; 'Joel M. Halpern'
> Subject: RE: [Policy] RE: PCELS position
>
>
>
> W.r.t.
> >  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?
>
>
> PCIMe is at Proposed Standard. If, for example = because of this
> effort to
> try and MAP it onto LDAP, we
> find that we did some things in PCIMe that we = should not have done,
> then,
> with WG consensus,
> we can make incompatible changes to PCIMe and = then recycle at
> Proposed
> Standard.
> That is part of the normal standars track = process. That is, we get
> something to PS, then we start
> using/implementing (the "using" part = is reusing PCIMe definitions
> in otehr
> CIM docs (like the
> other docs we did in Policy, and like the IPsec = work, the
> "implementing" is
> sort of mapping onto for
> example LDAP I think)... and if we find major = issues, then we fix
> and
> recycle at PS. If we do not
> find major issues, we may advance to DS.
>
>
> Hope this helps.
> Bert
>
>

------_=_NextPart_001_01C381FB.40AF98D0-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 26 19:16:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27223 for ; Fri, 26 Sep 2003 18:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312O-0005oj-8H for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QMQ8w3022325 for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312I-0005nI-1n; Fri, 26 Sep 2003 18:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rRd-0003XV-7H for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:59:25 -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 NAA27767; Tue, 23 Sep 2003 13:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rRa-0004Ec-00; Tue, 23 Sep 2003 13:59:22 -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 1A1rRa-0004EY-00; Tue, 23 Sep 2003 13:59:22 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:59:19 -0400 Message-ID: From: David McTavish To: "'Robert Moore'" , David McTavish Cc: "'Wijnen, Bert (Bert)'" , David McTavish , "'Joel M. Halpern'" , John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" , policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:58:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Bob, Pardon my confusion. From my experience, re-using attributes within multiple objectclasses is a valid strategy provided that the meaning of the attribute is maintained, and is in fact encouraged by existing RFC's (for example: x500UniqueIdentifier is identified in RFC 2256, and re-used in RFC 2798 (inetOrgPerson)). Regards, d. -----Original Message----- From: Robert Moore [mailto:remoore@us.ibm.com] Sent: Tuesday, September 23, 2003 1:40 PM To: David McTavish Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position David, Yes, that's exactly what I was saying. What I don't understand is this: if LDAP attributes are globally unique, what's the problem with reusing them in multiple classes (with the same syntax and semantics, of course)? This was a desirable thing in CMIP, but John is suggesting that it's to be avoided in LDAP. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From exim@www1.ietf.org Fri Sep 26 19:16:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27224 for ; Fri, 26 Sep 2003 18:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312O-0005oW-79 for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QMQ8Pt022316 for policy-archive@odin.ietf.org; Fri, 26 Sep 2003 18:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A312H-0005n2-3P; Fri, 26 Sep 2003 18:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1r2R-0001yP-N7 for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:33:23 -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 NAA26410; Tue, 23 Sep 2003 13:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1r2P-0003o6-00; Tue, 23 Sep 2003 13:33:21 -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 1A1r2O-0003o3-00; Tue, 23 Sep 2003 13:33:20 -0400 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Sep 2003 13:33:18 -0400 Message-ID: From: David McTavish To: "'Robert Moore'" , John Strassner Cc: "'Wijnen, Bert (Bert)'" , David McTavish , "'Joel M. Halpern'" , John Strassner , "'Pana, Mircea'" , "'policy@ietf.org'" , policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position Date: Tue, 23 Sep 2003 13:33:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Hi Bob, Unfortunately, in LDAP, attributes must be globally unique. So, if an attribute is defined as "foo" in one objectclass as a boolean, and as an integer in another class, this causes an incompatibility. In some cases (OpenLDAP), this prevents the server from even starting. It's not the most elegant implementation, but something you get used to when working on LDAP. Hope this is informational, d. -----Original Message----- From: Robert Moore [mailto:remoore@us.ibm.com] Sent: Tuesday, September 23, 2003 1:26 PM To: John Strassner Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org Subject: RE: [Policy] RE: PCELS position >Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class >bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different >attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. John, I'll have to say that I'm missing the essence of your argument here. Formally (as you've acknowledged), LDAP falls into the same category as X.500 and CMIP: attributes are defined, and maintain their identity, independent of the classes in which they appear. (Digression for those who haven't worked in the DMTF: CIM works the opposite way -- an attribute's identity is tied to the class in which it is defined, so that it's possible to have two attributes with identical names defined in two different CIM classes. This is, of course, a potential source of confusion, so there were DMTF guidelines saying "Don't do this." But these provided an artificial overlay of global scope on attributes whose identity was inherently scoped by the classes that defined them.) I don't have specific experience with X.500 and LDAP, but I do know that in the CMIP case it was perfectly good practice (in fact, it was typical) to define attributes without regard to the classes that would include them. I'm don't see why X.500 and LDAP should be any different. But your use of the wording "... the original class baz that defined foo" suggests that you see some non-formal, but nevertheless significant sense in which LDAP attributes *are* defined relative to the (first?) class that contains them. Regards, Bob Bob Moore WebSphere Advanced Design and Technology WebSphere Platform System House IBM Software Group +1-919-254-4436 remoore@us.ibm.com John Strassner , "'Wijnen, Bert (Bert)'" lliden.com> , "'David McTavish'" , "'policy@ietf.org'" Sent by: policy-admin@ietf.or cc: John Strassner , "'Joel M. Halpern'" g Subject: RE: [Policy] RE: PCELS position 09/23/2003 01:03 PM Again, you are trying to determine the validity of an information model based on the concerns of one specific data model. This is backwards. Furthermore, the argument that you are "reusing" an attribute foo in a new class bar is completely specious, because the new class bar is different than the original class baz that defined foo. The differences are very fundamental - different hierarchies, different attributes, and worse (e.g., the definition of priority). This isn't reuse, this is simply stealing an OID. So, how about defining a NEW set of classes and attributes? And if you prefixes the new classes and attributes, this would also get around the schema problem that I stated earlier. 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 -----Original Message----- From: Pana, Mircea [mailto:mpana@metasolv.com] Sent: Monday, September 22, 2003 8:21 AM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Maybe there is no need for such drastic measures. Maybe it is only a matter of interpretation of the PCIMe recommendations. After all PCIMe is quite lenient wrt. that is and what is not used in submodels (see PCIMe section 5.10.). Some of the structural changes proposed by PCIMe make it difficult for PCELS to be interoperable with PCLS. These are as follows: 1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass of the already defined PolicyRule and PolicyGroup 2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of a new relative priority mechanism. 3. PolicyRepository is deprecated in favor of the new ReusablePolicyContainer. PCELS could be interoperable with PCLS if it was to interpret these PCIMe changes as follows: A. there is no need to have an explicit LDAP mapping of the abstract PolicySet. (see also B.) B. there is no need to have an explicit LDAP mapping of the modified PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with no Actions or Conditions for PolicyGroup objects. C. implementations SHOULD (as opposed to MUST) use the relative priority mechanism instead of the absolute priority attribute of PolicyRule D. PolicyRepository SHOULD not be used directly but it is acceptable for instances of this class to occur through inheritance. So, the question is whether the statements A. through D. violate PCIMe or not. Opinions? Thanks, Mircea. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 6:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > 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? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy