From majordomo@raleigh.ibm.com  Fri Feb  2 17:45:36 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03440
	for <policy-archive@odin.ietf.org>; Fri, 2 Feb 2001 17:45:36 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA27894;
	Fri, 2 Feb 2001 17:37:52 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA35268;
	Fri, 2 Feb 2001 17:37:48 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50860; Fri, 2 Feb 2001 17:06:23 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42404; Fri, 2 Feb 2001 17:06:19 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA06832
	for <policy@raleigh.ibm.com>; Fri, 2 Feb 2001 17:06:19 -0500
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA35210
	for <policy@raleigh.ibm.com>; Fri, 2 Feb 2001 17:06:16 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA25657;
	Fri, 2 Feb 2001 14:05:59 -0800 (PST)
Received: from jstrassnlap ([171.69.108.130])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with SMTP id AKN03935;
	Fri, 2 Feb 2001 14:05:37 -0800 (PST)
Message-Id: <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
From: "John Strassner" <jstrassn@cisco.com>
To: "Robert Moore" <remoore@us.ibm.com>, <policy@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com>
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01
Date: Fri, 2 Feb 2001 14:09:43 -0800
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "John Strassner" <jstrassn@cisco.com>
Content-Transfer-Encoding: 7bit

Sorry for the delay, I've been out of the country. Comments
inline, look for <js>..</js>.

John
----- Original Message -----
From: "Robert Moore" <remoore@us.ibm.com>
To: <policy@raleigh.ibm.com>
Sent: Tuesday, January 30, 2001 8:01 AM
Subject: Preliminary results from PCIMe technical meeting,
1/24/01 - 1/26/01


> A subset of the PCIM, QPIM, ICIM, and MQPIM (Policy
> Framework MPLS Information Model for QoS and TE)
> authors met last week, to begin work on the PCIM
> Extensions (PCIMe) draft.  The goal was to take the
> "implementation" experience from the three submodels of
> PCIM, and determine what changes and extensions they
> suggested for the proposed-standard PCIM document
> (currently sitting in the RFC Editor's queue as
> draft-ietf-policy-core-info-model-08.txt).
>
> The following is the list of changes that we agreed to
> pursue documenting in the -00 version of the PCIMe draft.
> Rather than springing these changes cold on the WG at
> the I-D cutoff date, we'll provide a brief summary of
> them here.  This is still work in progress for the people
> who attended last week's meeting, so these formulations
> of the issues may change.  But here's a snapshot of where
> we stand right now.
>
>  The following subsections provide a very brief overview
> of the changes to PCIM being proposed in PCIMe.
>
>  2.2.1. Changes to PolicyRepository
>
>    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), it was determined that "PolicyRepository" is a bad
> name for the PCIM class representing a container of
> reusable policy elements.  Thus the class PolicyRepository
> has been replaced with the class ReusablePolicyContainer.
> To accomplish this change, it was necessary to deprecate
> the PCIM class PolicyRepository and its three
associations,
> and replace them with a new class ReusablePolicyContainer
> and new associations.

<js>
I don't agree with this change. If this was so confusing,
why has the name withstood the examination of all for over a
year in this working group? Deprecating a class and its
associations to fix a problem that has not been complained
about is a bad decision.
</js>

>    As a separate change, the definition of a
> ReusablePolicyContainer was broadened, to allow it to
> contain any reusable policy elements.  In PCIM, a
> PolicyRepository was allowed to contain only policy
> conditions and policy actions.

<js>
Huh? The definition of this class, from PCIM, is:

  "A class representing an administratively defined
   container for reusable policy-related information."

I've searched PCIM, and there is no text describing the
restriction you talk about above defined anywhere. This
*used* to be a restriction of QPIM, but that was removed a
long time ago.
</js>

>  2.2.2. Additional Associations and Additional Reusable
Elements
>
> The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule
> associations were imported from QPIM.  These associations
> make it possible to define larger "chunks" of reusable
> policy to place in a ReusablePolicyContainer.  The
> PolicyRuleInPolicyRule association also introduces new
> semantics representing the contextual implications of
> having one PolicyRule executing within the scope of
> another PolicyRule.

<js> Great </js>

>  2.2.3. CompoundPolicyConditions and CompoundPolicyActions
>
>  The concept of a CompoundPolicyCondition was imported
> into PCIMe from QPIM, and broadened to include a parallel
> CompoundPolicyAction.  In both cases the idea is to create
> reusable "chunks" of policy that can exist as named
> elements in a ReusablePolicyContainer.  The "Compound"
> classes and their associations incorporate the condition
> and action semantics that PCIM defines at the PolicyRule
> level: DNF/CNF for conditions, and ordering for actions.
>
>    Compound conditions and actions were defined to work
> with any component conditions and actions.  In other
> words, while the components may be instances,
> respectively, of SimplePolicyCondition and
> SimplePolicyAction (discussed immediately below),
> they need not be.

<js>
This seems fine. We didn't define CompoundActions in QPIM
because we didn't need them, but this does seem like a
generally useful idea.
</js>

>  2.2.4. Variables and Values
>
>    The SimplePolicyCondition / PolicyVariable /
> PolicyValue structure was imported into PCIMe from QPIM.
> A list of PCIMe-level variables was defined, as was a
> list of PCIMe-level values.  Other variables and values
> may, if necessary, be defined in submodels of PCIMe.
>
>  A corresponding SimplePolicyAction / PolicyVariable /
> PolicyValue structure was also defined.  While the
> semantics of a SimplePolicyCondition are "variable
> matches value", a SimplePolicyAction has the
> semantics "set variable to value".

<js>
This seems fine. I would recommend that you also copy the
binding between variable and value that we defined in QPIM
qosPolicySimpleCondition to SimplePolicyAction.
</js>

>  2.2.5. Packet Filtering
>
>    For packet filtering done in the context of a
> PolicyCondition, a set of PolicyVariables and
> PolicyValues were defined, corresponding to the
> fields in an IP packet header plus the most common
> Layer 2 frame header fields.  It is expected that policy
> conditions that filter on these header fields will be
> expressed in terms of CompoundPolicyConditions built up
> from SimplePolicyConditions that use these variables and
> values.
> An additional PolicyVariable, PacketDirection, was also
> defined, to indicate whether a packet being filtered is
> traveling inbound or outbound on an interface.
>
>    For packet filtering in other contexts (specifically,
> for the packet classifier filters modeled in QDDIM),
> these variables and values need not be used.  Filter
> classes derived from the CIM FilterEntryBase class
> hierarchy may still be used in these contexts.

<js>
This last sentence is misleading. One can easily define
equivalences between the FilterEntry.MatchConditionType and
the PolicyVariable classes and also between the
FilterEntry.MatchConditionValue and the PolicyValue classes.
The perception that PolicyVariables and PolicyValues somehow
break FilterEntries is just plain wrong.

Perhaps some additional wording to this effect should be
included in PCIMe. The designer can specify a filter using
either FilterEntries and/or {variable, operator, value}
triplets.
</js>

>  2.2.6. Priorities and Decision Strategies
>
> Drawing from both QPIM and ICIM, the priority property
> has been deprecated in PolicyRule, and placed instead on
> the associations PolicyRuleInPolicyGroup,
> PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
> PolicyRuleInPolicyRule. (Obvious question: would it be
> better to introduce a superclass
> PrioritizedPolicyComponent for these four associations,
> just to contain the priority property?  The answer is
> probably "yes".)  The QPIM rules for resolving relative
> priorities across nested PolicyGroups and PolicyRules
> have been incorporated into PCIMe as well.

<js>
What's the point of having a PrioritizedPolicyComponent
aggregation (these are aggregations, not associations)? This
only makes sense if there is also a
NonPrioritizedPolicyComponent aggregation. Because
eventually, someone is going to want order or some other
semantic added to one or more of these aggregations, and
then we are going to have to go through the hell of
deprecating things again. Since this is clearly an
optimization, why not wait and get some implementation
experience first?
</js>

> With the removal of the priority property from
> PolicyRule, a new modeling dependency has been
> introduced: in order to prioritize a PolicyRule
> relative to other PolicyRules, the rules must be
> placed in a PolicyGroup.

<js>
I think you missed the reusable case. Assuming that you do
add explicit text saying that you can put anything in a
PolicyRepository, then what if you have a PolicyRule that
contains two reusable PolicyRules? Here, you use the
association (not aggregation)
PolicyElementInPolicyRepository to associate any subclass of
Policy to a PolicyRepository. Therefore, if you REALLY want
to do this, you should add the
PolicyElementInPolicyRepository association, defined in
QPIM, to PCIMe.

Note that this produces a LOT of additional complexity. I'm
not sure it's a Good Thing. But the facility is there if you
want to explore it.
</js>

>    In the absence of any clear, general criterion for
> detecting policy conflicts, the PCIM restriction stating
> that priorities are relevant only in the case of
> conflicts has been removed.  In its place, a
> DecisionStrategy property has been added to PolicyGroup
> class, to allow the policy administrator to select one
> of two behaviors with respect to rule evaluation: either
> perform the actions for all PolicyRules whose
> conditions evaluate to TRUE, or perform the actions
> only for the highest-priority PolicyRule whose conditions
> evaluate to TRUE. The QPIM rules for applying decision
> strategies to a nested set of PolicyGroups and
> PolicyRules were also imported.

<js>
This begs the question, "What happens if there are multiple
PolicyRules of the same priority"? Then the DecisionStrategy
property doesn't help. So, looking at the paragraph below, I
*guess* that your answer would be that it doesn't matter
which PolicyRule executes, as long as only one executes.
This behavior is inconsistent with introducing the property
in the first place.
</js>

>    The question of whether to require unique priority
> values for the PolicyRules in a PolicyGroup was raised and
> discussed, but the decision was to allow these values to
> collide within a PolicyGroup, to indicate "don't care".
> Submodels of PCIMe are free to add the restriction that
> priority values not collide within a PolicyGroup.
>
>  2.2.7. Policy Roles
>
>    Policy roles were removed from PolicyRules (that is,
> the PolicyRoles property was deprecated there), and placed
> instead on PolicyGroups.

<js>
I object. This requires implementations to have PolicyGroups
to contain PolicyRules. This in turn only makes sense if
there is a reason to treat these PolicyRules as an atomic
unit. There may well not be such a reason. Implementations
should be able to use PolicyRules and the benefits of roles
without having to have an artificial grouping class.
</js>

>    nested PolicyGroups, any roles associated with the
> outer PolicyGroup are automatically "inherited" by the
> nested PolicyGroup. Additional roles may be added at the
> level of the nested group, but inherited roles
> cannot be canceled or overridden there.

<js>
This exacerbates the above problem. This means that I have
to two or more PolicyRules inside a PolicyGroup, but want
them to have different roles, I now have to add another
PolicyGroup for each different role that I want. This makes
the system unnecessarily complicated.
</js>

<js>
To sum up, here's why I object to both of the above
paragraphs: Grouping is for grouping, and roles are for
selecting. The two have completely different semantics, and
trying to mush them together looses those semantics.
</js>

>    It was also observed that there was no mechanism at all
> in PCIM for assigning roles to resources.  For example,
> while it was possible to associate a PolicyRule with the
> role combination "FrameRelay&&WAN", there was no way to
> indicate which interfaces had this role combination.  A
> new PolicyRole class was defined, representing the
> collection of resources associated with a particular role
> combination.  The linkage between a PolicyGroup and a set
> of resources is then represented by having an instance of
> PolicyRole that shares its name with a role combination
> value for the PolicyGroup, and is associated with the set
> of resources having that role combination.

<js>
I don't like this at all. First, you complained earlier
about the potential confusion (though the mail list had
none) between PolicyRepository the class and Policy
Repository the component. Yet it's fine to have a class
PolicyRole and a property PolicyRoles within another class?

Second, this is a bizarre form of referential integrity.
There are no semantics to enforce this in the rest of the
model. And some data stores probably couldn't enforce these
semantics anyway.

Third, hoping that someone gets the names right is a Bad
Thing, because they won't.

Fourth, from a modeling point-of-view, this should be done
by an association. Why isn't it done this way?
</js>

> If you have any comments on these proposed updates to
> PCIM, please post them to the mailing list.
>
> Regards,
> Bob
>
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> remoore@us.ibm.com




From majordomo@raleigh.ibm.com  Tue Feb  6 05:12:00 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10534
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 05:11:08 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA08056;
	Tue, 6 Feb 2001 04:37:46 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA22928;
	Tue, 6 Feb 2001 04:37:42 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47142; Tue, 6 Feb 2001 04:09:37 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33810; Tue, 6 Feb 2001 04:09:32 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA29678
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 04:09:34 -0500
Received: from web10509.mail.yahoo.com (web10509.mail.yahoo.com [216.136.172.141])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA06230
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 04:09:31 -0500
Message-Id: <20010206090932.55336.qmail@web10509.mail.yahoo.com>
Received: from [198.206.187.100] by web10509.mail.yahoo.com; Tue, 06 Feb 2001 01:09:32 PST
Date: Tue, 6 Feb 2001 01:09:32 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01
To: policy@raleigh.ibm.com
In-Reply-To: <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- John Strassner <jstrassn@cisco.com> wrote:
> This last sentence is misleading. One can easily
> define
> equivalences between the
> FilterEntry.MatchConditionType and
> the PolicyVariable classes and also between the
> FilterEntry.MatchConditionValue and the PolicyValue
> classes.
> The perception that PolicyVariables and PolicyValues
> somehow
> break FilterEntries is just plain wrong.

Can someone summarize the reasons why we will continue
to have the notion of FilterEntry in IPSP drafts. If
the reasons have been summarized in a thread, a
pointer to the thread would be sufficient.

Thanks


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/


From majordomo@raleigh.ibm.com  Tue Feb  6 05:30:56 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10717
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 05:30:56 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA31554;
	Tue, 6 Feb 2001 04:41:59 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA36046;
	Tue, 6 Feb 2001 04:37:43 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43732; Tue, 6 Feb 2001 04:01:26 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40618; Tue, 6 Feb 2001 04:01:17 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA29900
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 04:01:20 -0500
Received: from web10506.mail.yahoo.com (web10506.mail.yahoo.com [216.136.130.156])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA23720
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 04:01:16 -0500
Message-Id: <20010206090116.18269.qmail@web10506.mail.yahoo.com>
Received: from [198.206.187.100] by web10506.mail.yahoo.com; Tue, 06 Feb 2001 01:01:16 PST
Date: Tue, 6 Feb 2001 01:01:16 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: PolicyRoles in Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01
To: Robert Moore <remoore@us.ibm.com>, policy@raleigh.ibm.com
In-Reply-To: <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

Hello Bob,

I like the idea of PolicyRole being a first class
object which can be extended. I don't see why we
shouldn't go ahead and formally recognize the 3
possible roles(Admintration, Functional &
Enforcement). 

Are there any objections to this ?

Regardless of the application domain, these are basic
features of any rule or policy modeling system. These
are the points at which there needs to be a common
understanding across multiple parties reading/writing
to the policy repository.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/


From majordomo@raleigh.ibm.com  Tue Feb  6 09:59:32 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16520
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 09:59:32 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA21708;
	Tue, 6 Feb 2001 09:53:16 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA28760;
	Tue, 6 Feb 2001 09:53:10 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41534; Tue, 6 Feb 2001 09:19:44 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46892; Tue, 6 Feb 2001 09:19:40 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29542;
	Tue, 6 Feb 2001 09:19:43 -0500
Message-Id: <001a01c09047$a3d818e0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
References: <20010206090932.55336.qmail@web10509.mail.yahoo.com>
Subject: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Tue, 6 Feb 2001 09:18:12 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

Mahadevan, There has been some discussion on this list and, of course, on
the IPSP list but there's no conclusive answer as yet.  Jamie and I have
discussed this and we'll leave the IPsec Config Policy Model (ICPM, aka
ICIM) as it is for now.  The reason is primarily one of timing: the PCIMe
draft is being written right now and ICPM needs to be updated in time for
the March meeting.  We need stability in the technical content and these
kind of representation details are really secondary right now.

That said, in the long run whether we use FilterEntry or
PolicyVariable/PolicyValue pairs is tbd, but the answer will lie in how the
IPSP WG sees the trade-offs between common policy representation vs. a model
that's close to its device-level implementation.

Lee

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: <policy@raleigh.ibm.com>
Sent: Tuesday, February 06, 2001 4:09 AM
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 -
1/26/01


> --- John Strassner <jstrassn@cisco.com> wrote:
> > This last sentence is misleading. One can easily
> > define
> > equivalences between the
> > FilterEntry.MatchConditionType and
> > the PolicyVariable classes and also between the
> > FilterEntry.MatchConditionValue and the PolicyValue
> > classes.
> > The perception that PolicyVariables and PolicyValues
> > somehow
> > break FilterEntries is just plain wrong.
>
> Can someone summarize the reasons why we will continue
> to have the notion of FilterEntry in IPSP drafts. If
> the reasons have been summarized in a thread, a
> pointer to the thread would be sufficient.
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>



From majordomo@raleigh.ibm.com  Tue Feb  6 12:01:11 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22617
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 12:01:10 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA19918;
	Tue, 6 Feb 2001 11:55:13 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA21202;
	Tue, 6 Feb 2001 11:53:21 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA26424; Tue, 6 Feb 2001 11:19:23 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34084; Tue, 6 Feb 2001 11:19:19 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA32520
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 11:19:23 -0500
Message-Id: <009201c09058$5a4b9b00$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com> <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Subject: PolicyRepository (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Tue, 6 Feb 2001 11:17:50 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

John,  Thanks for your comments.  I'm breaking responses into different
threads for the different topics.  I think this one is easy.

> >  2.2.1. Changes to PolicyRepository
> >
> >    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), it was determined that "PolicyRepository" is a bad
> > name for the PCIM class representing a container of
> > reusable policy elements.  Thus the class PolicyRepository
> > has been replaced with the class ReusablePolicyContainer.
> > To accomplish this change, it was necessary to deprecate
> > the PCIM class PolicyRepository and its three
> associations,
> > and replace them with a new class ReusablePolicyContainer
> > and new associations.
>
> <js>
> I don't agree with this change. If this was so confusing,
> why has the name withstood the examination of all for over a
> year in this working group? Deprecating a class and its
> associations to fix a problem that has not been complained
> about is a bad decision.
> </js>

I don't believe the name has withstood the examination.  I've been confused
about PolicyRepository since its inception and we've talked about this
several times.  I know others are also confused (including some people in
your own company).  One suggestion has been made that we change the name of
the policy repository in the architecture drawing but that IS a policy
repository by the English use of the words whereas the PolicyRepository
class isn't a repository at all, it's an admindomain subclassed container
object for reusable policy components.  So, we concluded we ought to call it
that: ReusablePolicyContainer.  If we were going to do something dramatic
here, we'd change its superclass to a collection...but that hasn't been
proposed.

What's the harm in what we're proposing?  Well, it does necessitate
deprecating a few classes but this is the time to do that if we're going to.
PCIM is Proposed and we've been asked to reconcile PCIM and the other
drafts.  Is it essential to do this?  No, I don't think so, but I do think
we should.  If there are any implementations out there that have carved this
in stone...we'll, we're deprecating its use, we're not deleting it.

I think this is a red herring and not worth debating unless there's some
reason for concern that I don't grok.  But if someone thinks it's a critical
error to change the names of some classes in an Information Model, well, I
yield...but tell me why it's critical.  We're going to deprecate other
things in the process, so it can't be that we can't change PCIM.

> >    As a separate change, the definition of a
> > ReusablePolicyContainer was broadened, to allow it to
> > contain any reusable policy elements.  In PCIM, a
> > PolicyRepository was allowed to contain only policy
> > conditions and policy actions.
>
> <js>
> Huh? The definition of this class, from PCIM, is:
>
>   "A class representing an administratively defined
>    container for reusable policy-related information."
>
> I've searched PCIM, and there is no text describing the
> restriction you talk about above defined anywhere. This
> *used* to be a restriction of QPIM, but that was removed a
> long time ago.
> </js>

The only associations that were defined in PCIM were associations for
conditions and actions.  The broadening that Bob referred to is that we're
now explicitly extending the list in PCIMe rather than leaving it up to
derived models to do so.  Again, nothing to debate here either.

Cheers, Lee




From majordomo@raleigh.ibm.com  Tue Feb  6 12:49:18 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24912
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 12:49:18 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA38688;
	Tue, 6 Feb 2001 12:41:56 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA24356;
	Tue, 6 Feb 2001 12:41:54 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA41278; Tue, 6 Feb 2001 12:18:40 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34102; Tue, 6 Feb 2001 12:18:37 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA29496
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 12:18:41 -0500
Message-Id: <009601c09060$9341d840$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com> <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Subject: Decision Strategies (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Tue, 6 Feb 2001 12:16:42 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

John, Here are some responses to your comments on priorities and decision
strategies.  Cheers, Lee

> >  2.2.6. Priorities and Decision Strategies
> >
> > Drawing from both QPIM and ICIM, the priority property
> > has been deprecated in PolicyRule, and placed instead on
> > the associations PolicyRuleInPolicyGroup,
> > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
> > PolicyRuleInPolicyRule. (Obvious question: would it be
> > better to introduce a superclass
> > PrioritizedPolicyComponent for these four associations,
> > just to contain the priority property?  The answer is
> > probably "yes".)  The QPIM rules for resolving relative
> > priorities across nested PolicyGroups and PolicyRules
> > have been incorporated into PCIMe as well.
>
> <js>
> What's the point of having a PrioritizedPolicyComponent
> aggregation (these are aggregations, not associations)? This
> only makes sense if there is also a
> NonPrioritizedPolicyComponent aggregation. Because
> eventually, someone is going to want order or some other
> semantic added to one or more of these aggregations, and
> then we are going to have to go through the hell of
> deprecating things again. Since this is clearly an
> optimization, why not wait and get some implementation
> experience first?
> </js>

Bob was, I think, correctly hinting at re-examining some of the inheritance
hierarchy for a couple of classes.  While working on the section about
decision strategies, I found myself writing about decision strategy sets,
i.e., the abstraction for PolicyGroup and PolicyRule that contain other
policy groups and rules and have a homogeneous decision strategy.  This
abstraction is natural for the inheritance hierarchy in that a PolicySet
(pick a better name of you like) is an abstraction for PolicyGroup and
PolicyRule and it defines the PolicyDecisionStrategy property.  It would
then have the PolicySetComponent aggregation (my rename of Bob's
PrioritizedPolicyComponent) as an abstraction for the
PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, PolicyRuleInPolicyGroup
and PolicyRuleInPolicyRule aggregations wherein the Priority property is
defined.  With the complexity being added to groups and rules, this
abstraction makes it much easier to think about the concepts of decision
strategies and priorities. I've asked the other authors to render an opinion
on this suggestion but I haven't heard back yet.  Opinions from the broader
community are also welcome.

> > With the removal of the priority property from
> > PolicyRule, a new modeling dependency has been
> > introduced: in order to prioritize a PolicyRule
> > relative to other PolicyRules, the rules must be
> > placed in a PolicyGroup.
>
> <js>
> I think you missed the reusable case. Assuming that you do
> add explicit text saying that you can put anything in a
> PolicyRepository, then what if you have a PolicyRule that
> contains two reusable PolicyRules? Here, you use the
> association (not aggregation)
> PolicyElementInPolicyRepository to associate any subclass of
> Policy to a PolicyRepository. Therefore, if you REALLY want
> to do this, you should add the
> PolicyElementInPolicyRepository association, defined in
> QPIM, to PCIMe.
>
> Note that this produces a LOT of additional complexity. I'm
> not sure it's a Good Thing. But the facility is there if you
> want to explore it.
> </js>

What Bob missed in his summary was that rules can be in other rules in the
proposed rule structure.  But the essential point that rules need a context
to have priority is correct and, as a byproduct of the agreement to
deprecate the use of PolicyRule.Priority, that context is proposed to be
explicitly defined by the aggregation discussed above.
PolicyElementInPolicyRepository has nothing to do with priority...the
repository (or "ReusablePolicyContainer" or whatever we call it) does not
establish a context for priority evaluation; it's simply a container for
reusable policy components.  The context for priority is tied to the
decision strategy on a containing group or rule.  Hopefully, this will all
be clearer when I've written the section in the new draft.

> >    In the absence of any clear, general criterion for
> > detecting policy conflicts, the PCIM restriction stating
> > that priorities are relevant only in the case of
> > conflicts has been removed.  In its place, a
> > DecisionStrategy property has been added to PolicyGroup
> > class, to allow the policy administrator to select one
> > of two behaviors with respect to rule evaluation: either
> > perform the actions for all PolicyRules whose
> > conditions evaluate to TRUE, or perform the actions
> > only for the highest-priority PolicyRule whose conditions
> > evaluate to TRUE. The QPIM rules for applying decision
> > strategies to a nested set of PolicyGroups and
> > PolicyRules were also imported.
>
> <js>
> This begs the question, "What happens if there are multiple
> PolicyRules of the same priority"? Then the DecisionStrategy
> property doesn't help. So, looking at the paragraph below, I
> *guess* that your answer would be that it doesn't matter
> which PolicyRule executes, as long as only one executes.
> This behavior is inconsistent with introducing the property
> in the first place.
> </js>

Yes.  For "FirstMatching" only one rule gets executed, so if the submodel
and adminstrator decide to permit non-deterministic rules, then it up to the
implementation to decide which of the equal priority rules to execute when
more than one matches.

I don't understand how this behavior is inconsistent with the introduction
of a priority property.  I don't personally recommend that derived models
permit non-deterministic priorities, but when they do, this is the only
reasonable interpretation.  The PCIM notion that priority applies only to
conflicts has two problems: 1) it doesn't explain the "FirstMatching" use of
priority and 2) it relies on an undefined notion of "conflicting."  The
obvious conflicts (e.g., set DSCP to x and set DSCP to y are still resolved
by priority in both a FirstMatching and AllMatching strategy; either only
one gets executed or both get executed and the one evaluated last wins (an
interesting notion of priority, I admit).  Perhaps we should rename the
Priority property to EvaluationOrder?  (We discussed this as well and
decided to leave it alone, but I'm guessing we could be persuaded
otherwise.)

Again, hopefully this will all be clear when I've written the section in the
new draft.  We discussed having 3 decision strategies: FirstMatching,
AllMatching, AllNonConflictingMatching and decided to only have two...unless
someone can define the AllNonConflictingMatching strategy and the underlying
definition of "conflicting."

> >    The question of whether to require unique priority
> > values for the PolicyRules in a PolicyGroup was raised and
> > discussed, but the decision was to allow these values to
> > collide within a PolicyGroup, to indicate "don't care".
> > Submodels of PCIMe are free to add the restriction that
> > priority values not collide within a PolicyGroup.
> >




From majordomo@raleigh.ibm.com  Tue Feb  6 14:38:45 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29248
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 14:38:44 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA26138;
	Tue, 6 Feb 2001 14:31:08 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA29078;
	Tue, 6 Feb 2001 14:31:06 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40046; Tue, 6 Feb 2001 14:07:25 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40024; Tue, 6 Feb 2001 14:07:21 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA32998
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 14:07:26 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f16J7NW26418;
	Tue, 6 Feb 2001 14:07:23 -0500
Importance: Normal
Subject: Packet Filtering (Re: Preliminary results from PCIMe technical meeting, 1/24/01
 - 1/26/01)
To: <policy@raleigh.ibm.com>, johns@cisco.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OFBB76AE44.2FF5D4DA-ON852569EB.0067B982@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Tue, 6 Feb 2001 14:13:19 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/06/2001 02:07:23 PM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

John,

Here are your comments on the "Packet Filtering" section
of my PCIMe note.  My responses are below your comments.


>  2.2.5. Packet Filtering
>
>    For packet filtering done in the context of a
> PolicyCondition, a set of PolicyVariables and
> PolicyValues were defined, corresponding to the
> fields in an IP packet header plus the most common
> Layer 2 frame header fields.  It is expected that policy
> conditions that filter on these header fields will be
> expressed in terms of CompoundPolicyConditions built up
> from SimplePolicyConditions that use these variables and
> values.
> An additional PolicyVariable, PacketDirection, was also
> defined, to indicate whether a packet being filtered is
> traveling inbound or outbound on an interface.
>
>    For packet filtering in other contexts (specifically,
> for the packet classifier filters modeled in QDDIM),
> these variables and values need not be used.  Filter
> classes derived from the CIM FilterEntryBase class
> hierarchy may still be used in these contexts.

<js>
This last sentence is misleading. One can easily define
equivalences between the FilterEntry.MatchConditionType and
the PolicyVariable classes and also between the
FilterEntry.MatchConditionValue and the PolicyValue classes.
The perception that PolicyVariables and PolicyValues somehow
break FilterEntries is just plain wrong.

Perhaps some additional wording to this effect should be
included in PCIMe. The designer can specify a filter using
either FilterEntries and/or {variable, operator, value}
triplets.
</js>

I'm not sure I understand your basic point here, since
I think it's been a given all along that one can construct
equivalent filters using the two technologies.  I thought
that what people were asking us to do was simply to pick
one or the other mechanism as *the* way to represent
packet filtering for all IP-related policy models.

So, people asked us to pick one method or the other, and we
didn't quite do that.  We picked Variables&Values for
filters in Policy Conditions, but left FilterEntries as an
option for non-policy contexts like QDDIM.  This is what
we've proposed for PCIMe to say.

There's also the reality of staging, stability, and
schedules.  Even if PCIMe is going to end up saying that
Policy Conditions SHALL use Variables&Values to represent
packet filters, Lee and Jamie have elected to say that
for March, at least, ICIM is too far down the FilterEntry
path to change at this point.  So we'll have the anomaly
in ICIM of Policy Conditions that do packet filtering
using FilterEntries rather than Variables&Values.

Bottom line:  I think that your last sentence ("The
designer can specify a filter using either FilterEntries
and/or {variable, operator, value} triplets.") is
precisely what people *don't* want PCIMe to say.  Even if
we have to hedge it a little, I think they would rather
have us make a choice one way or the other.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Tue Feb  6 16:47:57 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02964
	for <policy-archive@odin.ietf.org>; Tue, 6 Feb 2001 16:47:56 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA40930;
	Tue, 6 Feb 2001 16:41:51 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA28772;
	Tue, 6 Feb 2001 16:39:32 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34960; Tue, 6 Feb 2001 16:12:37 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24968; Tue, 6 Feb 2001 16:12:34 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA03960
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 16:12:39 -0500
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA21634
	for <policy@raleigh.ibm.com>; Tue, 6 Feb 2001 16:12:35 -0500
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 6 Feb 2001 16:02:41 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <1MM3GHNS>; Tue, 6 Feb 2001 16:02:41 -0500
Message-Id: <28560036253BD41191A10000F8BCBD11841DB2@zcard00g.ca.nortel.com>
From: "Mircea Pana" <mpana@nortelnetworks.com>
To: policy <policy@raleigh.ibm.com>
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn ical 
         meeting, 1/24/01 - 1/26/01)
Date: Tue, 6 Feb 2001 16:02:25 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C09080.1B610290"
X-Orig: <mpana@americasm01.nt.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Mircea Pana" <mpana@nortelnetworks.com>

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_01C09080.1B610290
Content-Type: text/plain;
	charset="iso-8859-1"

My 2c. worth comments on Priority:

The "migration" of the Priority property from PolicyRule (in QPIM also
present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or PolicySet, or
PrioritizedPolicyComponent) changes its aspect from global to local. This,
definitely, makes it more flexible.

However, IMO, the focus should be placed on the container instead of its
components. I.e. The concept required here is a container with *sequenced*
policy components (I would call it: PolicySequence). The Priority property,
placed on the associations is just a way to implement it.

For example:
Consider a PolicyGroup with two PolicyRules as components: PR1 (higher
priority) and PR2 (lowed priority). The results of applying this PolicyGroup
to a policy target is the same in all the following cases:
- 100 (PR1) and 1 (PR2)
- 2 (PR1) and 1 (PR2)
- or "HIGH" (PR1) and "LOW" (PR2)
the only thing that matters is the sequence.

I also realize that in some cases the order is not important. In such cases
a PolicySet would be the appropriate concept.

Regards,
Mircea.



> -----Original Message-----
> From: Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> Sent: Tuesday, February 06, 2001 12:17 PM
> To: policy
> Subject: Decision Strategies (Re: Preliminary results from PCIMe
> technical meeting, 1/24/01 - 1/26/01)
> 
> 
> John, Here are some responses to your comments on priorities 
> and decision
> strategies.  Cheers, Lee
> 
> > >  2.2.6. Priorities and Decision Strategies
> > >
> > > Drawing from both QPIM and ICIM, the priority property
> > > has been deprecated in PolicyRule, and placed instead on
> > > the associations PolicyRuleInPolicyGroup,
> > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
> > > PolicyRuleInPolicyRule. (Obvious question: would it be
> > > better to introduce a superclass
> > > PrioritizedPolicyComponent for these four associations,
> > > just to contain the priority property?  The answer is
> > > probably "yes".)  The QPIM rules for resolving relative
> > > priorities across nested PolicyGroups and PolicyRules
> > > have been incorporated into PCIMe as well.
> >
> > <js>
> > What's the point of having a PrioritizedPolicyComponent
> > aggregation (these are aggregations, not associations)? This
> > only makes sense if there is also a
> > NonPrioritizedPolicyComponent aggregation. Because
> > eventually, someone is going to want order or some other
> > semantic added to one or more of these aggregations, and
> > then we are going to have to go through the hell of
> > deprecating things again. Since this is clearly an
> > optimization, why not wait and get some implementation
> > experience first?
> > </js>
> 
> Bob was, I think, correctly hinting at re-examining some of 
> the inheritance
> hierarchy for a couple of classes.  While working on the section about
> decision strategies, I found myself writing about decision 
> strategy sets,
> i.e., the abstraction for PolicyGroup and PolicyRule that 
> contain other
> policy groups and rules and have a homogeneous decision 
> strategy.  This
> abstraction is natural for the inheritance hierarchy in that 
> a PolicySet
> (pick a better name of you like) is an abstraction for PolicyGroup and
> PolicyRule and it defines the PolicyDecisionStrategy 
> property.  It would
> then have the PolicySetComponent aggregation (my rename of Bob's
> PrioritizedPolicyComponent) as an abstraction for the
> PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, 
> PolicyRuleInPolicyGroup
> and PolicyRuleInPolicyRule aggregations wherein the Priority 
> property is
> defined.  With the complexity being added to groups and rules, this
> abstraction makes it much easier to think about the concepts 
> of decision
> strategies and priorities. I've asked the other authors to 
> render an opinion
> on this suggestion but I haven't heard back yet.  Opinions 
> from the broader
> community are also welcome.
> 
> > > With the removal of the priority property from
> > > PolicyRule, a new modeling dependency has been
> > > introduced: in order to prioritize a PolicyRule
> > > relative to other PolicyRules, the rules must be
> > > placed in a PolicyGroup.
> >
> > <js>
> > I think you missed the reusable case. Assuming that you do
> > add explicit text saying that you can put anything in a
> > PolicyRepository, then what if you have a PolicyRule that
> > contains two reusable PolicyRules? Here, you use the
> > association (not aggregation)
> > PolicyElementInPolicyRepository to associate any subclass of
> > Policy to a PolicyRepository. Therefore, if you REALLY want
> > to do this, you should add the
> > PolicyElementInPolicyRepository association, defined in
> > QPIM, to PCIMe.
> >
> > Note that this produces a LOT of additional complexity. I'm
> > not sure it's a Good Thing. But the facility is there if you
> > want to explore it.
> > </js>
> 
> What Bob missed in his summary was that rules can be in other 
> rules in the
> proposed rule structure.  But the essential point that rules 
> need a context
> to have priority is correct and, as a byproduct of the agreement to
> deprecate the use of PolicyRule.Priority, that context is 
> proposed to be
> explicitly defined by the aggregation discussed above.
> PolicyElementInPolicyRepository has nothing to do with priority...the
> repository (or "ReusablePolicyContainer" or whatever we call 
> it) does not
> establish a context for priority evaluation; it's simply a 
> container for
> reusable policy components.  The context for priority is tied to the
> decision strategy on a containing group or rule.  Hopefully, 
> this will all
> be clearer when I've written the section in the new draft.
> 
> > >    In the absence of any clear, general criterion for
> > > detecting policy conflicts, the PCIM restriction stating
> > > that priorities are relevant only in the case of
> > > conflicts has been removed.  In its place, a
> > > DecisionStrategy property has been added to PolicyGroup
> > > class, to allow the policy administrator to select one
> > > of two behaviors with respect to rule evaluation: either
> > > perform the actions for all PolicyRules whose
> > > conditions evaluate to TRUE, or perform the actions
> > > only for the highest-priority PolicyRule whose conditions
> > > evaluate to TRUE. The QPIM rules for applying decision
> > > strategies to a nested set of PolicyGroups and
> > > PolicyRules were also imported.
> >
> > <js>
> > This begs the question, "What happens if there are multiple
> > PolicyRules of the same priority"? Then the DecisionStrategy
> > property doesn't help. So, looking at the paragraph below, I
> > *guess* that your answer would be that it doesn't matter
> > which PolicyRule executes, as long as only one executes.
> > This behavior is inconsistent with introducing the property
> > in the first place.
> > </js>
> 
> Yes.  For "FirstMatching" only one rule gets executed, so if 
> the submodel
> and adminstrator decide to permit non-deterministic rules, 
> then it up to the
> implementation to decide which of the equal priority rules to 
> execute when
> more than one matches.
> 
> I don't understand how this behavior is inconsistent with the 
> introduction
> of a priority property.  I don't personally recommend that 
> derived models
> permit non-deterministic priorities, but when they do, this 
> is the only
> reasonable interpretation.  The PCIM notion that priority 
> applies only to
> conflicts has two problems: 1) it doesn't explain the 
> "FirstMatching" use of
> priority and 2) it relies on an undefined notion of 
> "conflicting."  The
> obvious conflicts (e.g., set DSCP to x and set DSCP to y are 
> still resolved
> by priority in both a FirstMatching and AllMatching strategy; 
> either only
> one gets executed or both get executed and the one evaluated 
> last wins (an
> interesting notion of priority, I admit).  Perhaps we should 
> rename the
> Priority property to EvaluationOrder?  (We discussed this as well and
> decided to leave it alone, but I'm guessing we could be persuaded
> otherwise.)
> 
> Again, hopefully this will all be clear when I've written the 
> section in the
> new draft.  We discussed having 3 decision strategies: FirstMatching,
> AllMatching, AllNonConflictingMatching and decided to only 
> have two...unless
> someone can define the AllNonConflictingMatching strategy and 
> the underlying
> definition of "conflicting."
> 
> > >    The question of whether to require unique priority
> > > values for the PolicyRules in a PolicyGroup was raised and
> > > discussed, but the decision was to allow these values to
> > > collide within a PolicyGroup, to indicate "don't care".
> > > Submodels of PCIMe are free to add the restriction that
> > > priority values not collide within a PolicyGroup.
> > >
> 
> 
> 

------_=_NextPart_001_01C09080.1B610290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.19">
<TITLE>RE: Decision Strategies (Re: Preliminary results from PCIMe =
technical  meeting, 1/24/01 - 1/26/01)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>My 2c. worth comments on Priority:</FONT>
</P>

<P><FONT SIZE=3D2>The &quot;migration&quot; of the Priority property =
from PolicyRule (in QPIM also present in a gpsPolicyGroup) to the =
PolicyXXXInPolicyXXX (or PolicySet, or PrioritizedPolicyComponent) =
changes its aspect from global to local. This, definitely, makes it =
more flexible.</FONT></P>

<P><FONT SIZE=3D2>However, IMO, the focus should be placed on the =
container instead of its components. I.e. The concept required here is =
a container with *sequenced* policy components (I would call it: =
PolicySequence). The Priority property, placed on the associations is =
just a way to implement it.</FONT></P>

<P><FONT SIZE=3D2>For example:</FONT>
<BR><FONT SIZE=3D2>Consider a PolicyGroup with two PolicyRules as =
components: PR1 (higher priority) and PR2 (lowed priority). The results =
of applying this PolicyGroup to a policy target is the same in all the =
following cases:</FONT></P>

<P><FONT SIZE=3D2>- 100 (PR1) and 1 (PR2)</FONT>
<BR><FONT SIZE=3D2>- 2 (PR1) and 1 (PR2)</FONT>
<BR><FONT SIZE=3D2>- or &quot;HIGH&quot; (PR1) and &quot;LOW&quot; =
(PR2)</FONT>
<BR><FONT SIZE=3D2>the only thing that matters is the sequence.</FONT>
</P>

<P><FONT SIZE=3D2>I also realize that in some cases the order is not =
important. In such cases a PolicySet would be the appropriate =
concept.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Mircea.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Lee Rafalow [<A =
HREF=3D"mailto:rafalow@raleigh.ibm.com">mailto:rafalow@raleigh.ibm.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, February 06, 2001 12:17 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: policy</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Decision Strategies (Re: Preliminary =
results from PCIMe</FONT>
<BR><FONT SIZE=3D2>&gt; technical meeting, 1/24/01 - 1/26/01)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; John, Here are some responses to your comments =
on priorities </FONT>
<BR><FONT SIZE=3D2>&gt; and decision</FONT>
<BR><FONT SIZE=3D2>&gt; strategies.&nbsp; Cheers, Lee</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; 2.2.6. Priorities and Decision =
Strategies</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Drawing from both QPIM and ICIM, the =
priority property</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; has been deprecated in PolicyRule, =
and placed instead on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the associations =
PolicyRuleInPolicyGroup,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PolicyGroupInPolicyGroup, =
PolicyGroupInPolicyRule, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PolicyRuleInPolicyRule. (Obvious =
question: would it be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; better to introduce a =
superclass</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PrioritizedPolicyComponent for these =
four associations,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; just to contain the priority =
property?&nbsp; The answer is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; probably &quot;yes&quot;.)&nbsp; The =
QPIM rules for resolving relative</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; priorities across nested PolicyGroups =
and PolicyRules</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; have been incorporated into PCIMe as =
well.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What's the point of having a =
PrioritizedPolicyComponent</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aggregation (these are aggregations, not =
associations)? This</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; only makes sense if there is also a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; NonPrioritizedPolicyComponent aggregation. =
Because</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; eventually, someone is going to want order =
or some other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; semantic added to one or more of these =
aggregations, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; then we are going to have to go through =
the hell of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; deprecating things again. Since this is =
clearly an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; optimization, why not wait and get some =
implementation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; experience first?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bob was, I think, correctly hinting at =
re-examining some of </FONT>
<BR><FONT SIZE=3D2>&gt; the inheritance</FONT>
<BR><FONT SIZE=3D2>&gt; hierarchy for a couple of classes.&nbsp; While =
working on the section about</FONT>
<BR><FONT SIZE=3D2>&gt; decision strategies, I found myself writing =
about decision </FONT>
<BR><FONT SIZE=3D2>&gt; strategy sets,</FONT>
<BR><FONT SIZE=3D2>&gt; i.e., the abstraction for PolicyGroup and =
PolicyRule that </FONT>
<BR><FONT SIZE=3D2>&gt; contain other</FONT>
<BR><FONT SIZE=3D2>&gt; policy groups and rules and have a homogeneous =
decision </FONT>
<BR><FONT SIZE=3D2>&gt; strategy.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; abstraction is natural for the inheritance =
hierarchy in that </FONT>
<BR><FONT SIZE=3D2>&gt; a PolicySet</FONT>
<BR><FONT SIZE=3D2>&gt; (pick a better name of you like) is an =
abstraction for PolicyGroup and</FONT>
<BR><FONT SIZE=3D2>&gt; PolicyRule and it defines the =
PolicyDecisionStrategy </FONT>
<BR><FONT SIZE=3D2>&gt; property.&nbsp; It would</FONT>
<BR><FONT SIZE=3D2>&gt; then have the PolicySetComponent aggregation =
(my rename of Bob's</FONT>
<BR><FONT SIZE=3D2>&gt; PrioritizedPolicyComponent) as an abstraction =
for the</FONT>
<BR><FONT SIZE=3D2>&gt; PolicyGroupInPolicyGroup, =
PolicyGroupInPolicyRule, </FONT>
<BR><FONT SIZE=3D2>&gt; PolicyRuleInPolicyGroup</FONT>
<BR><FONT SIZE=3D2>&gt; and PolicyRuleInPolicyRule aggregations wherein =
the Priority </FONT>
<BR><FONT SIZE=3D2>&gt; property is</FONT>
<BR><FONT SIZE=3D2>&gt; defined.&nbsp; With the complexity being added =
to groups and rules, this</FONT>
<BR><FONT SIZE=3D2>&gt; abstraction makes it much easier to think about =
the concepts </FONT>
<BR><FONT SIZE=3D2>&gt; of decision</FONT>
<BR><FONT SIZE=3D2>&gt; strategies and priorities. I've asked the other =
authors to </FONT>
<BR><FONT SIZE=3D2>&gt; render an opinion</FONT>
<BR><FONT SIZE=3D2>&gt; on this suggestion but I haven't heard back =
yet.&nbsp; Opinions </FONT>
<BR><FONT SIZE=3D2>&gt; from the broader</FONT>
<BR><FONT SIZE=3D2>&gt; community are also welcome.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; With the removal of the priority =
property from</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PolicyRule, a new modeling dependency =
has been</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; introduced: in order to prioritize a =
PolicyRule</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; relative to other PolicyRules, the =
rules must be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; placed in a PolicyGroup.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I think you missed the reusable case. =
Assuming that you do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; add explicit text saying that you can put =
anything in a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PolicyRepository, then what if you have a =
PolicyRule that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; contains two reusable PolicyRules? Here, =
you use the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; association (not aggregation)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PolicyElementInPolicyRepository to =
associate any subclass of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Policy to a PolicyRepository. Therefore, =
if you REALLY want</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to do this, you should add the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PolicyElementInPolicyRepository =
association, defined in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; QPIM, to PCIMe.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Note that this produces a LOT of =
additional complexity. I'm</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; not sure it's a Good Thing. But the =
facility is there if you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; want to explore it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What Bob missed in his summary was that rules =
can be in other </FONT>
<BR><FONT SIZE=3D2>&gt; rules in the</FONT>
<BR><FONT SIZE=3D2>&gt; proposed rule structure.&nbsp; But the =
essential point that rules </FONT>
<BR><FONT SIZE=3D2>&gt; need a context</FONT>
<BR><FONT SIZE=3D2>&gt; to have priority is correct and, as a byproduct =
of the agreement to</FONT>
<BR><FONT SIZE=3D2>&gt; deprecate the use of PolicyRule.Priority, that =
context is </FONT>
<BR><FONT SIZE=3D2>&gt; proposed to be</FONT>
<BR><FONT SIZE=3D2>&gt; explicitly defined by the aggregation discussed =
above.</FONT>
<BR><FONT SIZE=3D2>&gt; PolicyElementInPolicyRepository has nothing to =
do with priority...the</FONT>
<BR><FONT SIZE=3D2>&gt; repository (or =
&quot;ReusablePolicyContainer&quot; or whatever we call </FONT>
<BR><FONT SIZE=3D2>&gt; it) does not</FONT>
<BR><FONT SIZE=3D2>&gt; establish a context for priority evaluation; =
it's simply a </FONT>
<BR><FONT SIZE=3D2>&gt; container for</FONT>
<BR><FONT SIZE=3D2>&gt; reusable policy components.&nbsp; The context =
for priority is tied to the</FONT>
<BR><FONT SIZE=3D2>&gt; decision strategy on a containing group or =
rule.&nbsp; Hopefully, </FONT>
<BR><FONT SIZE=3D2>&gt; this will all</FONT>
<BR><FONT SIZE=3D2>&gt; be clearer when I've written the section in the =
new draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; In the absence of =
any clear, general criterion for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; detecting policy conflicts, the PCIM =
restriction stating</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that priorities are relevant only in =
the case of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; conflicts has been removed.&nbsp; In =
its place, a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; DecisionStrategy property has been =
added to PolicyGroup</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; class, to allow the policy =
administrator to select one</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; of two behaviors with respect to rule =
evaluation: either</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; perform the actions for all =
PolicyRules whose</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; conditions evaluate to TRUE, or =
perform the actions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; only for the highest-priority =
PolicyRule whose conditions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; evaluate to TRUE. The QPIM rules for =
applying decision</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; strategies to a nested set of =
PolicyGroups and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PolicyRules were also =
imported.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This begs the question, &quot;What happens =
if there are multiple</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PolicyRules of the same priority&quot;? =
Then the DecisionStrategy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; property doesn't help. So, looking at the =
paragraph below, I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; *guess* that your answer would be that it =
doesn't matter</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; which PolicyRule executes, as long as only =
one executes.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This behavior is inconsistent with =
introducing the property</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the first place.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes.&nbsp; For &quot;FirstMatching&quot; only =
one rule gets executed, so if </FONT>
<BR><FONT SIZE=3D2>&gt; the submodel</FONT>
<BR><FONT SIZE=3D2>&gt; and adminstrator decide to permit =
non-deterministic rules, </FONT>
<BR><FONT SIZE=3D2>&gt; then it up to the</FONT>
<BR><FONT SIZE=3D2>&gt; implementation to decide which of the equal =
priority rules to </FONT>
<BR><FONT SIZE=3D2>&gt; execute when</FONT>
<BR><FONT SIZE=3D2>&gt; more than one matches.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't understand how this behavior is =
inconsistent with the </FONT>
<BR><FONT SIZE=3D2>&gt; introduction</FONT>
<BR><FONT SIZE=3D2>&gt; of a priority property.&nbsp; I don't =
personally recommend that </FONT>
<BR><FONT SIZE=3D2>&gt; derived models</FONT>
<BR><FONT SIZE=3D2>&gt; permit non-deterministic priorities, but when =
they do, this </FONT>
<BR><FONT SIZE=3D2>&gt; is the only</FONT>
<BR><FONT SIZE=3D2>&gt; reasonable interpretation.&nbsp; The PCIM =
notion that priority </FONT>
<BR><FONT SIZE=3D2>&gt; applies only to</FONT>
<BR><FONT SIZE=3D2>&gt; conflicts has two problems: 1) it doesn't =
explain the </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;FirstMatching&quot; use of</FONT>
<BR><FONT SIZE=3D2>&gt; priority and 2) it relies on an undefined =
notion of </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;conflicting.&quot;&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; obvious conflicts (e.g., set DSCP to x and set =
DSCP to y are </FONT>
<BR><FONT SIZE=3D2>&gt; still resolved</FONT>
<BR><FONT SIZE=3D2>&gt; by priority in both a FirstMatching and =
AllMatching strategy; </FONT>
<BR><FONT SIZE=3D2>&gt; either only</FONT>
<BR><FONT SIZE=3D2>&gt; one gets executed or both get executed and the =
one evaluated </FONT>
<BR><FONT SIZE=3D2>&gt; last wins (an</FONT>
<BR><FONT SIZE=3D2>&gt; interesting notion of priority, I admit).&nbsp; =
Perhaps we should </FONT>
<BR><FONT SIZE=3D2>&gt; rename the</FONT>
<BR><FONT SIZE=3D2>&gt; Priority property to EvaluationOrder?&nbsp; (We =
discussed this as well and</FONT>
<BR><FONT SIZE=3D2>&gt; decided to leave it alone, but I'm guessing we =
could be persuaded</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Again, hopefully this will all be clear when =
I've written the </FONT>
<BR><FONT SIZE=3D2>&gt; section in the</FONT>
<BR><FONT SIZE=3D2>&gt; new draft.&nbsp; We discussed having 3 decision =
strategies: FirstMatching,</FONT>
<BR><FONT SIZE=3D2>&gt; AllMatching, AllNonConflictingMatching and =
decided to only </FONT>
<BR><FONT SIZE=3D2>&gt; have two...unless</FONT>
<BR><FONT SIZE=3D2>&gt; someone can define the =
AllNonConflictingMatching strategy and </FONT>
<BR><FONT SIZE=3D2>&gt; the underlying</FONT>
<BR><FONT SIZE=3D2>&gt; definition of &quot;conflicting.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The question of =
whether to require unique priority</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; values for the PolicyRules in a =
PolicyGroup was raised and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; discussed, but the decision was to =
allow these values to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; collide within a PolicyGroup, to =
indicate &quot;don't care&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Submodels of PCIMe are free to add =
the restriction that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; priority values not collide within a =
PolicyGroup.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C09080.1B610290--


From majordomo@raleigh.ibm.com  Wed Feb  7 01:14:04 2001
Received: from fwns1.raleigh.ibm.com ([204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12422
	for <policy-archive@odin.ietf.org>; Wed, 7 Feb 2001 01:14:03 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA19716;
	Wed, 7 Feb 2001 01:03:51 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA04034;
	Wed, 7 Feb 2001 01:03:51 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA49586; Wed, 7 Feb 2001 00:37:29 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA42644; Wed, 7 Feb 2001 00:37:25 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA25708
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 00:37:26 -0500
Received: from web10502.mail.yahoo.com (web10502.mail.yahoo.com [216.136.130.152])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id AAA39368
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 00:37:23 -0500
Message-Id: <20010207053722.14320.qmail@web10502.mail.yahoo.com>
Received: from [198.206.187.100] by web10502.mail.yahoo.com; Tue, 06 Feb 2001 21:37:22 PST
Date: Tue, 6 Feb 2001 21:37:22 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
To: Lee Rafalow <rafalow@raleigh.ibm.com>, policy@raleigh.ibm.com
Cc: ipsec-policy@vpnc.org
In-Reply-To: <001a01c09047$a3d818e0$11312509@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Mahadevan Iyer <iyermahadevan@yahoo.com>

--- Lee Rafalow <rafalow@raleigh.ibm.com> wrote:
> That said, in the long run whether we use
> FilterEntry or
> PolicyVariable/PolicyValue pairs is tbd, but the
> answer will lie in how the
> IPSP WG sees the trade-offs between common policy
> representation vs. a model
> that's close to its device-level implementation.

What is the device-level implementation aspect that
points to FilterEntries. As far as I know IKE itself
has a notion of proxy id's(not filterentries) which at
this point are specified as IP subnets. 

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/


From majordomo@raleigh.ibm.com  Wed Feb  7 10:15:49 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01388
	for <policy-archive@odin.ietf.org>; Wed, 7 Feb 2001 10:15:49 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24900;
	Wed, 7 Feb 2001 10:00:44 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA28308;
	Wed, 7 Feb 2001 10:00:33 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA07660; Wed, 7 Feb 2001 09:34:09 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35044; Wed, 7 Feb 2001 09:34:05 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA12602;
	Wed, 7 Feb 2001 09:34:10 -0500
Message-Id: <003e01c09112$d07a78e0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
References: <20010207053722.14320.qmail@web10502.mail.yahoo.com>
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Wed, 7 Feb 2001 09:32:34 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

Mahadevan,

First, let's make sure everyone understands that the IPSP model is for a PEP
not for a PDP.  It's a device-level configuration model of an IKE service
and related stack components in a security client or security gateway; it's
not a domain policy.

Implementations vary, of course, but the notion that filter entries are
closer to a device-level policy implementation has to do with the fact that
parsing a general grammar (Variable, Operator, Value) is not the most
efficient implementation of a filter.  One of our implementations, for
example, uses the stack's 5-tuple filters to not only find the outbound SAs
but to also test the address-based conditions for the rules...it's pretty
efficient.  A parser for the VOV syntax wouldn't be implemented in that
product.

But that doesn't mean we shouldn't express the conditions in a VOV syntax in
the information model just that there are trade-offs.  It's very tempting to
try to find an algorithmic mapping from an information model to an
implementable data model.  Such a mapping for VOV won't even be close for
some implementations whereas it'll be close for Filters.  But as long as the
PIB, MIB, LDAP, et al mapping activities aren't tempted to do that, then
this concern is diminished.

Another thing to consider here is that a general grammar can specify
conditions that a PEP might not be able to parse into its limited set of
filter options.  A PDP can take a general specification of a domain-level
policy and map it to a set of device-level policies that match the
capabilities of a given PEP.  A PEP cannot be expected to handle any policy,
just the ones appropriate for it.  This concern doesn't disappear if we use
filters, but it's easier to spot the conditions that can be specified that
may not be supported.

Just a few things to consider.  Cheers, Lee

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>; <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
Sent: Wednesday, February 07, 2001 12:37 AM
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)


> --- Lee Rafalow <rafalow@raleigh.ibm.com> wrote:
> > That said, in the long run whether we use
> > FilterEntry or
> > PolicyVariable/PolicyValue pairs is tbd, but the
> > answer will lie in how the
> > IPSP WG sees the trade-offs between common policy
> > representation vs. a model
> > that's close to its device-level implementation.
>
> What is the device-level implementation aspect that
> points to FilterEntries. As far as I know IKE itself
> has a notion of proxy id's(not filterentries) which at
> this point are specified as IP subnets.
>
> Thanks
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>



From majordomo@raleigh.ibm.com  Wed Feb  7 12:25:50 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04355
	for <policy-archive@odin.ietf.org>; Wed, 7 Feb 2001 12:25:49 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA26894;
	Wed, 7 Feb 2001 12:18:21 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA22158;
	Wed, 7 Feb 2001 12:18:19 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34004; Wed, 7 Feb 2001 11:50:52 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA49094; Wed, 7 Feb 2001 11:50:47 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA34944
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 11:50:53 -0500
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA28754
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 11:50:50 -0500
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24341
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 11:50:49 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24275
	for <policy@raleigh.ibm.com>; Wed, 7 Feb 2001 11:50:47 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <D5Z8BFGK>; Wed, 7 Feb 2001 17:50:36 +0100
Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0B1D381D@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: policy@raleigh.ibm.com
Subject: Last Call: Publish draft-ops-ip-config-management-reqmnts-00.txt 
	as Informational RFC
Date: Wed, 7 Feb 2001 17:36:46 +0100 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>

Hi...

http://www.ietf.org/internet-drafts/draft-ops-ip-config-management-reqmnts-0
0.txt

I dropped the ball on this document. But I would like to get it publsihed
as an Informational RFC, so that we capture the work we did and
so that we can use it to evaluate other work when appropriate.

Anyone who has an issue with this document, pls speak up
before Feb 21 2001. You can send comments directly to me
or (preferably) to the confmgmt mailing list: confmgt@ops.ietf.org

This "Last Call" will be posted on:

   Policy FW WG
   RAP WG
   CONFMGT mailing list (discussion on THIS list pls)
   SNMPCONF WG
   OPS-AREA mailing list

Bert Wijnen


From majordomo@raleigh.ibm.com  Thu Feb  8 04:07:57 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03146
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 04:07:57 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA27764;
	Thu, 8 Feb 2001 03:48:05 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA34124;
	Thu, 8 Feb 2001 03:47:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24268; Thu, 8 Feb 2001 03:20:53 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA25406; Thu, 8 Feb 2001 03:20:41 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA36128;
	Thu, 8 Feb 2001 03:20:03 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA29682;
	Thu, 8 Feb 2001 03:19:53 -0500
Received: from yramberg-8000.cisco.com (telaviv3-dhcp17.cisco.com [144.254.93.145])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA12808;
	Thu, 8 Feb 2001 10:19:23 +0200 (IST)
Message-Id: <4.3.2.7.2.20010208100520.0271f7c0@csi-admin1.cisco.com>
X-Sender: yramberg@csi-admin1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 08 Feb 2001 10:20:03 +0200
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>, <policy@raleigh.ibm.com>
From: Yoram Ramberg <yramberg@cisco.com>
Subject: Re: PolicyRepository (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
In-Reply-To: <009201c09058$5a4b9b00$11312509@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com>
 <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Yoram Ramberg <yramberg@cisco.com>

(finally we have a thread to talk about it and I can't be blamed for 
starting it!)

I admit that I've experienced some confusion in the way we use the term 
'repository' to denote various things. Here's an attempt to organize this 
somewhat:

Policy repository: This term has been used mostly to refer to storage. It 
has been synonymous at times with the term 'policy database'.

Reusable-objects repository: This term has been used to refer to the 
classes that model the collection(s) of objects that are "reusable", i.e., 
can be managed centrally but referred to ("used") by other objects. An 
example is a reusable condition used by many rules.

Repository: Has also been used to refer to a directory (LDAP). This was 
mostly used in schema documents but sipped sometime into info model docs as 
well.

To me the first two have been confusing and required me to do a double take 
several times while reading (even text I myself had written!). In 
particular this becomes tricky when reading through text such as this (not 
a real example, just a possible one, but we have a couple of places that 
almost read like this):

"The object may be placed in the reusable-objects repository. Several 
reusable-objects repositories may exist in the policy repository. The 
administrator is free to locate the repositories anywhere within his/her 
own organization repository as long as objects associated with 
reusable-objects have access to the repositories where they 
reside.'"    Not easy, is it?

While I learned to deal with it (after all, life has presented me with 
greater challenges before and since), it would be nice to take this 
opportunity and get it cleared out once and for all.

I'll refrain from making a proposal for new terminology but I support this 
effort for the reasons explained above.

*Yoram

At 11:17 AM 2/6/01 -0500, Lee Rafalow wrote:
>John,  Thanks for your comments.  I'm breaking responses into different
>threads for the different topics.  I think this one is easy.
>
> > >  2.2.1. Changes to PolicyRepository
> > >
> > >    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), it was determined that "PolicyRepository" is a bad
> > > name for the PCIM class representing a container of
> > > reusable policy elements.  Thus the class PolicyRepository
> > > has been replaced with the class ReusablePolicyContainer.
> > > To accomplish this change, it was necessary to deprecate
> > > the PCIM class PolicyRepository and its three
> > associations,
> > > and replace them with a new class ReusablePolicyContainer
> > > and new associations.
> >
> > <js>
> > I don't agree with this change. If this was so confusing,
> > why has the name withstood the examination of all for over a
> > year in this working group? Deprecating a class and its
> > associations to fix a problem that has not been complained
> > about is a bad decision.
> > </js>
>
>I don't believe the name has withstood the examination.  I've been confused
>about PolicyRepository since its inception and we've talked about this
>several times.  I know others are also confused (including some people in
>your own company).  One suggestion has been made that we change the name of
>the policy repository in the architecture drawing but that IS a policy
>repository by the English use of the words whereas the PolicyRepository
>class isn't a repository at all, it's an admindomain subclassed container
>object for reusable policy components.  So, we concluded we ought to call it
>that: ReusablePolicyContainer.  If we were going to do something dramatic
>here, we'd change its superclass to a collection...but that hasn't been
>proposed.
>
>What's the harm in what we're proposing?  Well, it does necessitate
>deprecating a few classes but this is the time to do that if we're going to.
>PCIM is Proposed and we've been asked to reconcile PCIM and the other
>drafts.  Is it essential to do this?  No, I don't think so, but I do think
>we should.  If there are any implementations out there that have carved this
>in stone...we'll, we're deprecating its use, we're not deleting it.
>
>I think this is a red herring and not worth debating unless there's some
>reason for concern that I don't grok.  But if someone thinks it's a critical
>error to change the names of some classes in an Information Model, well, I
>yield...but tell me why it's critical.  We're going to deprecate other
>things in the process, so it can't be that we can't change PCIM.
>
> > >    As a separate change, the definition of a
> > > ReusablePolicyContainer was broadened, to allow it to
> > > contain any reusable policy elements.  In PCIM, a
> > > PolicyRepository was allowed to contain only policy
> > > conditions and policy actions.
> >
> > <js>
> > Huh? The definition of this class, from PCIM, is:
> >
> >   "A class representing an administratively defined
> >    container for reusable policy-related information."
> >
> > I've searched PCIM, and there is no text describing the
> > restriction you talk about above defined anywhere. This
> > *used* to be a restriction of QPIM, but that was removed a
> > long time ago.
> > </js>
>
>The only associations that were defined in PCIM were associations for
>conditions and actions.  The broadening that Bob referred to is that we're
>now explicitly extending the list in PCIMe rather than leaving it up to
>derived models to do so.  Again, nothing to debate here either.
>
>Cheers, Lee



From majordomo@raleigh.ibm.com  Thu Feb  8 05:18:04 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03768
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 05:18:04 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA27478;
	Thu, 8 Feb 2001 05:12:30 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA23344;
	Thu, 8 Feb 2001 03:51:26 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50666; Thu, 8 Feb 2001 01:22:55 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA29400; Thu, 8 Feb 2001 01:22:51 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA21020
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 01:22:53 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA31626
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 01:22:50 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id WAA09682;
	Wed, 7 Feb 2001 22:22:23 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (rtp-dial-1-212.cisco.com [10.83.97.212])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AKW42865;
	Wed, 7 Feb 2001 22:21:49 -0800 (PST)
Message-Id: <4.3.2.7.2.20010207111219.00b13368@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 07 Feb 2001 11:19:37 -0800
To: "Robert Moore" <remoore@us.ibm.com>
From: John Strassner <jstrassn@cisco.com>
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
Cc: <policy@raleigh.ibm.com>, johns@cisco.com
In-Reply-To: <OFBB76AE44.2FF5D4DA-ON852569EB.0067B982@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Bob,

first, I didn't think that people were asking us to pick one method. This 
is dictatorial without due cause. If one can map between the two, which you 
agreed could be done in your note, why not let people choose what method is 
most appropriate for their application? I don't think we'll ever be able to 
say that one method is better than the other, because applications will use 
these tools differently.

Furthermore, I don't understand your reasoning. First, you say that people 
want us to pick one method. Then, you say that it is perfectly acceptable 
for us to have one method in PCIMe and another method in ICIM. This 
contradicts your goal of having us pick one.

In addition, I don't understand the point of your message, unless it was to 
underscore that PCIMe didn't do what people wanted. My point was simply 
that the two mechanisms are equivalent and either could be used in a given 
application. Since that is what is happening, why can't we just document that?

John

p.s.: still waiting for responses on my other points...

At 02:13 PM 2/6/2001 -0500, Robert Moore wrote:
>John,
>
>Here are your comments on the "Packet Filtering" section
>of my PCIMe note.  My responses are below your comments.
>
>
> >  2.2.5. Packet Filtering
> >
> >    For packet filtering done in the context of a
> > PolicyCondition, a set of PolicyVariables and
> > PolicyValues were defined, corresponding to the
> > fields in an IP packet header plus the most common
> > Layer 2 frame header fields.  It is expected that policy
> > conditions that filter on these header fields will be
> > expressed in terms of CompoundPolicyConditions built up
> > from SimplePolicyConditions that use these variables and
> > values.
> > An additional PolicyVariable, PacketDirection, was also
> > defined, to indicate whether a packet being filtered is
> > traveling inbound or outbound on an interface.
> >
> >    For packet filtering in other contexts (specifically,
> > for the packet classifier filters modeled in QDDIM),
> > these variables and values need not be used.  Filter
> > classes derived from the CIM FilterEntryBase class
> > hierarchy may still be used in these contexts.
>
><js>
>This last sentence is misleading. One can easily define
>equivalences between the FilterEntry.MatchConditionType and
>the PolicyVariable classes and also between the
>FilterEntry.MatchConditionValue and the PolicyValue classes.
>The perception that PolicyVariables and PolicyValues somehow
>break FilterEntries is just plain wrong.
>
>Perhaps some additional wording to this effect should be
>included in PCIMe. The designer can specify a filter using
>either FilterEntries and/or {variable, operator, value}
>triplets.
></js>
>
>I'm not sure I understand your basic point here, since
>I think it's been a given all along that one can construct
>equivalent filters using the two technologies.  I thought
>that what people were asking us to do was simply to pick
>one or the other mechanism as *the* way to represent
>packet filtering for all IP-related policy models.
>
>So, people asked us to pick one method or the other, and we
>didn't quite do that.  We picked Variables&Values for
>filters in Policy Conditions, but left FilterEntries as an
>option for non-policy contexts like QDDIM.  This is what
>we've proposed for PCIMe to say.
>
>There's also the reality of staging, stability, and
>schedules.  Even if PCIMe is going to end up saying that
>Policy Conditions SHALL use Variables&Values to represent
>packet filters, Lee and Jamie have elected to say that
>for March, at least, ICIM is too far down the FilterEntry
>path to change at this point.  So we'll have the anomaly
>in ICIM of Policy Conditions that do packet filtering
>using FilterEntries rather than Variables&Values.
>
>Bottom line:  I think that your last sentence ("The
>designer can specify a filter using either FilterEntries
>and/or {variable, operator, value} triplets.") is
>precisely what people *don't* want PCIMe to say.  Even if
>we have to hedge it a little, I think they would rather
>have us make a choice one way or the other.
>
>Regards,
>Bob
>
>Bob Moore
>IBM Networking Software
>+1-919-254-4436
>remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Thu Feb  8 10:13:30 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09647
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 10:13:30 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA19978;
	Thu, 8 Feb 2001 09:32:43 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA30038;
	Thu, 8 Feb 2001 09:32:09 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46672; Thu, 8 Feb 2001 09:02:29 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43592; Thu, 8 Feb 2001 09:02:25 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA23504
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 09:02:30 -0500
Message-Id: <001c01c091d7$8d116ee0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
References: <4.3.2.7.2.20010207111219.00b13368@mira-sjcm-1.cisco.com>
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe  technical meeting, 1/24/01 - 1/26/01)
Date: Thu, 8 Feb 2001 09:00:51 -0500
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Content-Transfer-Encoding: 7bit

If I remember correctly, the charter on  filters was to either pick one or
explain why there are two (or more) ways to do filters.  When we got
together to discuss this topic, our collective judgment was that there are
reasons for both but that for policy conditions the VOV syntax was
preferable.  (I, personally, have some hesitations that I've outlined in
another posting, but that was the consensus.)  So, the "why" ends up being
guidance about when to use each...which is different from pick as you will.
What gets tagged as MAY, SHOULD or MUST is TBD.

As for IPCM (aka ICIM), Jamie & I discussed whether we should make the
changes and concluded that we'll postpone changes for now.  We're racing to
get it updated to so we can have a technically stable model without the
representation issues clouding the picture and we want to get input from the
IPSP WG on the representation issues as well.  The ultimate consensus needs
to be broader than just the Policy Framework WG.

IHTH.  Cheers.


----- Original Message -----
From: "John Strassner" <jstrassn@cisco.com>
To: "Robert Moore" <remoore@us.ibm.com>
Cc: <policy@raleigh.ibm.com>; <johns@cisco.com>
Sent: Wednesday, February 07, 2001 2:19 PM
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe technical
meeting, 1/24/01 - 1/26/01)


> Bob,
>
> first, I didn't think that people were asking us to pick one method. This
> is dictatorial without due cause. If one can map between the two, which
you
> agreed could be done in your note, why not let people choose what method
is
> most appropriate for their application? I don't think we'll ever be able
to
> say that one method is better than the other, because applications will
use
> these tools differently.
>
> Furthermore, I don't understand your reasoning. First, you say that people
> want us to pick one method. Then, you say that it is perfectly acceptable
> for us to have one method in PCIMe and another method in ICIM. This
> contradicts your goal of having us pick one.
>
> In addition, I don't understand the point of your message, unless it was
to
> underscore that PCIMe didn't do what people wanted. My point was simply
> that the two mechanisms are equivalent and either could be used in a given
> application. Since that is what is happening, why can't we just document
that?
>
> John
>
> p.s.: still waiting for responses on my other points...
>
snip...



From majordomo@raleigh.ibm.com  Thu Feb  8 11:09:36 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11704
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 11:09:36 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA32494;
	Thu, 8 Feb 2001 10:56:48 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA33622;
	Thu, 8 Feb 2001 10:56:39 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA38176; Thu, 8 Feb 2001 10:26:17 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24848; Thu, 8 Feb 2001 10:26:13 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA22618;
	Thu, 8 Feb 2001 10:26:18 -0500
Received: from longmail2.lboard.com ([63.109.116.89])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA12232;
	Thu, 8 Feb 2001 10:26:16 -0500
Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21)
	id <1P56B56N>; Thu, 8 Feb 2001 10:26:15 -0500
Message-Id: <F2F760C942EBD411B98800A0CC733FCF064F87@longmail2.lboard.com>
From: Ed Ellesson <eellesson@lboard.com>
To: "'Yoram Ramberg'" <yramberg@cisco.com>,
        Lee Rafalow
	 <rafalow@raleigh.ibm.com>, policy@raleigh.ibm.com
Subject: RE: PolicyRepository (Re: Preliminary results from PCIMe technica
	l meeting, 1/24/01 - 1/26/01)
Date: Thu, 8 Feb 2001 10:26:14 -0500 
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ed Ellesson <eellesson@lboard.com>

Hi, everyone,  

I'm still breathing, re-surfacing at my new job, with a start-up, and with a
new email address.  Sorry for the absence from interaction with the list.  I
was at the PCIMe technical meeting, week before last, and then was at the
Policy 2001 workshop in Bristol, UK last week.  

With regard to our conflicting use of the term "repository":

As co-chair, I want to see a consensus that resolves the confusion that
current and future users of the model have and will have, with regard to our
conflicting fuse of the term "repository", albeit in different contexts: the
PCIM and PCIMe documents, and the Policy Framework (four-box picture)
document.  I have to agree with Yoram R. that our use of the term
"repository" has been very confusing.  It causes extreme confusion with
people who are new to the model, and it even causes confusion with people
who have been working with it for some time, when they try to relate it to
the four box framework.  What brought this issue to a head, in the PCIMe
technical meeting two weeks ago, is that this conflict  made it hard to even
talk about, and think about, the technical problems we were dealing with,
since we had to continually qualify the context, every time we opened our
mouths.    

<Begin, as contributor>

As a contributor, I have a personal opinion that agrees with Bob, I think,
and that is I would prefer to change the term in the Policy Model, since we
are making other deprecatory changes there anyway.  If there were no other
deprecations to to the model to be made, then I would favor changing the
name in the four box picture.    

The reason, in my opinion, that we did not change it before this, is that
when we were focused on PCIM and QPIM,  the issue of confusion with the term
"Policy Repository" in the four box picture did not come up, because we were
not focused on the four box picture at all then.  But as soon as we start
talking about the model in the context of the four box framework, we get
ourselves all tangled up again, just as Yoram explained in his note.  

If this was the only change we had to make that involved deprecating
something in PCIM, I would agree that it would make more sense to change the
name in the four box architecture picture to remove the confusion, since
that document needs a lot of revision work anyway, before it goes to
informational rfc.  (In fact, it was my suggestion to consider this option,
that Bob referred to in his note.)  

However, since we have to make some deprecation changes to PCIM anyway, I
would favor making the change to the name of the class in the model, since I
believe new people coming to the model will more intuitively understand the
use of "repository" in the four-box framework context, than in the context
of the model.  

This is just my two cents (or less) as a contributor.  

<End, as contributor>

As co-chair, I am seeking consensus, and will, of course, accept whatever
the sense of the working group turns out to be.  To that end, I would like
to see more comments on this issue from the authors and other contributors,
and from the other members of the mailing list, as well as the AD's, if they
have an opinion regarding changing/deprecating something that we have
already  so recently sent to proposed standard.  In that sense, this project
becomes something of a "PCIM-bis", similar to other working groups who have
gone through iteration of their standards with implementation experience.

Looking for more comments, positions, etc.

Ed Ellesson
LongBoard, Inc. 
eellesson@lboard.com
919-361-3230

 -----Original Message-----
From: 	Yoram Ramberg [mailto:yramberg@cisco.com] 
Sent:	Thursday, February 08, 2001 3:20 AM
To:	Lee Rafalow; policy@raleigh.ibm.com
Subject:	Re: PolicyRepository (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)

(finally we have a thread to talk about it and I can't be blamed for 
starting it!)

I admit that I've experienced some confusion in the way we use the term 
'repository' to denote various things. Here's an attempt to organize this 
somewhat:

Policy repository: This term has been used mostly to refer to storage. It 
has been synonymous at times with the term 'policy database'.

Reusable-objects repository: This term has been used to refer to the 
classes that model the collection(s) of objects that are "reusable", i.e., 
can be managed centrally but referred to ("used") by other objects. An 
example is a reusable condition used by many rules.

Repository: Has also been used to refer to a directory (LDAP). This was 
mostly used in schema documents but sipped sometime into info model docs as 
well.

To me the first two have been confusing and required me to do a double take 
several times while reading (even text I myself had written!). In 
particular this becomes tricky when reading through text such as this (not 
a real example, just a possible one, but we have a couple of places that 
almost read like this):

"The object may be placed in the reusable-objects repository. Several 
reusable-objects repositories may exist in the policy repository. The 
administrator is free to locate the repositories anywhere within his/her 
own organization repository as long as objects associated with 
reusable-objects have access to the repositories where they 
reside.'"    Not easy, is it?

While I learned to deal with it (after all, life has presented me with 
greater challenges before and since), it would be nice to take this 
opportunity and get it cleared out once and for all.

I'll refrain from making a proposal for new terminology but I support this 
effort for the reasons explained above.

*Yoram

At 11:17 AM 2/6/01 -0500, Lee Rafalow wrote:
>John,  Thanks for your comments.  I'm breaking responses into different
>threads for the different topics.  I think this one is easy.
>
> > >  2.2.1. Changes to PolicyRepository
> > >
> > >    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), it was determined that "PolicyRepository" is a bad
> > > name for the PCIM class representing a container of
> > > reusable policy elements.  Thus the class PolicyRepository
> > > has been replaced with the class ReusablePolicyContainer.
> > > To accomplish this change, it was necessary to deprecate
> > > the PCIM class PolicyRepository and its three
> > associations,
> > > and replace them with a new class ReusablePolicyContainer
> > > and new associations.
> >
> > <js>
> > I don't agree with this change. If this was so confusing,
> > why has the name withstood the examination of all for over a
> > year in this working group? Deprecating a class and its
> > associations to fix a problem that has not been complained
> > about is a bad decision.
> > </js>
>
>I don't believe the name has withstood the examination.  I've been confused
>about PolicyRepository since its inception and we've talked about this
>several times.  I know others are also confused (including some people in
>your own company).  One suggestion has been made that we change the name of
>the policy repository in the architecture drawing but that IS a policy
>repository by the English use of the words whereas the PolicyRepository
>class isn't a repository at all, it's an admindomain subclassed container
>object for reusable policy components.  So, we concluded we ought to call
it
>that: ReusablePolicyContainer.  If we were going to do something dramatic
>here, we'd change its superclass to a collection...but that hasn't been
>proposed.
>
>What's the harm in what we're proposing?  Well, it does necessitate
>deprecating a few classes but this is the time to do that if we're going
to.
>PCIM is Proposed and we've been asked to reconcile PCIM and the other
>drafts.  Is it essential to do this?  No, I don't think so, but I do think
>we should.  If there are any implementations out there that have carved
this
>in stone...we'll, we're deprecating its use, we're not deleting it.
>
>I think this is a red herring and not worth debating unless there's some
>reason for concern that I don't grok.  But if someone thinks it's a
critical
>error to change the names of some classes in an Information Model, well, I
>yield...but tell me why it's critical.  We're going to deprecate other
>things in the process, so it can't be that we can't change PCIM.
>
> > >    As a separate change, the definition of a
> > > ReusablePolicyContainer was broadened, to allow it to
> > > contain any reusable policy elements.  In PCIM, a
> > > PolicyRepository was allowed to contain only policy
> > > conditions and policy actions.
> >
> > <js>
> > Huh? The definition of this class, from PCIM, is:
> >
> >   "A class representing an administratively defined
> >    container for reusable policy-related information."
> >
> > I've searched PCIM, and there is no text describing the
> > restriction you talk about above defined anywhere. This
> > *used* to be a restriction of QPIM, but that was removed a
> > long time ago.
> > </js>
>
>The only associations that were defined in PCIM were associations for
>conditions and actions.  The broadening that Bob referred to is that we're
>now explicitly extending the list in PCIMe rather than leaving it up to
>derived models to do so.  Again, nothing to debate here either.
>
>Cheers, Lee


From majordomo@raleigh.ibm.com  Thu Feb  8 14:23:23 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17452
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 14:23:10 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA43238;
	Thu, 8 Feb 2001 14:12:16 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA25142;
	Thu, 8 Feb 2001 14:12:13 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40514; Thu, 8 Feb 2001 13:47:04 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51734; Thu, 8 Feb 2001 13:46:59 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA27056;
	Thu, 8 Feb 2001 13:47:05 -0500
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA21320;
	Thu, 8 Feb 2001 13:47:01 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA07340;
	Thu, 8 Feb 2001 10:46:45 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (sj-dial-1-184.cisco.com [171.68.179.185])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AKW50838;
	Thu, 8 Feb 2001 10:46:26 -0800 (PST)
Message-Id: <4.3.2.7.2.20010208103322.00b3eb90@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 08 Feb 2001 10:35:40 -0800
To: Ed Ellesson <eellesson@lboard.com>
From: John Strassner <jstrassn@cisco.com>
Subject: RE: PolicyRepository (Re: Preliminary results from PCIMe
  technica l meeting, 1/24/01 - 1/26/01)
Cc: "'Yoram Ramberg'" <yramberg@cisco.com>,
        Lee Rafalow <rafalow@raleigh.ibm.com>, policy@raleigh.ibm.com
In-Reply-To: <F2F760C942EBD411B98800A0CC733FCF064F87@longmail2.lboard.co
 m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Hi Ed,

thanks for your note. I guess I've just been around this too long. I still 
don't see how referring to the class PolicyRepository conflicts with a data 
store, a.k.a., a policy repository. As such, I've presented my arguments as 
best I can. If others really think that this change is necessary, I'll stop 
clogging the mail lines. It just worries me that instead of extending PCIM, 
we seem to have sounded a "Hunting Season is Now Open" call instead.

regards,
John
At 10:26 AM 2/8/2001 -0500, Ed Ellesson wrote:
>Hi, everyone,
>
>I'm still breathing, re-surfacing at my new job, with a start-up, and with a
>new email address.  Sorry for the absence from interaction with the list.  I
>was at the PCIMe technical meeting, week before last, and then was at the
>Policy 2001 workshop in Bristol, UK last week.
>
>With regard to our conflicting use of the term "repository":
>
>As co-chair, I want to see a consensus that resolves the confusion that
>current and future users of the model have and will have, with regard to our
>conflicting fuse of the term "repository", albeit in different contexts: the
>PCIM and PCIMe documents, and the Policy Framework (four-box picture)
>document.  I have to agree with Yoram R. that our use of the term
>"repository" has been very confusing.  It causes extreme confusion with
>people who are new to the model, and it even causes confusion with people
>who have been working with it for some time, when they try to relate it to
>the four box framework.  What brought this issue to a head, in the PCIMe
>technical meeting two weeks ago, is that this conflict  made it hard to even
>talk about, and think about, the technical problems we were dealing with,
>since we had to continually qualify the context, every time we opened our
>mouths.
>
><Begin, as contributor>
>
>As a contributor, I have a personal opinion that agrees with Bob, I think,
>and that is I would prefer to change the term in the Policy Model, since we
>are making other deprecatory changes there anyway.  If there were no other
>deprecations to to the model to be made, then I would favor changing the
>name in the four box picture.
>
>The reason, in my opinion, that we did not change it before this, is that
>when we were focused on PCIM and QPIM,  the issue of confusion with the term
>"Policy Repository" in the four box picture did not come up, because we were
>not focused on the four box picture at all then.  But as soon as we start
>talking about the model in the context of the four box framework, we get
>ourselves all tangled up again, just as Yoram explained in his note.
>
>If this was the only change we had to make that involved deprecating
>something in PCIM, I would agree that it would make more sense to change the
>name in the four box architecture picture to remove the confusion, since
>that document needs a lot of revision work anyway, before it goes to
>informational rfc.  (In fact, it was my suggestion to consider this option,
>that Bob referred to in his note.)
>
>However, since we have to make some deprecation changes to PCIM anyway, I
>would favor making the change to the name of the class in the model, since I
>believe new people coming to the model will more intuitively understand the
>use of "repository" in the four-box framework context, than in the context
>of the model.
>
>This is just my two cents (or less) as a contributor.
>
><End, as contributor>
>
>As co-chair, I am seeking consensus, and will, of course, accept whatever
>the sense of the working group turns out to be.  To that end, I would like
>to see more comments on this issue from the authors and other contributors,
>and from the other members of the mailing list, as well as the AD's, if they
>have an opinion regarding changing/deprecating something that we have
>already  so recently sent to proposed standard.  In that sense, this project
>becomes something of a "PCIM-bis", similar to other working groups who have
>gone through iteration of their standards with implementation experience.
>
>Looking for more comments, positions, etc.
>
>Ed Ellesson
>LongBoard, Inc.
>eellesson@lboard.com
>919-361-3230
>
>  -----Original Message-----
>From:   Yoram Ramberg [mailto:yramberg@cisco.com]
>Sent:   Thursday, February 08, 2001 3:20 AM
>To:     Lee Rafalow; policy@raleigh.ibm.com
>Subject:        Re: PolicyRepository (Re: Preliminary results from PCIMe
>technical meeting, 1/24/01 - 1/26/01)
>
>(finally we have a thread to talk about it and I can't be blamed for
>starting it!)
>
>I admit that I've experienced some confusion in the way we use the term
>'repository' to denote various things. Here's an attempt to organize this
>somewhat:
>
>Policy repository: This term has been used mostly to refer to storage. It
>has been synonymous at times with the term 'policy database'.
>
>Reusable-objects repository: This term has been used to refer to the
>classes that model the collection(s) of objects that are "reusable", i.e.,
>can be managed centrally but referred to ("used") by other objects. An
>example is a reusable condition used by many rules.
>
>Repository: Has also been used to refer to a directory (LDAP). This was
>mostly used in schema documents but sipped sometime into info model docs as
>well.
>
>To me the first two have been confusing and required me to do a double take
>several times while reading (even text I myself had written!). In
>particular this becomes tricky when reading through text such as this (not
>a real example, just a possible one, but we have a couple of places that
>almost read like this):
>
>"The object may be placed in the reusable-objects repository. Several
>reusable-objects repositories may exist in the policy repository. The
>administrator is free to locate the repositories anywhere within his/her
>own organization repository as long as objects associated with
>reusable-objects have access to the repositories where they
>reside.'"    Not easy, is it?
>
>While I learned to deal with it (after all, life has presented me with
>greater challenges before and since), it would be nice to take this
>opportunity and get it cleared out once and for all.
>
>I'll refrain from making a proposal for new terminology but I support this
>effort for the reasons explained above.
>
>*Yoram
>
>At 11:17 AM 2/6/01 -0500, Lee Rafalow wrote:
> >John,  Thanks for your comments.  I'm breaking responses into different
> >threads for the different topics.  I think this one is easy.
> >
> > > >  2.2.1. Changes to PolicyRepository
> > > >
> > > >    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), it was determined that "PolicyRepository" is a bad
> > > > name for the PCIM class representing a container of
> > > > reusable policy elements.  Thus the class PolicyRepository
> > > > has been replaced with the class ReusablePolicyContainer.
> > > > To accomplish this change, it was necessary to deprecate
> > > > the PCIM class PolicyRepository and its three
> > > associations,
> > > > and replace them with a new class ReusablePolicyContainer
> > > > and new associations.
> > >
> > > <js>
> > > I don't agree with this change. If this was so confusing,
> > > why has the name withstood the examination of all for over a
> > > year in this working group? Deprecating a class and its
> > > associations to fix a problem that has not been complained
> > > about is a bad decision.
> > > </js>
> >
> >I don't believe the name has withstood the examination.  I've been confused
> >about PolicyRepository since its inception and we've talked about this
> >several times.  I know others are also confused (including some people in
> >your own company).  One suggestion has been made that we change the name of
> >the policy repository in the architecture drawing but that IS a policy
> >repository by the English use of the words whereas the PolicyRepository
> >class isn't a repository at all, it's an admindomain subclassed container
> >object for reusable policy components.  So, we concluded we ought to call
>it
> >that: ReusablePolicyContainer.  If we were going to do something dramatic
> >here, we'd change its superclass to a collection...but that hasn't been
> >proposed.
> >
> >What's the harm in what we're proposing?  Well, it does necessitate
> >deprecating a few classes but this is the time to do that if we're going
>to.
> >PCIM is Proposed and we've been asked to reconcile PCIM and the other
> >drafts.  Is it essential to do this?  No, I don't think so, but I do think
> >we should.  If there are any implementations out there that have carved
>this
> >in stone...we'll, we're deprecating its use, we're not deleting it.
> >
> >I think this is a red herring and not worth debating unless there's some
> >reason for concern that I don't grok.  But if someone thinks it's a
>critical
> >error to change the names of some classes in an Information Model, well, I
> >yield...but tell me why it's critical.  We're going to deprecate other
> >things in the process, so it can't be that we can't change PCIM.
> >
> > > >    As a separate change, the definition of a
> > > > ReusablePolicyContainer was broadened, to allow it to
> > > > contain any reusable policy elements.  In PCIM, a
> > > > PolicyRepository was allowed to contain only policy
> > > > conditions and policy actions.
> > >
> > > <js>
> > > Huh? The definition of this class, from PCIM, is:
> > >
> > >   "A class representing an administratively defined
> > >    container for reusable policy-related information."
> > >
> > > I've searched PCIM, and there is no text describing the
> > > restriction you talk about above defined anywhere. This
> > > *used* to be a restriction of QPIM, but that was removed a
> > > long time ago.
> > > </js>
> >
> >The only associations that were defined in PCIM were associations for
> >conditions and actions.  The broadening that Bob referred to is that we're
> >now explicitly extending the list in PCIMe rather than leaving it up to
> >derived models to do so.  Again, nothing to debate here either.
> >
> >Cheers, Lee



From majordomo@raleigh.ibm.com  Thu Feb  8 14:24:48 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17492
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 14:24:46 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA07622;
	Thu, 8 Feb 2001 14:12:12 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA29756;
	Thu, 8 Feb 2001 14:12:10 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52484; Thu, 8 Feb 2001 13:46:58 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51914; Thu, 8 Feb 2001 13:46:52 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA35736;
	Thu, 8 Feb 2001 13:46:58 -0500
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA39064;
	Thu, 8 Feb 2001 13:46:56 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA06854;
	Thu, 8 Feb 2001 10:46:42 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (sj-dial-1-184.cisco.com [171.68.179.185])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AKW50836;
	Thu, 8 Feb 2001 10:46:23 -0800 (PST)
Message-Id: <4.3.2.7.2.20010208101601.00b31bf8@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 08 Feb 2001 10:30:22 -0800
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
From: John Strassner <jstrassn@cisco.com>
Subject: Re: PolicyRepository (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
Cc: <policy@raleigh.ibm.com>
In-Reply-To: <009201c09058$5a4b9b00$11312509@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com>
 <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Hi Lee,

thanks for the response, comments inline using <js2>..</js2>

regards,
John

At 11:17 AM 2/6/2001 -0500, Lee Rafalow wrote:
>John,  Thanks for your comments.  I'm breaking responses into different
>threads for the different topics.  I think this one is easy.
>
> > >  2.2.1. Changes to PolicyRepository
> > >
> > >    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), it was determined that "PolicyRepository" is a bad
> > > name for the PCIM class representing a container of
> > > reusable policy elements.  Thus the class PolicyRepository
> > > has been replaced with the class ReusablePolicyContainer.
> > > To accomplish this change, it was necessary to deprecate
> > > the PCIM class PolicyRepository and its three
> > associations,
> > > and replace them with a new class ReusablePolicyContainer
> > > and new associations.
> >
> > <js>
> > I don't agree with this change. If this was so confusing,
> > why has the name withstood the examination of all for over a
> > year in this working group? Deprecating a class and its
> > associations to fix a problem that has not been complained
> > about is a bad decision.
> > </js>
>
>I don't believe the name has withstood the examination.  I've been confused
>about PolicyRepository since its inception and we've talked about this
>several times.  I know others are also confused (including some people in
>your own company).  One suggestion has been made that we change the name of
>the policy repository in the architecture drawing but that IS a policy
>repository by the English use of the words whereas the PolicyRepository
>class isn't a repository at all, it's an admindomain subclassed container
>object for reusable policy components.  So, we concluded we ought to call it
>that: ReusablePolicyContainer.  If we were going to do something dramatic
>here, we'd change its superclass to a collection...but that hasn't been
>proposed.

<js2>
How can you say that the name has withstood the examination? There is not 
one single message to the policy list questioning the name of this class. 
Furthermore, we could call the policy repository in the architecture 
drawing a data store, too. The PolicyRepository class IS a repository in 
how we're using it - in the QPIM text and presentations, we've emphasized 
the fact that this is a repository in a repository, specifically for 
containing reusable policy components. But my main argument is in the next 
paragraph below.
</js2>

>What's the harm in what we're proposing?  Well, it does necessitate
>deprecating a few classes but this is the time to do that if we're going to.
>PCIM is Proposed and we've been asked to reconcile PCIM and the other
>drafts.  Is it essential to do this?  No, I don't think so, but I do think
>we should.  If there are any implementations out there that have carved this
>in stone...we'll, we're deprecating its use, we're not deleting it.

<js2>
The harm is exactly what you mentioned. I feel that we are unnecessarily 
deprecating classes in an RFC in advance of implementation. We have product 
that uses this class, and we've had no problems in distinguishing the class 
from the data store. ;-)
</js2>

>I think this is a red herring and not worth debating unless there's some
>reason for concern that I don't grok.  But if someone thinks it's a critical
>error to change the names of some classes in an Information Model, well, I
>yield...but tell me why it's critical.  We're going to deprecate other
>things in the process, so it can't be that we can't change PCIM.

<js2>
You're right, there's no rule saying that we can't deprecate things. But I 
would hope that we do deprecate things with caution, and based on 
implementation experience. I don't see either of these steps being taken 
here, and since we do have product using this, I objected.
</js2>

> > >    As a separate change, the definition of a
> > > ReusablePolicyContainer was broadened, to allow it to
> > > contain any reusable policy elements.  In PCIM, a
> > > PolicyRepository was allowed to contain only policy
> > > conditions and policy actions.
> >
> > <js>
> > Huh? The definition of this class, from PCIM, is:
> >
> >   "A class representing an administratively defined
> >    container for reusable policy-related information."
> >
> > I've searched PCIM, and there is no text describing the
> > restriction you talk about above defined anywhere. This
> > *used* to be a restriction of QPIM, but that was removed a
> > long time ago.
> > </js>
>
>The only associations that were defined in PCIM were associations for
>conditions and actions.  The broadening that Bob referred to is that we're
>now explicitly extending the list in PCIMe rather than leaving it up to
>derived models to do so.  Again, nothing to debate here either.

<js2>
Again I disagree. Bob's text says:
 >>  As a separate change, the definition of a
 >> ReusablePolicyContainer was broadened, to allow it to
 >> contain any reusable policy elements. In PCIM, a
 >> PolicyRepository was allowed to contain only policy
 >> conditions and policy actions.

This clearly implies that the PolicyRepository/ReusablePolicyContainer was 
somehow limited and could not contain any reusable policy elements, but 
only a limited set. Your argument is somewhat of a red herring - while we 
only defined associations to put conditions and actions in the 
PolicyRepository, remember that the PolicyRepository came from QPIM in the 
first place. One of the first things we did in QPIM was to also define the 
storage of other policy elements in the PolicyRepository.

Put another way, we started by taking things from QPIM and putting them 
into PCIM. Now we're taking more things (but not enough, as I argue in the 
author's meetings of PCIMe) from QPIM and putting it into PCIMe. I don't 
think it does anyone any good to say that such things are new concepts, 
because they're not. They've been defined in QPIM, and now we're trying to 
generalize them.

This is why I object to the literal wording of Bob's message, and as proof 
attached the definition of what's in PCIM now. So please delete that 
statement, and I'll shut up.
</js2>

>Cheers, Lee



From majordomo@raleigh.ibm.com  Thu Feb  8 15:20:52 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18615
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 15:20:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA37656;
	Thu, 8 Feb 2001 15:14:03 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA36852;
	Thu, 8 Feb 2001 15:14:01 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46978; Thu, 8 Feb 2001 14:52:20 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA40560; Thu, 8 Feb 2001 14:52:15 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA36704
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 14:52:14 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28124
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 14:52:09 -0500
Received: from ysnirnt70 (ysnir-isdn-home.cisco.com [10.49.112.178])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id VAA29345;
	Thu, 8 Feb 2001 21:49:01 +0200 (IST)
From: "Yoram Snir" <ysnir@cisco.com>
To: "'Mircea Pana'" <mpana@nortelnetworks.com>,
        "'policy'" <policy@raleigh.ibm.com>
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn ical         meeting, 1/24/01 - 1/26/01)
Date: Thu, 8 Feb 2001 21:47:54 +0200
Message-Id: <001c01c09208$07fbccb0$b270310a@ysnirnt70>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001D_01C09218.CB849CB0"
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <28560036253BD41191A10000F8BCBD11841DB2@zcard00g.ca.nortel.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Snir" <ysnir@cisco.com>

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C09218.CB849CB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Decision Strategies (Re: Preliminary results from PCIMe technical
meeting, 1/24/01 - 1/26/01)IMO, the priority should be placed int he
association and not with the container.The obvious example for why the
association is the right place is when a policy rule is used with in 2
different policy groups. The priority is a property of the association, not
the container and not the rule (since the same rule is used by different
containers, in different sequence/ priority.
Yoram
  -----Original Message-----
  From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On
Behalf Of Mircea Pana
  Sent: Tuesday, February 06, 2001 11:02 PM
  To: policy
  Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)


  My 2c. worth comments on Priority:

  The "migration" of the Priority property from PolicyRule (in QPIM also
present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or PolicySet, or
PrioritizedPolicyComponent) changes its aspect from global to local. This,
definitely, makes it more flexible.

  However, IMO, the focus should be placed on the container instead of its
components. I.e. The concept required here is a container with *sequenced*
policy components (I would call it: PolicySequence). The Priority property,
placed on the associations is just a way to implement it.

  For example:
  Consider a PolicyGroup with two PolicyRules as components: PR1 (higher
priority) and PR2 (lowed priority). The results of applying this PolicyGroup
to a policy target is the same in all the following cases:

  - 100 (PR1) and 1 (PR2)
  - 2 (PR1) and 1 (PR2)
  - or "HIGH" (PR1) and "LOW" (PR2)
  the only thing that matters is the sequence.

  I also realize that in some cases the order is not important. In such
cases a PolicySet would be the appropriate concept.

  Regards,
  Mircea.




  > -----Original Message-----
  > From: Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
  > Sent: Tuesday, February 06, 2001 12:17 PM
  > To: policy
  > Subject: Decision Strategies (Re: Preliminary results from PCIMe
  > technical meeting, 1/24/01 - 1/26/01)
  >
  >
  > John, Here are some responses to your comments on priorities
  > and decision
  > strategies.  Cheers, Lee
  >
  > > >  2.2.6. Priorities and Decision Strategies
  > > >
  > > > Drawing from both QPIM and ICIM, the priority property
  > > > has been deprecated in PolicyRule, and placed instead on
  > > > the associations PolicyRuleInPolicyGroup,
  > > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
  > > > PolicyRuleInPolicyRule. (Obvious question: would it be
  > > > better to introduce a superclass
  > > > PrioritizedPolicyComponent for these four associations,
  > > > just to contain the priority property?  The answer is
  > > > probably "yes".)  The QPIM rules for resolving relative
  > > > priorities across nested PolicyGroups and PolicyRules
  > > > have been incorporated into PCIMe as well.
  > >
  > > <js>
  > > What's the point of having a PrioritizedPolicyComponent
  > > aggregation (these are aggregations, not associations)? This
  > > only makes sense if there is also a
  > > NonPrioritizedPolicyComponent aggregation. Because
  > > eventually, someone is going to want order or some other
  > > semantic added to one or more of these aggregations, and
  > > then we are going to have to go through the hell of
  > > deprecating things again. Since this is clearly an
  > > optimization, why not wait and get some implementation
  > > experience first?
  > > </js>
  >
  > Bob was, I think, correctly hinting at re-examining some of
  > the inheritance
  > hierarchy for a couple of classes.  While working on the section about
  > decision strategies, I found myself writing about decision
  > strategy sets,
  > i.e., the abstraction for PolicyGroup and PolicyRule that
  > contain other
  > policy groups and rules and have a homogeneous decision
  > strategy.  This
  > abstraction is natural for the inheritance hierarchy in that
  > a PolicySet
  > (pick a better name of you like) is an abstraction for PolicyGroup and
  > PolicyRule and it defines the PolicyDecisionStrategy
  > property.  It would
  > then have the PolicySetComponent aggregation (my rename of Bob's
  > PrioritizedPolicyComponent) as an abstraction for the
  > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule,
  > PolicyRuleInPolicyGroup
  > and PolicyRuleInPolicyRule aggregations wherein the Priority
  > property is
  > defined.  With the complexity being added to groups and rules, this
  > abstraction makes it much easier to think about the concepts
  > of decision
  > strategies and priorities. I've asked the other authors to
  > render an opinion
  > on this suggestion but I haven't heard back yet.  Opinions
  > from the broader
  > community are also welcome.
  >
  > > > With the removal of the priority property from
  > > > PolicyRule, a new modeling dependency has been
  > > > introduced: in order to prioritize a PolicyRule
  > > > relative to other PolicyRules, the rules must be
  > > > placed in a PolicyGroup.
  > >
  > > <js>
  > > I think you missed the reusable case. Assuming that you do
  > > add explicit text saying that you can put anything in a
  > > PolicyRepository, then what if you have a PolicyRule that
  > > contains two reusable PolicyRules? Here, you use the
  > > association (not aggregation)
  > > PolicyElementInPolicyRepository to associate any subclass of
  > > Policy to a PolicyRepository. Therefore, if you REALLY want
  > > to do this, you should add the
  > > PolicyElementInPolicyRepository association, defined in
  > > QPIM, to PCIMe.
  > >
  > > Note that this produces a LOT of additional complexity. I'm
  > > not sure it's a Good Thing. But the facility is there if you
  > > want to explore it.
  > > </js>
  >
  > What Bob missed in his summary was that rules can be in other
  > rules in the
  > proposed rule structure.  But the essential point that rules
  > need a context
  > to have priority is correct and, as a byproduct of the agreement to
  > deprecate the use of PolicyRule.Priority, that context is
  > proposed to be
  > explicitly defined by the aggregation discussed above.
  > PolicyElementInPolicyRepository has nothing to do with priority...the
  > repository (or "ReusablePolicyContainer" or whatever we call
  > it) does not
  > establish a context for priority evaluation; it's simply a
  > container for
  > reusable policy components.  The context for priority is tied to the
  > decision strategy on a containing group or rule.  Hopefully,
  > this will all
  > be clearer when I've written the section in the new draft.
  >
  > > >    In the absence of any clear, general criterion for
  > > > detecting policy conflicts, the PCIM restriction stating
  > > > that priorities are relevant only in the case of
  > > > conflicts has been removed.  In its place, a
  > > > DecisionStrategy property has been added to PolicyGroup
  > > > class, to allow the policy administrator to select one
  > > > of two behaviors with respect to rule evaluation: either
  > > > perform the actions for all PolicyRules whose
  > > > conditions evaluate to TRUE, or perform the actions
  > > > only for the highest-priority PolicyRule whose conditions
  > > > evaluate to TRUE. The QPIM rules for applying decision
  > > > strategies to a nested set of PolicyGroups and
  > > > PolicyRules were also imported.
  > >
  > > <js>
  > > This begs the question, "What happens if there are multiple
  > > PolicyRules of the same priority"? Then the DecisionStrategy
  > > property doesn't help. So, looking at the paragraph below, I
  > > *guess* that your answer would be that it doesn't matter
  > > which PolicyRule executes, as long as only one executes.
  > > This behavior is inconsistent with introducing the property
  > > in the first place.
  > > </js>
  >
  > Yes.  For "FirstMatching" only one rule gets executed, so if
  > the submodel
  > and adminstrator decide to permit non-deterministic rules,
  > then it up to the
  > implementation to decide which of the equal priority rules to
  > execute when
  > more than one matches.
  >
  > I don't understand how this behavior is inconsistent with the
  > introduction
  > of a priority property.  I don't personally recommend that
  > derived models
  > permit non-deterministic priorities, but when they do, this
  > is the only
  > reasonable interpretation.  The PCIM notion that priority
  > applies only to
  > conflicts has two problems: 1) it doesn't explain the
  > "FirstMatching" use of
  > priority and 2) it relies on an undefined notion of
  > "conflicting."  The
  > obvious conflicts (e.g., set DSCP to x and set DSCP to y are
  > still resolved
  > by priority in both a FirstMatching and AllMatching strategy;
  > either only
  > one gets executed or both get executed and the one evaluated
  > last wins (an
  > interesting notion of priority, I admit).  Perhaps we should
  > rename the
  > Priority property to EvaluationOrder?  (We discussed this as well and
  > decided to leave it alone, but I'm guessing we could be persuaded
  > otherwise.)
  >
  > Again, hopefully this will all be clear when I've written the
  > section in the
  > new draft.  We discussed having 3 decision strategies: FirstMatching,
  > AllMatching, AllNonConflictingMatching and decided to only
  > have two...unless
  > someone can define the AllNonConflictingMatching strategy and
  > the underlying
  > definition of "conflicting."
  >
  > > >    The question of whether to require unique priority
  > > > values for the PolicyRules in a PolicyGroup was raised and
  > > > discussed, but the decision was to allow these values to
  > > > collide within a PolicyGroup, to indicate "don't care".
  > > > Submodels of PCIMe are free to add the restriction that
  > > > priority values not collide within a PolicyGroup.
  > > >
  >
  >
  >


------=_NextPart_000_001D_01C09218.CB849CB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Decision Strategies (Re: Preliminary results from PCIMe =
technical meeting, 1/24/01 - 1/26/01)</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D882114319-08022001>IMO,=20
the priority should be placed int he association and not with the =
container.The=20
obvious example for why the association is the right place is when a =
policy rule=20
is used with in 2 different policy groups. The priority is a property of =
the=20
association, not the container and not the rule (since the same rule is =
used by=20
different containers, in different sequence/ =
priority.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D882114319-08022001>Yoram</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
policy-owner@raleigh.ibm.com=20
  [mailto:policy-owner@raleigh.ibm.com]<B>On Behalf Of</B> Mircea=20
  Pana<BR><B>Sent:</B> Tuesday, February 06, 2001 11:02 PM<BR><B>To:</B> =

  policy<BR><B>Subject:</B> RE: Decision Strategies (Re: Preliminary =
results=20
  from PCIMe techn ical meeting, 1/24/01 - 1/26/01)<BR><BR></DIV></FONT>
  <P><FONT size=3D2>My 2c. worth comments on Priority:</FONT> </P>
  <P><FONT size=3D2>The "migration" of the Priority property from =
PolicyRule (in=20
  QPIM also present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or =

  PolicySet, or PrioritizedPolicyComponent) changes its aspect from =
global to=20
  local. This, definitely, makes it more flexible.</FONT></P>
  <P><FONT size=3D2>However, IMO, the focus should be placed on the =
container=20
  instead of its components. I.e. The concept required here is a =
container with=20
  *sequenced* policy components (I would call it: PolicySequence). The =
Priority=20
  property, placed on the associations is just a way to implement =
it.</FONT></P>
  <P><FONT size=3D2>For example:</FONT> <BR><FONT size=3D2>Consider a =
PolicyGroup=20
  with two PolicyRules as components: PR1 (higher priority) and PR2 =
(lowed=20
  priority). The results of applying this PolicyGroup to a policy target =
is the=20
  same in all the following cases:</FONT></P>
  <P><FONT size=3D2>- 100 (PR1) and 1 (PR2)</FONT> <BR><FONT size=3D2>- =
2 (PR1) and=20
  1 (PR2)</FONT> <BR><FONT size=3D2>- or "HIGH" (PR1) and "LOW" =
(PR2)</FONT>=20
  <BR><FONT size=3D2>the only thing that matters is the sequence.</FONT> =
</P>
  <P><FONT size=3D2>I also realize that in some cases the order is not =
important.=20
  In such cases a PolicySet would be the appropriate concept.</FONT></P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT size=3D2>Mircea.</FONT> =
</P><BR><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Lee Rafalow [<A=20
  =
href=3D"mailto:rafalow@raleigh.ibm.com">mailto:rafalow@raleigh.ibm.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Tuesday, February 06, 2001 12:17 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: policy</FONT> <BR><FONT size=3D2>&gt; =
Subject:=20
  Decision Strategies (Re: Preliminary results from PCIMe</FONT> =
<BR><FONT=20
  size=3D2>&gt; technical meeting, 1/24/01 - 1/26/01)</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; John, =
Here are some=20
  responses to your comments on priorities </FONT><BR><FONT =
size=3D2>&gt; and=20
  decision</FONT> <BR><FONT size=3D2>&gt; strategies.&nbsp; Cheers, =
Lee</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&nbsp; =
2.2.6.=20
  Priorities and Decision Strategies</FONT> <BR><FONT size=3D2>&gt; &gt; =

  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; Drawing from both QPIM =
and ICIM,=20
  the priority property</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; has =
been=20
  deprecated in PolicyRule, and placed instead on</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; the associations PolicyRuleInPolicyGroup,</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt; PolicyGroupInPolicyGroup, =
PolicyGroupInPolicyRule,=20
  and</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; PolicyRuleInPolicyRule. =
(Obvious=20
  question: would it be</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; better =
to=20
  introduce a superclass</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;=20
  PrioritizedPolicyComponent for these four associations,</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; just to contain the priority property?&nbsp; =
The answer=20
  is</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; probably "yes".)&nbsp; The =
QPIM=20
  rules for resolving relative</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
priorities=20
  across nested PolicyGroups and PolicyRules</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; have been incorporated into PCIMe as well.</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &lt;js&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; What's the point of having a PrioritizedPolicyComponent</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; aggregation (these are aggregations, not =
associations)?=20
  This</FONT> <BR><FONT size=3D2>&gt; &gt; only makes sense if there is =
also=20
  a</FONT> <BR><FONT size=3D2>&gt; &gt; NonPrioritizedPolicyComponent =
aggregation.=20
  Because</FONT> <BR><FONT size=3D2>&gt; &gt; eventually, someone is =
going to want=20
  order or some other</FONT> <BR><FONT size=3D2>&gt; &gt; semantic added =
to one or=20
  more of these aggregations, and</FONT> <BR><FONT size=3D2>&gt; &gt; =
then we are=20
  going to have to go through the hell of</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  deprecating things again. Since this is clearly an</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; optimization, why not wait and get some =
implementation</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; experience first?</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &lt;/js&gt;</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Bob was,=20
  I think, correctly hinting at re-examining some of </FONT><BR><FONT=20
  size=3D2>&gt; the inheritance</FONT> <BR><FONT size=3D2>&gt; hierarchy =
for a=20
  couple of classes.&nbsp; While working on the section about</FONT> =
<BR><FONT=20
  size=3D2>&gt; decision strategies, I found myself writing about =
decision=20
  </FONT><BR><FONT size=3D2>&gt; strategy sets,</FONT> <BR><FONT =
size=3D2>&gt; i.e.,=20
  the abstraction for PolicyGroup and PolicyRule that </FONT><BR><FONT=20
  size=3D2>&gt; contain other</FONT> <BR><FONT size=3D2>&gt; policy =
groups and rules=20
  and have a homogeneous decision </FONT><BR><FONT size=3D2>&gt; =
strategy.&nbsp;=20
  This</FONT> <BR><FONT size=3D2>&gt; abstraction is natural for the =
inheritance=20
  hierarchy in that </FONT><BR><FONT size=3D2>&gt; a PolicySet</FONT> =
<BR><FONT=20
  size=3D2>&gt; (pick a better name of you like) is an abstraction for =
PolicyGroup=20
  and</FONT> <BR><FONT size=3D2>&gt; PolicyRule and it defines the=20
  PolicyDecisionStrategy </FONT><BR><FONT size=3D2>&gt; property.&nbsp; =
It=20
  would</FONT> <BR><FONT size=3D2>&gt; then have the PolicySetComponent=20
  aggregation (my rename of Bob's</FONT> <BR><FONT size=3D2>&gt;=20
  PrioritizedPolicyComponent) as an abstraction for the</FONT> <BR><FONT =

  size=3D2>&gt; PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule,=20
  </FONT><BR><FONT size=3D2>&gt; PolicyRuleInPolicyGroup</FONT> =
<BR><FONT=20
  size=3D2>&gt; and PolicyRuleInPolicyRule aggregations wherein the =
Priority=20
  </FONT><BR><FONT size=3D2>&gt; property is</FONT> <BR><FONT =
size=3D2>&gt;=20
  defined.&nbsp; With the complexity being added to groups and rules,=20
  this</FONT> <BR><FONT size=3D2>&gt; abstraction makes it much easier =
to think=20
  about the concepts </FONT><BR><FONT size=3D2>&gt; of decision</FONT> =
<BR><FONT=20
  size=3D2>&gt; strategies and priorities. I've asked the other authors =
to=20
  </FONT><BR><FONT size=3D2>&gt; render an opinion</FONT> <BR><FONT =
size=3D2>&gt; on=20
  this suggestion but I haven't heard back yet.&nbsp; Opinions =
</FONT><BR><FONT=20
  size=3D2>&gt; from the broader</FONT> <BR><FONT size=3D2>&gt; =
community are also=20
  welcome.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  With the removal of the priority property from</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; PolicyRule, a new modeling dependency has been</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; introduced: in order to prioritize a =
PolicyRule</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; relative to other PolicyRules, the =
rules must=20
  be</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; placed in a =
PolicyGroup.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&lt;js&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; I think you missed the reusable case. =
Assuming that=20
  you do</FONT> <BR><FONT size=3D2>&gt; &gt; add explicit text saying =
that you can=20
  put anything in a</FONT> <BR><FONT size=3D2>&gt; &gt; =
PolicyRepository, then=20
  what if you have a PolicyRule that</FONT> <BR><FONT size=3D2>&gt; &gt; =
contains=20
  two reusable PolicyRules? Here, you use the</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  association (not aggregation)</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  PolicyElementInPolicyRepository to associate any subclass of</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Policy to a PolicyRepository. Therefore, if you =
REALLY=20
  want</FONT> <BR><FONT size=3D2>&gt; &gt; to do this, you should add =
the</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; PolicyElementInPolicyRepository =
association,=20
  defined in</FONT> <BR><FONT size=3D2>&gt; &gt; QPIM, to PCIMe.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Note that this =
produces a=20
  LOT of additional complexity. I'm</FONT> <BR><FONT size=3D2>&gt; &gt; =
not sure=20
  it's a Good Thing. But the facility is there if you</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; want to explore it.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &lt;/js&gt;</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; What Bob=20
  missed in his summary was that rules can be in other </FONT><BR><FONT=20
  size=3D2>&gt; rules in the</FONT> <BR><FONT size=3D2>&gt; proposed =
rule=20
  structure.&nbsp; But the essential point that rules </FONT><BR><FONT=20
  size=3D2>&gt; need a context</FONT> <BR><FONT size=3D2>&gt; to have =
priority is=20
  correct and, as a byproduct of the agreement to</FONT> <BR><FONT =
size=3D2>&gt;=20
  deprecate the use of PolicyRule.Priority, that context is =
</FONT><BR><FONT=20
  size=3D2>&gt; proposed to be</FONT> <BR><FONT size=3D2>&gt; explicitly =
defined by=20
  the aggregation discussed above.</FONT> <BR><FONT size=3D2>&gt;=20
  PolicyElementInPolicyRepository has nothing to do with =
priority...the</FONT>=20
  <BR><FONT size=3D2>&gt; repository (or "ReusablePolicyContainer" or =
whatever we=20
  call </FONT><BR><FONT size=3D2>&gt; it) does not</FONT> <BR><FONT =
size=3D2>&gt;=20
  establish a context for priority evaluation; it's simply a =
</FONT><BR><FONT=20
  size=3D2>&gt; container for</FONT> <BR><FONT size=3D2>&gt; reusable =
policy=20
  components.&nbsp; The context for priority is tied to the</FONT> =
<BR><FONT=20
  size=3D2>&gt; decision strategy on a containing group or rule.&nbsp; =
Hopefully,=20
  </FONT><BR><FONT size=3D2>&gt; this will all</FONT> <BR><FONT =
size=3D2>&gt; be=20
  clearer when I've written the section in the new draft.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&nbsp;&nbsp;&nbsp; In the=20
  absence of any clear, general criterion for</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; detecting policy conflicts, the PCIM restriction stating</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; that priorities are relevant only in the case =
of</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; conflicts has been removed.&nbsp; In =
its=20
  place, a</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; DecisionStrategy =
property has=20
  been added to PolicyGroup</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
class, to=20
  allow the policy administrator to select one</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; of two behaviors with respect to rule evaluation: either</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; perform the actions for all PolicyRules =
whose</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; conditions evaluate to TRUE, or =
perform the=20
  actions</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; only for the =
highest-priority=20
  PolicyRule whose conditions</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
evaluate to=20
  TRUE. The QPIM rules for applying decision</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; strategies to a nested set of PolicyGroups and</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt; PolicyRules were also imported.</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&lt;js&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; This begs the question, "What happens if there are=20
  multiple</FONT> <BR><FONT size=3D2>&gt; &gt; PolicyRules of the same =
priority"?=20
  Then the DecisionStrategy</FONT> <BR><FONT size=3D2>&gt; &gt; property =
doesn't=20
  help. So, looking at the paragraph below, I</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  *guess* that your answer would be that it doesn't matter</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; which PolicyRule executes, as long as only one=20
  executes.</FONT> <BR><FONT size=3D2>&gt; &gt; This behavior is =
inconsistent with=20
  introducing the property</FONT> <BR><FONT size=3D2>&gt; &gt; in the =
first=20
  place.</FONT> <BR><FONT size=3D2>&gt; &gt; &lt;/js&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Yes.&nbsp; For =
"FirstMatching" only=20
  one rule gets executed, so if </FONT><BR><FONT size=3D2>&gt; the =
submodel</FONT>=20
  <BR><FONT size=3D2>&gt; and adminstrator decide to permit =
non-deterministic=20
  rules, </FONT><BR><FONT size=3D2>&gt; then it up to the</FONT> =
<BR><FONT=20
  size=3D2>&gt; implementation to decide which of the equal priority =
rules to=20
  </FONT><BR><FONT size=3D2>&gt; execute when</FONT> <BR><FONT =
size=3D2>&gt; more=20
  than one matches.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I=20
  don't understand how this behavior is inconsistent with the =
</FONT><BR><FONT=20
  size=3D2>&gt; introduction</FONT> <BR><FONT size=3D2>&gt; of a =
priority=20
  property.&nbsp; I don't personally recommend that </FONT><BR><FONT =
size=3D2>&gt;=20
  derived models</FONT> <BR><FONT size=3D2>&gt; permit non-deterministic =

  priorities, but when they do, this </FONT><BR><FONT size=3D2>&gt; is =
the=20
  only</FONT> <BR><FONT size=3D2>&gt; reasonable interpretation.&nbsp; =
The PCIM=20
  notion that priority </FONT><BR><FONT size=3D2>&gt; applies only =
to</FONT>=20
  <BR><FONT size=3D2>&gt; conflicts has two problems: 1) it doesn't =
explain the=20
  </FONT><BR><FONT size=3D2>&gt; "FirstMatching" use of</FONT> <BR><FONT =

  size=3D2>&gt; priority and 2) it relies on an undefined notion of=20
  </FONT><BR><FONT size=3D2>&gt; "conflicting."&nbsp; The</FONT> =
<BR><FONT=20
  size=3D2>&gt; obvious conflicts (e.g., set DSCP to x and set DSCP to y =
are=20
  </FONT><BR><FONT size=3D2>&gt; still resolved</FONT> <BR><FONT =
size=3D2>&gt; by=20
  priority in both a FirstMatching and AllMatching strategy; =
</FONT><BR><FONT=20
  size=3D2>&gt; either only</FONT> <BR><FONT size=3D2>&gt; one gets =
executed or both=20
  get executed and the one evaluated </FONT><BR><FONT size=3D2>&gt; last =
wins=20
  (an</FONT> <BR><FONT size=3D2>&gt; interesting notion of priority, I=20
  admit).&nbsp; Perhaps we should </FONT><BR><FONT size=3D2>&gt; rename =
the</FONT>=20
  <BR><FONT size=3D2>&gt; Priority property to EvaluationOrder?&nbsp; =
(We=20
  discussed this as well and</FONT> <BR><FONT size=3D2>&gt; decided to =
leave it=20
  alone, but I'm guessing we could be persuaded</FONT> <BR><FONT =
size=3D2>&gt;=20
  otherwise.)</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Again,=20
  hopefully this will all be clear when I've written the =
</FONT><BR><FONT=20
  size=3D2>&gt; section in the</FONT> <BR><FONT size=3D2>&gt; new =
draft.&nbsp; We=20
  discussed having 3 decision strategies: FirstMatching,</FONT> =
<BR><FONT=20
  size=3D2>&gt; AllMatching, AllNonConflictingMatching and decided to =
only=20
  </FONT><BR><FONT size=3D2>&gt; have two...unless</FONT> <BR><FONT =
size=3D2>&gt;=20
  someone can define the AllNonConflictingMatching strategy and =
</FONT><BR><FONT=20
  size=3D2>&gt; the underlying</FONT> <BR><FONT size=3D2>&gt; definition =
of=20
  "conflicting."</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&nbsp;&nbsp;&nbsp; The question of whether to require unique=20
  priority</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; values for the =
PolicyRules in=20
  a PolicyGroup was raised and</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
discussed,=20
  but the decision was to allow these values to</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; collide within a PolicyGroup, to indicate "don't =
care".</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; Submodels of PCIMe are free to add =
the=20
  restriction that</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; priority =
values not=20
  collide within a PolicyGroup.</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001D_01C09218.CB849CB0--



From majordomo@raleigh.ibm.com  Thu Feb  8 19:52:24 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22145
	for <policy-archive@odin.ietf.org>; Thu, 8 Feb 2001 19:52:23 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA44218;
	Thu, 8 Feb 2001 19:46:38 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA30864;
	Thu, 8 Feb 2001 19:46:36 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48044; Thu, 8 Feb 2001 18:53:44 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47268; Thu, 8 Feb 2001 18:53:40 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA31654
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 18:53:41 -0500
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA32308
	for <policy@raleigh.ibm.com>; Thu, 8 Feb 2001 18:53:36 -0500
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 8 Feb 2001 18:19:23 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <1MM3H823>; Thu, 8 Feb 2001 18:19:25 -0500
Message-Id: <28560036253BD41191A10000F8BCBD11841DC8@zcard00g.ca.nortel.com>
From: "Mircea Pana" <mpana@nortelnetworks.com>
To: "'ysnir'" <ysnir@cisco.com>, "'policy'" <policy@raleigh.ibm.com>
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn ical 
         meeting, 1/24/01 - 1/26/01)
Date: Thu, 8 Feb 2001 18:19:21 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C09225.913E7A50"
X-Orig: <mpana@americasm01.nt.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Mircea Pana" <mpana@nortelnetworks.com>

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_01C09225.913E7A50
Content-Type: text/plain;
	charset="iso-8859-1"

I agree that the Priority should be placed on the association instead of the
container. What I actually intended to suggest is that (from the component
ordering point of view) there are two types of containers: PolicySet and
PolicySequence. Wrt. the Decision Strategy, a PolicySet should be treated
differently from a PolicySequence.
 
IMO the Decision Strategy is not applicable to a Set (which should have a
"All" behavior), while it makes perfect sense on a PolicySequence. In
addition, a PolicySequence could be restricted to strict-ordering of its
components (equal priority not allowed), therefore avoiding the ambiguity
described by:
> > <js> 
> > This begs the question, "What happens if there are multiple 
> > PolicyRules of the same priority"? Then the DecisionStrategy 
> > property doesn't help. So, looking at the paragraph below, I 
> > *guess* that your answer would be that it doesn't matter 
> > which PolicyRule executes, as long as only one executes. 
> > This behavior is inconsistent with introducing the property 
> > in the first place. 
> > </js> 

Thanks,
Mircea.
 
 
 

-----Original Message-----
From: Yoram Snir [mailto:ysnir@cisco.com]
Sent: Thursday, February 08, 2001 2:48 PM
To: Pana, Mircea [CAR:5E20:EXCH]; 'policy'
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)


IMO, the priority should be placed int he association and not with the
container.The obvious example for why the association is the right place is
when a policy rule is used with in 2 different policy groups. The priority
is a property of the association, not the container and not the rule (since
the same rule is used by different containers, in different sequence/
priority.
Yoram

-----Original Message-----
From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On
Behalf Of Mircea Pana
Sent: Tuesday, February 06, 2001 11:02 PM
To: policy
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)



My 2c. worth comments on Priority: 

The "migration" of the Priority property from PolicyRule (in QPIM also
present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or PolicySet, or
PrioritizedPolicyComponent) changes its aspect from global to local. This,
definitely, makes it more flexible.

However, IMO, the focus should be placed on the container instead of its
components. I.e. The concept required here is a container with *sequenced*
policy components (I would call it: PolicySequence). The Priority property,
placed on the associations is just a way to implement it.

For example: 
Consider a PolicyGroup with two PolicyRules as components: PR1 (higher
priority) and PR2 (lowed priority). The results of applying this PolicyGroup
to a policy target is the same in all the following cases:

- 100 (PR1) and 1 (PR2) 
- 2 (PR1) and 1 (PR2) 
- or "HIGH" (PR1) and "LOW" (PR2) 
the only thing that matters is the sequence. 

I also realize that in some cases the order is not important. In such cases
a PolicySet would be the appropriate concept.

Regards, 
Mircea. 



> -----Original Message----- 
> From: Lee Rafalow [ mailto:rafalow@raleigh.ibm.com
<mailto:rafalow@raleigh.ibm.com> ] 
> Sent: Tuesday, February 06, 2001 12:17 PM 
> To: policy 
> Subject: Decision Strategies (Re: Preliminary results from PCIMe 
> technical meeting, 1/24/01 - 1/26/01) 
> 
> 
> John, Here are some responses to your comments on priorities 
> and decision 
> strategies.  Cheers, Lee 
> 
> > >  2.2.6. Priorities and Decision Strategies 
> > > 
> > > Drawing from both QPIM and ICIM, the priority property 
> > > has been deprecated in PolicyRule, and placed instead on 
> > > the associations PolicyRuleInPolicyGroup, 
> > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and 
> > > PolicyRuleInPolicyRule. (Obvious question: would it be 
> > > better to introduce a superclass 
> > > PrioritizedPolicyComponent for these four associations, 
> > > just to contain the priority property?  The answer is 
> > > probably "yes".)  The QPIM rules for resolving relative 
> > > priorities across nested PolicyGroups and PolicyRules 
> > > have been incorporated into PCIMe as well. 
> > 
> > <js> 
> > What's the point of having a PrioritizedPolicyComponent 
> > aggregation (these are aggregations, not associations)? This 
> > only makes sense if there is also a 
> > NonPrioritizedPolicyComponent aggregation. Because 
> > eventually, someone is going to want order or some other 
> > semantic added to one or more of these aggregations, and 
> > then we are going to have to go through the hell of 
> > deprecating things again. Since this is clearly an 
> > optimization, why not wait and get some implementation 
> > experience first? 
> > </js> 
> 
> Bob was, I think, correctly hinting at re-examining some of 
> the inheritance 
> hierarchy for a couple of classes.  While working on the section about 
> decision strategies, I found myself writing about decision 
> strategy sets, 
> i.e., the abstraction for PolicyGroup and PolicyRule that 
> contain other 
> policy groups and rules and have a homogeneous decision 
> strategy.  This 
> abstraction is natural for the inheritance hierarchy in that 
> a PolicySet 
> (pick a better name of you like) is an abstraction for PolicyGroup and 
> PolicyRule and it defines the PolicyDecisionStrategy 
> property.  It would 
> then have the PolicySetComponent aggregation (my rename of Bob's 
> PrioritizedPolicyComponent) as an abstraction for the 
> PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, 
> PolicyRuleInPolicyGroup 
> and PolicyRuleInPolicyRule aggregations wherein the Priority 
> property is 
> defined.  With the complexity being added to groups and rules, this 
> abstraction makes it much easier to think about the concepts 
> of decision 
> strategies and priorities. I've asked the other authors to 
> render an opinion 
> on this suggestion but I haven't heard back yet.  Opinions 
> from the broader 
> community are also welcome. 
> 
> > > With the removal of the priority property from 
> > > PolicyRule, a new modeling dependency has been 
> > > introduced: in order to prioritize a PolicyRule 
> > > relative to other PolicyRules, the rules must be 
> > > placed in a PolicyGroup. 
> > 
> > <js> 
> > I think you missed the reusable case. Assuming that you do 
> > add explicit text saying that you can put anything in a 
> > PolicyRepository, then what if you have a PolicyRule that 
> > contains two reusable PolicyRules? Here, you use the 
> > association (not aggregation) 
> > PolicyElementInPolicyRepository to associate any subclass of 
> > Policy to a PolicyRepository. Therefore, if you REALLY want 
> > to do this, you should add the 
> > PolicyElementInPolicyRepository association, defined in 
> > QPIM, to PCIMe. 
> > 
> > Note that this produces a LOT of additional complexity. I'm 
> > not sure it's a Good Thing. But the facility is there if you 
> > want to explore it. 
> > </js> 
> 
> What Bob missed in his summary was that rules can be in other 
> rules in the 
> proposed rule structure.  But the essential point that rules 
> need a context 
> to have priority is correct and, as a byproduct of the agreement to 
> deprecate the use of PolicyRule.Priority, that context is 
> proposed to be 
> explicitly defined by the aggregation discussed above. 
> PolicyElementInPolicyRepository has nothing to do with priority...the 
> repository (or "ReusablePolicyContainer" or whatever we call 
> it) does not 
> establish a context for priority evaluation; it's simply a 
> container for 
> reusable policy components.  The context for priority is tied to the 
> decision strategy on a containing group or rule.  Hopefully, 
> this will all 
> be clearer when I've written the section in the new draft. 
> 
> > >    In the absence of any clear, general criterion for 
> > > detecting policy conflicts, the PCIM restriction stating 
> > > that priorities are relevant only in the case of 
> > > conflicts has been removed.  In its place, a 
> > > DecisionStrategy property has been added to PolicyGroup 
> > > class, to allow the policy administrator to select one 
> > > of two behaviors with respect to rule evaluation: either 
> > > perform the actions for all PolicyRules whose 
> > > conditions evaluate to TRUE, or perform the actions 
> > > only for the highest-priority PolicyRule whose conditions 
> > > evaluate to TRUE. The QPIM rules for applying decision 
> > > strategies to a nested set of PolicyGroups and 
> > > PolicyRules were also imported. 
> > 
> > <js> 
> > This begs the question, "What happens if there are multiple 
> > PolicyRules of the same priority"? Then the DecisionStrategy 
> > property doesn't help. So, looking at the paragraph below, I 
> > *guess* that your answer would be that it doesn't matter 
> > which PolicyRule executes, as long as only one executes. 
> > This behavior is inconsistent with introducing the property 
> > in the first place. 
> > </js> 
> 
> Yes.  For "FirstMatching" only one rule gets executed, so if 
> the submodel 
> and adminstrator decide to permit non-deterministic rules, 
> then it up to the 
> implementation to decide which of the equal priority rules to 
> execute when 
> more than one matches. 
> 
> I don't understand how this behavior is inconsistent with the 
> introduction 
> of a priority property.  I don't personally recommend that 
> derived models 
> permit non-deterministic priorities, but when they do, this 
> is the only 
> reasonable interpretation.  The PCIM notion that priority 
> applies only to 
> conflicts has two problems: 1) it doesn't explain the 
> "FirstMatching" use of 
> priority and 2) it relies on an undefined notion of 
> "conflicting."  The 
> obvious conflicts (e.g., set DSCP to x and set DSCP to y are 
> still resolved 
> by priority in both a FirstMatching and AllMatching strategy; 
> either only 
> one gets executed or both get executed and the one evaluated 
> last wins (an 
> interesting notion of priority, I admit).  Perhaps we should 
> rename the 
> Priority property to EvaluationOrder?  (We discussed this as well and 
> decided to leave it alone, but I'm guessing we could be persuaded 
> otherwise.) 
> 
> Again, hopefully this will all be clear when I've written the 
> section in the 
> new draft.  We discussed having 3 decision strategies: FirstMatching, 
> AllMatching, AllNonConflictingMatching and decided to only 
> have two...unless 
> someone can define the AllNonConflictingMatching strategy and 
> the underlying 
> definition of "conflicting." 
> 
> > >    The question of whether to require unique priority 
> > > values for the PolicyRules in a PolicyGroup was raised and 
> > > discussed, but the decision was to allow these values to 
> > > collide within a PolicyGroup, to indicate "don't care". 
> > > Submodels of PCIMe are free to add the restriction that 
> > > priority values not collide within a PolicyGroup. 
> > > 
> 
> 
> 


------_=_NextPart_001_01C09225.913E7A50
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Decision Strategies (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064165422-08022001>I 
agree that the&nbsp;Priority should be placed on the association instead of the 
container. What I actually intended to suggest is that (from the component 
ordering point of view) there are two types of containers: PolicySet and 
PolicySequence. Wrt. the Decision Strategy, a PolicySet&nbsp;should be treated 
differently from a PolicySequence.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064165422-08022001>IMO 
the Decision Strategy is not applicable to a Set (which should&nbsp;have a "All" 
behavior), while it makes perfect sense on a PolicySequence.</SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=064165422-08022001> In 
addition,&nbsp;a PolicySequence could be restricted&nbsp;to strict-ordering of 
its components (equal priority not allowed), therefore avoiding the ambiguity 
described by:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=064165422-08022001><FONT 
size=2>&gt; &gt; &lt;js&gt;</FONT> <BR><FONT size=2>&gt; &gt; This begs the 
question, "What happens if there are multiple</FONT> <BR><FONT size=2>&gt; &gt; 
PolicyRules of the same priority"? Then the DecisionStrategy</FONT> <BR><FONT 
size=2>&gt; &gt; property doesn't help. So, looking at the paragraph below, 
I</FONT> <BR><FONT size=2>&gt; &gt; *guess* that your answer would be that it 
doesn't matter</FONT> <BR><FONT size=2>&gt; &gt; which PolicyRule executes, as 
long as only one executes.</FONT> <BR><FONT size=2>&gt; &gt; This behavior is 
inconsistent with introducing the property</FONT> <BR><FONT size=2>&gt; &gt; in 
the first place.</FONT> <BR><FONT size=2>&gt; &gt; &lt;/js&gt;</FONT> 
<BR></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001>Mircea.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001>&nbsp;</DIV></SPAN></FONT>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=064165422-08022001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Yoram Snir 
  [mailto:ysnir@cisco.com]<BR><B>Sent:</B> Thursday, February 08, 2001 2:48 
  PM<BR><B>To:</B> Pana, Mircea [CAR:5E20:EXCH]; 'policy'<BR><B>Subject:</B> RE: 
  Decision Strategies (Re: Preliminary results from PCIMe techn ical meeting, 
  1/24/01 - 1/26/01)<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=882114319-08022001>IMO, 
  the priority should be placed int he association and not with the 
  container.The obvious example for why the association is the right place is 
  when a policy rule is used with in 2 different policy groups. The priority is 
  a property of the association, not the container and not the rule (since the 
  same rule is used by different containers, in different sequence/ 
  priority.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=882114319-08022001>Yoram</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
    size=2>-----Original Message-----<BR><B>From:</B> 
    policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]<B>On 
    Behalf Of</B> Mircea Pana<BR><B>Sent:</B> Tuesday, February 06, 2001 11:02 
    PM<BR><B>To:</B> policy<BR><B>Subject:</B> RE: Decision Strategies (Re: 
    Preliminary results from PCIMe techn ical meeting, 1/24/01 - 
    1/26/01)<BR><BR></DIV></FONT>
    <P><FONT size=2>My 2c. worth comments on Priority:</FONT> </P>
    <P><FONT size=2>The "migration" of the Priority property from PolicyRule (in 
    QPIM also present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or 
    PolicySet, or PrioritizedPolicyComponent) changes its aspect from global to 
    local. This, definitely, makes it more flexible.</FONT></P>
    <P><FONT size=2>However, IMO, the focus should be placed on the container 
    instead of its components. I.e. The concept required here is a container 
    with *sequenced* policy components (I would call it: PolicySequence). The 
    Priority property, placed on the associations is just a way to implement 
    it.</FONT></P>
    <P><FONT size=2>For example:</FONT> <BR><FONT size=2>Consider a PolicyGroup 
    with two PolicyRules as components: PR1 (higher priority) and PR2 (lowed 
    priority). The results of applying this PolicyGroup to a policy target is 
    the same in all the following cases:</FONT></P>
    <P><FONT size=2>- 100 (PR1) and 1 (PR2)</FONT> <BR><FONT size=2>- 2 (PR1) 
    and 1 (PR2)</FONT> <BR><FONT size=2>- or "HIGH" (PR1) and "LOW" (PR2)</FONT> 
    <BR><FONT size=2>the only thing that matters is the sequence.</FONT> </P>
    <P><FONT size=2>I also realize that in some cases the order is not 
    important. In such cases a PolicySet would be the appropriate 
    concept.</FONT></P>
    <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Mircea.</FONT> </P><BR><BR>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Lee Rafalow [<A 
    href="mailto:rafalow@raleigh.ibm.com">mailto:rafalow@raleigh.ibm.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Tuesday, February 06, 2001 12:17 PM</FONT> 
    <BR><FONT size=2>&gt; To: policy</FONT> <BR><FONT size=2>&gt; Subject: 
    Decision Strategies (Re: Preliminary results from PCIMe</FONT> <BR><FONT 
    size=2>&gt; technical meeting, 1/24/01 - 1/26/01)</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; John, 
    Here are some responses to your comments on priorities </FONT><BR><FONT 
    size=2>&gt; and decision</FONT> <BR><FONT size=2>&gt; strategies.&nbsp; 
    Cheers, Lee</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; 
    &gt;&nbsp; 2.2.6. Priorities and Decision Strategies</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt; Drawing from 
    both QPIM and ICIM, the priority property</FONT> <BR><FONT size=2>&gt; &gt; 
    &gt; has been deprecated in PolicyRule, and placed instead on</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt; the associations 
    PolicyRuleInPolicyGroup,</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
    PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt; PolicyRuleInPolicyRule. (Obvious question: would it 
    be</FONT> <BR><FONT size=2>&gt; &gt; &gt; better to introduce a 
    superclass</FONT> <BR><FONT size=2>&gt; &gt; &gt; PrioritizedPolicyComponent 
    for these four associations,</FONT> <BR><FONT size=2>&gt; &gt; &gt; just to 
    contain the priority property?&nbsp; The answer is</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt; probably "yes".)&nbsp; The QPIM rules for resolving 
    relative</FONT> <BR><FONT size=2>&gt; &gt; &gt; priorities across nested 
    PolicyGroups and PolicyRules</FONT> <BR><FONT size=2>&gt; &gt; &gt; have 
    been incorporated into PCIMe as well.</FONT> <BR><FONT size=2>&gt; 
    &gt;</FONT> <BR><FONT size=2>&gt; &gt; &lt;js&gt;</FONT> <BR><FONT 
    size=2>&gt; &gt; What's the point of having a 
    PrioritizedPolicyComponent</FONT> <BR><FONT size=2>&gt; &gt; aggregation 
    (these are aggregations, not associations)? This</FONT> <BR><FONT 
    size=2>&gt; &gt; only makes sense if there is also a</FONT> <BR><FONT 
    size=2>&gt; &gt; NonPrioritizedPolicyComponent aggregation. Because</FONT> 
    <BR><FONT size=2>&gt; &gt; eventually, someone is going to want order or 
    some other</FONT> <BR><FONT size=2>&gt; &gt; semantic added to one or more 
    of these aggregations, and</FONT> <BR><FONT size=2>&gt; &gt; then we are 
    going to have to go through the hell of</FONT> <BR><FONT size=2>&gt; &gt; 
    deprecating things again. Since this is clearly an</FONT> <BR><FONT 
    size=2>&gt; &gt; optimization, why not wait and get some 
    implementation</FONT> <BR><FONT size=2>&gt; &gt; experience first?</FONT> 
    <BR><FONT size=2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Bob was, I think, correctly hinting at 
    re-examining some of </FONT><BR><FONT size=2>&gt; the inheritance</FONT> 
    <BR><FONT size=2>&gt; hierarchy for a couple of classes.&nbsp; While working 
    on the section about</FONT> <BR><FONT size=2>&gt; decision strategies, I 
    found myself writing about decision </FONT><BR><FONT size=2>&gt; strategy 
    sets,</FONT> <BR><FONT size=2>&gt; i.e., the abstraction for PolicyGroup and 
    PolicyRule that </FONT><BR><FONT size=2>&gt; contain other</FONT> <BR><FONT 
    size=2>&gt; policy groups and rules and have a homogeneous decision 
    </FONT><BR><FONT size=2>&gt; strategy.&nbsp; This</FONT> <BR><FONT 
    size=2>&gt; abstraction is natural for the inheritance hierarchy in that 
    </FONT><BR><FONT size=2>&gt; a PolicySet</FONT> <BR><FONT size=2>&gt; (pick 
    a better name of you like) is an abstraction for PolicyGroup and</FONT> 
    <BR><FONT size=2>&gt; PolicyRule and it defines the PolicyDecisionStrategy 
    </FONT><BR><FONT size=2>&gt; property.&nbsp; It would</FONT> <BR><FONT 
    size=2>&gt; then have the PolicySetComponent aggregation (my rename of 
    Bob's</FONT> <BR><FONT size=2>&gt; PrioritizedPolicyComponent) as an 
    abstraction for the</FONT> <BR><FONT size=2>&gt; PolicyGroupInPolicyGroup, 
    PolicyGroupInPolicyRule, </FONT><BR><FONT size=2>&gt; 
    PolicyRuleInPolicyGroup</FONT> <BR><FONT size=2>&gt; and 
    PolicyRuleInPolicyRule aggregations wherein the Priority </FONT><BR><FONT 
    size=2>&gt; property is</FONT> <BR><FONT size=2>&gt; defined.&nbsp; With the 
    complexity being added to groups and rules, this</FONT> <BR><FONT 
    size=2>&gt; abstraction makes it much easier to think about the concepts 
    </FONT><BR><FONT size=2>&gt; of decision</FONT> <BR><FONT size=2>&gt; 
    strategies and priorities. I've asked the other authors to </FONT><BR><FONT 
    size=2>&gt; render an opinion</FONT> <BR><FONT size=2>&gt; on this 
    suggestion but I haven't heard back yet.&nbsp; Opinions </FONT><BR><FONT 
    size=2>&gt; from the broader</FONT> <BR><FONT size=2>&gt; community are also 
    welcome.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
    With the removal of the priority property from</FONT> <BR><FONT size=2>&gt; 
    &gt; &gt; PolicyRule, a new modeling dependency has been</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt; introduced: in order to prioritize a PolicyRule</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt; relative to other PolicyRules, the rules 
    must be</FONT> <BR><FONT size=2>&gt; &gt; &gt; placed in a 
    PolicyGroup.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt; &lt;js&gt;</FONT> <BR><FONT size=2>&gt; &gt; I think you missed the 
    reusable case. Assuming that you do</FONT> <BR><FONT size=2>&gt; &gt; add 
    explicit text saying that you can put anything in a</FONT> <BR><FONT 
    size=2>&gt; &gt; PolicyRepository, then what if you have a PolicyRule 
    that</FONT> <BR><FONT size=2>&gt; &gt; contains two reusable PolicyRules? 
    Here, you use the</FONT> <BR><FONT size=2>&gt; &gt; association (not 
    aggregation)</FONT> <BR><FONT size=2>&gt; &gt; 
    PolicyElementInPolicyRepository to associate any subclass of</FONT> 
    <BR><FONT size=2>&gt; &gt; Policy to a PolicyRepository. Therefore, if you 
    REALLY want</FONT> <BR><FONT size=2>&gt; &gt; to do this, you should add 
    the</FONT> <BR><FONT size=2>&gt; &gt; PolicyElementInPolicyRepository 
    association, defined in</FONT> <BR><FONT size=2>&gt; &gt; QPIM, to 
    PCIMe.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
    Note that this produces a LOT of additional complexity. I'm</FONT> <BR><FONT 
    size=2>&gt; &gt; not sure it's a Good Thing. But the facility is there if 
    you</FONT> <BR><FONT size=2>&gt; &gt; want to explore it.</FONT> <BR><FONT 
    size=2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; What Bob missed in his summary was that rules can be in other 
    </FONT><BR><FONT size=2>&gt; rules in the</FONT> <BR><FONT size=2>&gt; 
    proposed rule structure.&nbsp; But the essential point that rules 
    </FONT><BR><FONT size=2>&gt; need a context</FONT> <BR><FONT size=2>&gt; to 
    have priority is correct and, as a byproduct of the agreement to</FONT> 
    <BR><FONT size=2>&gt; deprecate the use of PolicyRule.Priority, that context 
    is </FONT><BR><FONT size=2>&gt; proposed to be</FONT> <BR><FONT size=2>&gt; 
    explicitly defined by the aggregation discussed above.</FONT> <BR><FONT 
    size=2>&gt; PolicyElementInPolicyRepository has nothing to do with 
    priority...the</FONT> <BR><FONT size=2>&gt; repository (or 
    "ReusablePolicyContainer" or whatever we call </FONT><BR><FONT size=2>&gt; 
    it) does not</FONT> <BR><FONT size=2>&gt; establish a context for priority 
    evaluation; it's simply a </FONT><BR><FONT size=2>&gt; container for</FONT> 
    <BR><FONT size=2>&gt; reusable policy components.&nbsp; The context for 
    priority is tied to the</FONT> <BR><FONT size=2>&gt; decision strategy on a 
    containing group or rule.&nbsp; Hopefully, </FONT><BR><FONT size=2>&gt; this 
    will all</FONT> <BR><FONT size=2>&gt; be clearer when I've written the 
    section in the new draft.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; In the absence of any clear, general 
    criterion for</FONT> <BR><FONT size=2>&gt; &gt; &gt; detecting policy 
    conflicts, the PCIM restriction stating</FONT> <BR><FONT size=2>&gt; &gt; 
    &gt; that priorities are relevant only in the case of</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt; conflicts has been removed.&nbsp; In its place, 
    a</FONT> <BR><FONT size=2>&gt; &gt; &gt; DecisionStrategy property has been 
    added to PolicyGroup</FONT> <BR><FONT size=2>&gt; &gt; &gt; class, to allow 
    the policy administrator to select one</FONT> <BR><FONT size=2>&gt; &gt; 
    &gt; of two behaviors with respect to rule evaluation: either</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt; perform the actions for all PolicyRules 
    whose</FONT> <BR><FONT size=2>&gt; &gt; &gt; conditions evaluate to TRUE, or 
    perform the actions</FONT> <BR><FONT size=2>&gt; &gt; &gt; only for the 
    highest-priority PolicyRule whose conditions</FONT> <BR><FONT size=2>&gt; 
    &gt; &gt; evaluate to TRUE. The QPIM rules for applying decision</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt; strategies to a nested set of PolicyGroups 
    and</FONT> <BR><FONT size=2>&gt; &gt; &gt; PolicyRules were also 
    imported.</FONT> <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; 
    &gt; &lt;js&gt;</FONT> <BR><FONT size=2>&gt; &gt; This begs the question, 
    "What happens if there are multiple</FONT> <BR><FONT size=2>&gt; &gt; 
    PolicyRules of the same priority"? Then the DecisionStrategy</FONT> 
    <BR><FONT size=2>&gt; &gt; property doesn't help. So, looking at the 
    paragraph below, I</FONT> <BR><FONT size=2>&gt; &gt; *guess* that your 
    answer would be that it doesn't matter</FONT> <BR><FONT size=2>&gt; &gt; 
    which PolicyRule executes, as long as only one executes.</FONT> <BR><FONT 
    size=2>&gt; &gt; This behavior is inconsistent with introducing the 
    property</FONT> <BR><FONT size=2>&gt; &gt; in the first place.</FONT> 
    <BR><FONT size=2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Yes.&nbsp; For "FirstMatching" only one rule 
    gets executed, so if </FONT><BR><FONT size=2>&gt; the submodel</FONT> 
    <BR><FONT size=2>&gt; and adminstrator decide to permit non-deterministic 
    rules, </FONT><BR><FONT size=2>&gt; then it up to the</FONT> <BR><FONT 
    size=2>&gt; implementation to decide which of the equal priority rules to 
    </FONT><BR><FONT size=2>&gt; execute when</FONT> <BR><FONT size=2>&gt; more 
    than one matches.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    I don't understand how this behavior is inconsistent with the 
    </FONT><BR><FONT size=2>&gt; introduction</FONT> <BR><FONT size=2>&gt; of a 
    priority property.&nbsp; I don't personally recommend that </FONT><BR><FONT 
    size=2>&gt; derived models</FONT> <BR><FONT size=2>&gt; permit 
    non-deterministic priorities, but when they do, this </FONT><BR><FONT 
    size=2>&gt; is the only</FONT> <BR><FONT size=2>&gt; reasonable 
    interpretation.&nbsp; The PCIM notion that priority </FONT><BR><FONT 
    size=2>&gt; applies only to</FONT> <BR><FONT size=2>&gt; conflicts has two 
    problems: 1) it doesn't explain the </FONT><BR><FONT size=2>&gt; 
    "FirstMatching" use of</FONT> <BR><FONT size=2>&gt; priority and 2) it 
    relies on an undefined notion of </FONT><BR><FONT size=2>&gt; 
    "conflicting."&nbsp; The</FONT> <BR><FONT size=2>&gt; obvious conflicts 
    (e.g., set DSCP to x and set DSCP to y are </FONT><BR><FONT size=2>&gt; 
    still resolved</FONT> <BR><FONT size=2>&gt; by priority in both a 
    FirstMatching and AllMatching strategy; </FONT><BR><FONT size=2>&gt; either 
    only</FONT> <BR><FONT size=2>&gt; one gets executed or both get executed and 
    the one evaluated </FONT><BR><FONT size=2>&gt; last wins (an</FONT> 
    <BR><FONT size=2>&gt; interesting notion of priority, I admit).&nbsp; 
    Perhaps we should </FONT><BR><FONT size=2>&gt; rename the</FONT> <BR><FONT 
    size=2>&gt; Priority property to EvaluationOrder?&nbsp; (We discussed this 
    as well and</FONT> <BR><FONT size=2>&gt; decided to leave it alone, but I'm 
    guessing we could be persuaded</FONT> <BR><FONT size=2>&gt; 
    otherwise.)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Again, 
    hopefully this will all be clear when I've written the </FONT><BR><FONT 
    size=2>&gt; section in the</FONT> <BR><FONT size=2>&gt; new draft.&nbsp; We 
    discussed having 3 decision strategies: FirstMatching,</FONT> <BR><FONT 
    size=2>&gt; AllMatching, AllNonConflictingMatching and decided to only 
    </FONT><BR><FONT size=2>&gt; have two...unless</FONT> <BR><FONT size=2>&gt; 
    someone can define the AllNonConflictingMatching strategy and 
    </FONT><BR><FONT size=2>&gt; the underlying</FONT> <BR><FONT size=2>&gt; 
    definition of "conflicting."</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The question of whether to require 
    unique priority</FONT> <BR><FONT size=2>&gt; &gt; &gt; values for the 
    PolicyRules in a PolicyGroup was raised and</FONT> <BR><FONT size=2>&gt; 
    &gt; &gt; discussed, but the decision was to allow these values to</FONT> 
    <BR><FONT size=2>&gt; &gt; &gt; collide within a PolicyGroup, to indicate 
    "don't care".</FONT> <BR><FONT size=2>&gt; &gt; &gt; Submodels of PCIMe are 
    free to add the restriction that</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
    priority values not collide within a PolicyGroup.</FONT> <BR><FONT 
    size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; 
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C09225.913E7A50--


From majordomo@raleigh.ibm.com  Fri Feb  9 10:04:30 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19321
	for <policy-archive@odin.ietf.org>; Fri, 9 Feb 2001 10:04:29 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA39544;
	Fri, 9 Feb 2001 09:46:34 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29908;
	Fri, 9 Feb 2001 09:46:23 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43416; Fri, 9 Feb 2001 09:17:23 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37262; Fri, 9 Feb 2001 09:17:16 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA35196
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 09:17:21 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA25034
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 09:17:15 -0500
Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f19EHaA98860;
	Fri, 9 Feb 2001 15:17:36 +0100 (CET)
Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA01120;
	Fri, 9 Feb 2001 15:17:18 +0100
Message-Id: <3A83FC39.2F109B7A@ccrle.nec.de>
Date: Fri, 09 Feb 2001 15:18:33 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
Organization: NEC Europe Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,de
Mime-Version: 1.0
To: Mircea Pana <mpana@nortelnetworks.com>
Cc: "'policy'" <policy@raleigh.ibm.com>
Subject: Re: Decision Strategies (Re: Preliminary results from PCIMe techn ical 
 meeting, 1/24/01 - 1/26/01)
References: <28560036253BD41191A10000F8BCBD11841DC8@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit


>I agree that the Priority should be placed on the association instead of the container. >What I actually intended to suggest is that
>(from the component ordering point of view) there are two types of containers: PolicySet >and PolicySequence. Wrt. the Decision
>Strategy, a PolicySet should be treated differently from a PolicySequence.

If I recall our meeting correctly, we discussed about the difference,
but decided to go only with the priority. The meaning is a little
different depending on the decision strategy of the group.

Marcus
-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155


From majordomo@raleigh.ibm.com  Fri Feb  9 14:12:31 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29073
	for <policy-archive@odin.ietf.org>; Fri, 9 Feb 2001 14:12:30 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34838;
	Fri, 9 Feb 2001 14:05:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA33736;
	Fri, 9 Feb 2001 14:05:39 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23742; Fri, 9 Feb 2001 13:37:04 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34726; Fri, 9 Feb 2001 13:37:00 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA35074
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 13:37:00 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA23616
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 13:36:58 -0500
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id f19IaFm06615;
	Fri, 9 Feb 2001 18:36:15 GMT
Message-Id: <4.2.2.20010209133237.00bbba00@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 09 Feb 2001 13:35:41 -0500
To: John Strassner <jstrassn@cisco.com>, "Robert Moore" <remoore@us.ibm.com>
From: "Joel M. Halpern" <joel@longsys.com>
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
Cc: <policy@raleigh.ibm.com>, johns@cisco.com
In-Reply-To: <4.3.2.7.2.20010207111219.00b13368@mira-sjcm-1.cisco.com>
References: <OFBB76AE44.2FF5D4DA-ON852569EB.0067B982@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Joel M. Halpern" <joel@longsys.com>

Actually, we need to be careful about the phrase "map between the two".
1) One can create variable condition expressions to represent (with 
suitable variables) filters
2) For variable expressions that correspond to filters, one can (usually) 
create the filter.

However, it is certainly not the case that all variable conditions can be 
reasonably expressed in the filter mechanisms that we are looking at.  One 
of the nice things about filters and filter classes is that you can 
describe what set of filters the underlying system can support.  Simply 
describing what set of variables can be tested in expressions does not give 
one the same level of clarity.  Hence, we will probably find ourselves 
needing to write somewhere textual restrictions on the variable expressions 
if we want them to be "mappable" to useable filters.

Yours,
Joel M. Halpern

At 11:19 AM 2/7/01 -0800, John Strassner wrote:

>Bob,
>
>first, I didn't think that people were asking us to pick one method. This 
>is dictatorial without due cause. If one can map between the two, which 
>you agreed could be done in your note, why not let people choose what 
>method is most appropriate for their application? I don't think we'll ever 
>be able to say that one method is better than the other, because 
>applications will use these tools differently.
>
>Furthermore, I don't understand your reasoning. First, you say that people 
>want us to pick one method. Then, you say that it is perfectly acceptable 
>for us to have one method in PCIMe and another method in ICIM. This 
>contradicts your goal of having us pick one.
>
>In addition, I don't understand the point of your message, unless it was 
>to underscore that PCIMe didn't do what people wanted. My point was simply 
>that the two mechanisms are equivalent and either could be used in a given 
>application. Since that is what is happening, why can't we just document that?
>
>John
>
>p.s.: still waiting for responses on my other points...
>
>At 02:13 PM 2/6/2001 -0500, Robert Moore wrote:
>>John,
>>
>>Here are your comments on the "Packet Filtering" section
>>of my PCIMe note.  My responses are below your comments.
>>
>>
>> >  2.2.5. Packet Filtering
>> >
>> >    For packet filtering done in the context of a
>> > PolicyCondition, a set of PolicyVariables and
>> > PolicyValues were defined, corresponding to the
>> > fields in an IP packet header plus the most common
>> > Layer 2 frame header fields.  It is expected that policy
>> > conditions that filter on these header fields will be
>> > expressed in terms of CompoundPolicyConditions built up
>> > from SimplePolicyConditions that use these variables and
>> > values.
>> > An additional PolicyVariable, PacketDirection, was also
>> > defined, to indicate whether a packet being filtered is
>> > traveling inbound or outbound on an interface.
>> >
>> >    For packet filtering in other contexts (specifically,
>> > for the packet classifier filters modeled in QDDIM),
>> > these variables and values need not be used.  Filter
>> > classes derived from the CIM FilterEntryBase class
>> > hierarchy may still be used in these contexts.
>>
>><js>
>>This last sentence is misleading. One can easily define
>>equivalences between the FilterEntry.MatchConditionType and
>>the PolicyVariable classes and also between the
>>FilterEntry.MatchConditionValue and the PolicyValue classes.
>>The perception that PolicyVariables and PolicyValues somehow
>>break FilterEntries is just plain wrong.
>>
>>Perhaps some additional wording to this effect should be
>>included in PCIMe. The designer can specify a filter using
>>either FilterEntries and/or {variable, operator, value}
>>triplets.
>></js>
>>
>>I'm not sure I understand your basic point here, since
>>I think it's been a given all along that one can construct
>>equivalent filters using the two technologies.  I thought
>>that what people were asking us to do was simply to pick
>>one or the other mechanism as *the* way to represent
>>packet filtering for all IP-related policy models.
>>
>>So, people asked us to pick one method or the other, and we
>>didn't quite do that.  We picked Variables&Values for
>>filters in Policy Conditions, but left FilterEntries as an
>>option for non-policy contexts like QDDIM.  This is what
>>we've proposed for PCIMe to say.
>>
>>There's also the reality of staging, stability, and
>>schedules.  Even if PCIMe is going to end up saying that
>>Policy Conditions SHALL use Variables&Values to represent
>>packet filters, Lee and Jamie have elected to say that
>>for March, at least, ICIM is too far down the FilterEntry
>>path to change at this point.  So we'll have the anomaly
>>in ICIM of Policy Conditions that do packet filtering
>>using FilterEntries rather than Variables&Values.
>>
>>Bottom line:  I think that your last sentence ("The
>>designer can specify a filter using either FilterEntries
>>and/or {variable, operator, value} triplets.") is
>>precisely what people *don't* want PCIMe to say.  Even if
>>we have to hedge it a little, I think they would rather
>>have us make a choice one way or the other.
>>
>>Regards,
>>Bob
>>
>>Bob Moore
>>IBM Networking Software
>>+1-919-254-4436
>>remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Fri Feb  9 15:42:05 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01227
	for <policy-archive@odin.ietf.org>; Fri, 9 Feb 2001 15:42:04 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA34586;
	Fri, 9 Feb 2001 15:34:17 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA39422;
	Fri, 9 Feb 2001 15:34:16 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA25952; Fri, 9 Feb 2001 15:06:49 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45886; Fri, 9 Feb 2001 15:06:44 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA28312;
	Fri, 9 Feb 2001 15:06:45 -0500
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA32898;
	Fri, 9 Feb 2001 15:06:41 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA15066;
	Fri, 9 Feb 2001 12:06:25 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id AKY17008;
	Fri, 9 Feb 2001 12:06:01 -0800 (PST)
Message-Id: <4.3.2.7.2.20010209043835.00b586c8@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 09 Feb 2001 06:04:14 -0800
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
From: John Strassner <jstrassn@cisco.com>
Subject: Re: Decision Strategies (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
Cc: <policy@raleigh.ibm.com>
In-Reply-To: <009601c09060$9341d840$11312509@raleigh.ibm.com>
References: <OFC173406E.ADC0CFF9-ON852569E4.005609F7@raleigh.ibm.com>
 <0aba01c08d64$dd3c81b0$826c45ab@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Hi Lee,

thanks for the comments. Please see inline comments, demarcated by 
<js2>..</js2>.

regards,
John

At 12:16 PM 2/6/2001 -0500, Lee Rafalow wrote:
>John, Here are some responses to your comments on priorities and decision
>strategies.  Cheers, Lee
>
> > >  2.2.6. Priorities and Decision Strategies
> > >
> > > Drawing from both QPIM and ICIM, the priority property
> > > has been deprecated in PolicyRule, and placed instead on
> > > the associations PolicyRuleInPolicyGroup,
> > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
> > > PolicyRuleInPolicyRule. (Obvious question: would it be
> > > better to introduce a superclass
> > > PrioritizedPolicyComponent for these four associations,
> > > just to contain the priority property?  The answer is
> > > probably "yes".)  The QPIM rules for resolving relative
> > > priorities across nested PolicyGroups and PolicyRules
> > > have been incorporated into PCIMe as well.
> >
> > <js>
> > What's the point of having a PrioritizedPolicyComponent
> > aggregation (these are aggregations, not associations)? This
> > only makes sense if there is also a
> > NonPrioritizedPolicyComponent aggregation. Because
> > eventually, someone is going to want order or some other
> > semantic added to one or more of these aggregations, and
> > then we are going to have to go through the hell of
> > deprecating things again. Since this is clearly an
> > optimization, why not wait and get some implementation
> > experience first?
> > </js>
>
>Bob was, I think, correctly hinting at re-examining some of the inheritance
>hierarchy for a couple of classes.  While working on the section about
>decision strategies, I found myself writing about decision strategy sets,
>i.e., the abstraction for PolicyGroup and PolicyRule that contain other
>policy groups and rules and have a homogeneous decision strategy.  This
>abstraction is natural for the inheritance hierarchy in that a PolicySet
>(pick a better name of you like) is an abstraction for PolicyGroup and
>PolicyRule and it defines the PolicyDecisionStrategy property.  It would
>then have the PolicySetComponent aggregation (my rename of Bob's
>PrioritizedPolicyComponent) as an abstraction for the
>PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, PolicyRuleInPolicyGroup
>and PolicyRuleInPolicyRule aggregations wherein the Priority property is
>defined.  With the complexity being added to groups and rules, this
>abstraction makes it much easier to think about the concepts of decision
>strategies and priorities. I've asked the other authors to render an opinion
>on this suggestion but I haven't heard back yet.  Opinions from the broader
>community are also welcome.

<js2>
I didn't get any of this from Bob's message, and am still not sure I follow 
completely what you're proposing. So let me ask a couple of questions to 
ensure I understand.

   - you're proposing a new class, PolicySet, that is a collection
     that can contain PolicyGroups and PolicyRules.
     - is that ALL that it can contain?
     - what is the superclass of PolicySet?
   - you're proposing a new aggregation, PolicySetComponent
     - is this the superclass for the 4 existing
       PolicyGroup/RuleInPolicyGroup/Rule aggregations, or
       does it replace it?
   - are you still proposing to deprecate PolicyRule.Priority?
</js2>

> > > With the removal of the priority property from
> > > PolicyRule, a new modeling dependency has been
> > > introduced: in order to prioritize a PolicyRule
> > > relative to other PolicyRules, the rules must be
> > > placed in a PolicyGroup.
> >
> > <js>
> > I think you missed the reusable case. Assuming that you do
> > add explicit text saying that you can put anything in a
> > PolicyRepository, then what if you have a PolicyRule that
> > contains two reusable PolicyRules? Here, you use the
> > association (not aggregation)
> > PolicyElementInPolicyRepository to associate any subclass of
> > Policy to a PolicyRepository. Therefore, if you REALLY want
> > to do this, you should add the
> > PolicyElementInPolicyRepository association, defined in
> > QPIM, to PCIMe.
> >
> > Note that this produces a LOT of additional complexity. I'm
> > not sure it's a Good Thing. But the facility is there if you
> > want to explore it.
> > </js>
>
>What Bob missed in his summary was that rules can be in other rules in the
>proposed rule structure.  But the essential point that rules need a context
>to have priority is correct and, as a byproduct of the agreement to
>deprecate the use of PolicyRule.Priority, that context is proposed to be
>explicitly defined by the aggregation discussed above.

<js2>
A sub-rule, by definition, is already scoped by its parent rule. In other 
words, it already has a context.

In QPIM, we put decision strategies on containers, so that the container 
could establish a decision strategy for the rules that it contained. We 
combined this so that one could equate grouping with decision strategy. I 
don't see how you accomplish that with the PolicySet construct above. Can you?
</js2>

>PolicyElementInPolicyRepository has nothing to do with priority...the
>repository (or "ReusablePolicyContainer" or whatever we call it) does not
>establish a context for priority evaluation; it's simply a container for
>reusable policy components.  The context for priority is tied to the
>decision strategy on a containing group or rule.  Hopefully, this will all
>be clearer when I've written the section in the new draft.

<js2>
Let me try again. The point about PolicyElementInPolicyRepository is that 
you may want to include a reusable PolicyRule in your PolicySet. So how do 
you do this with your new constructs? You can't use your new 
PolicySetComponent aggregation, because its definition doesn't allow the 
inclusion of PolicyRepositories. Therefore, you either need to reuse 
PolicyElementInPolicyRepository or define a new association.
</js2>

> > >    In the absence of any clear, general criterion for
> > > detecting policy conflicts, the PCIM restriction stating
> > > that priorities are relevant only in the case of
> > > conflicts has been removed.  In its place, a
> > > DecisionStrategy property has been added to PolicyGroup
> > > class, to allow the policy administrator to select one
> > > of two behaviors with respect to rule evaluation: either
> > > perform the actions for all PolicyRules whose
> > > conditions evaluate to TRUE, or perform the actions
> > > only for the highest-priority PolicyRule whose conditions
> > > evaluate to TRUE. The QPIM rules for applying decision
> > > strategies to a nested set of PolicyGroups and
> > > PolicyRules were also imported.
> >
> > <js>
> > This begs the question, "What happens if there are multiple
> > PolicyRules of the same priority"? Then the DecisionStrategy
> > property doesn't help. So, looking at the paragraph below, I
> > *guess* that your answer would be that it doesn't matter
> > which PolicyRule executes, as long as only one executes.
> > This behavior is inconsistent with introducing the property
> > in the first place.
> > </js>
>
>Yes.  For "FirstMatching" only one rule gets executed, so if the submodel
>and adminstrator decide to permit non-deterministic rules, then it up to the
>implementation to decide which of the equal priority rules to execute when
>more than one matches.

<js2>
No! Why are we allowing non-deterministic behavior? As long as "the hood is 
open", why don't we prevent this?
</js2>

>I don't understand how this behavior is inconsistent with the introduction
>of a priority property.

<js2>
Priority implies no ties and deterministic behavior.
/js2>

>   I don't personally recommend that derived models
>permit non-deterministic priorities, but when they do, this is the only
>reasonable interpretation.

<js2>
No, a better interpretation is to prevent non-deterministic behavior in the 
first place.
</js2>

>   The PCIM notion that priority applies only to
>conflicts has two problems: 1) it doesn't explain the "FirstMatching" use of
>priority and 2) it relies on an undefined notion of "conflicting."  The
>obvious conflicts (e.g., set DSCP to x and set DSCP to y are still resolved
>by priority in both a FirstMatching and AllMatching strategy; either only
>one gets executed or both get executed and the one evaluated last wins (an
>interesting notion of priority, I admit).  Perhaps we should rename the
>Priority property to EvaluationOrder?  (We discussed this as well and
>decided to leave it alone, but I'm guessing we could be persuaded
>otherwise.)

<js2>
First, I would note that we can't define "conflicting" because a complete 
definition of "conflicting" is dependent on application-specific semantics, 
which by definition can't be standardized. Second, I would argue that PCIM 
does NOT say that the only purpose of priority is to provide conflict 
resolution. So as to how to resolve this, it depends on what you want to 
accomplish. Renaming Priority to EvaluationOrder would help emphasize that 
Priority is solely for determining the order of execution of rules. One use 
of this is to allow a policy rule to temporarily override another policy 
rule. This has **nothing** to do with conflict resolution. My fear is that 
there are already implementations out there that also use Priority for 
helping to resolve conflicts.

So, what did you want to accomplish? ;-)
</js2>

>Again, hopefully this will all be clear when I've written the section in the
>new draft.  We discussed having 3 decision strategies: FirstMatching,
>AllMatching, AllNonConflictingMatching and decided to only have two...unless
>someone can define the AllNonConflictingMatching strategy and the underlying
>definition of "conflicting."
>
> > >    The question of whether to require unique priority
> > > values for the PolicyRules in a PolicyGroup was raised and
> > > discussed, but the decision was to allow these values to
> > > collide within a PolicyGroup, to indicate "don't care".
> > > Submodels of PCIMe are free to add the restriction that
> > > priority values not collide within a PolicyGroup.
> > >



From majordomo@raleigh.ibm.com  Fri Feb  9 16:10:40 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02012
	for <policy-archive@odin.ietf.org>; Fri, 9 Feb 2001 16:10:39 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA29508;
	Fri, 9 Feb 2001 15:54:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA33324;
	Fri, 9 Feb 2001 15:54:30 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44256; Fri, 9 Feb 2001 15:28:15 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA47052; Fri, 9 Feb 2001 15:28:10 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA24742
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 15:28:11 -0500
Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA43884
	for <policy@raleigh.ibm.com>; Fri, 9 Feb 2001 14:45:16 -0500
Received: from ysnirnt70 (ysnir-isdn-home.cisco.com [10.49.112.178])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id VAA14801;
	Fri, 9 Feb 2001 21:36:46 +0200 (IST)
From: "Yoram Snir" <ysnir@cisco.com>
To: "'Mircea Pana'" <mpana@nortelnetworks.com>,
        "'policy'" <policy@raleigh.ibm.com>
Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn ical         meeting, 1/24/01 - 1/26/01)
Date: Fri, 9 Feb 2001 21:35:35 +0200
Message-Id: <005101c092cf$7bb48e90$b270310a@ysnirnt70>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0052_01C092E0.3F3D5E90"
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <28560036253BD41191A10000F8BCBD11841DC8@zcard00g.ca.nortel.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yoram Snir" <ysnir@cisco.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0052_01C092E0.3F3D5E90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: Decision Strategies (Re: Preliminary results from PCIMe technical
meeting, 1/24/01 - 1/26/01)IMO, policy set should be modeled by a policy
group with a set of rules with identical priority. I don't see the reason
for complicating this by adding another class.
Yoram,
  -----Original Message-----
  From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On
Behalf Of Mircea Pana
  Sent: Friday, February 09, 2001 1:19 AM
  To: 'ysnir'; 'policy'
  Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe techn
ical meeting, 1/24/01 - 1/26/01)


  I agree that the Priority should be placed on the association instead of
the container. What I actually intended to suggest is that (from the
component ordering point of view) there are two types of containers:
PolicySet and PolicySequence. Wrt. the Decision Strategy, a PolicySet should
be treated differently from a PolicySequence.

  IMO the Decision Strategy is not applicable to a Set (which should have a
"All" behavior), while it makes perfect sense on a PolicySequence. In
addition, a PolicySequence could be restricted to strict-ordering of its
components (equal priority not allowed), therefore avoiding the ambiguity
described by:
  > > <js>
  > > This begs the question, "What happens if there are multiple
  > > PolicyRules of the same priority"? Then the DecisionStrategy
  > > property doesn't help. So, looking at the paragraph below, I
  > > *guess* that your answer would be that it doesn't matter
  > > which PolicyRule executes, as long as only one executes.
  > > This behavior is inconsistent with introducing the property
  > > in the first place.
  > > </js>

  Thanks,
  Mircea.



    -----Original Message-----
    From: Yoram Snir [mailto:ysnir@cisco.com]
    Sent: Thursday, February 08, 2001 2:48 PM
    To: Pana, Mircea [CAR:5E20:EXCH]; 'policy'
    Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe
techn ical meeting, 1/24/01 - 1/26/01)


    IMO, the priority should be placed int he association and not with the
container.The obvious example for why the association is the right place is
when a policy rule is used with in 2 different policy groups. The priority
is a property of the association, not the container and not the rule (since
the same rule is used by different containers, in different sequence/
priority.
    Yoram
      -----Original Message-----
      From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mircea Pana
      Sent: Tuesday, February 06, 2001 11:02 PM
      To: policy
      Subject: RE: Decision Strategies (Re: Preliminary results from PCIMe
techn ical meeting, 1/24/01 - 1/26/01)


      My 2c. worth comments on Priority:

      The "migration" of the Priority property from PolicyRule (in QPIM also
present in a gpsPolicyGroup) to the PolicyXXXInPolicyXXX (or PolicySet, or
PrioritizedPolicyComponent) changes its aspect from global to local. This,
definitely, makes it more flexible.

      However, IMO, the focus should be placed on the container instead of
its components. I.e. The concept required here is a container with
*sequenced* policy components (I would call it: PolicySequence). The
Priority property, placed on the associations is just a way to implement it.

      For example:
      Consider a PolicyGroup with two PolicyRules as components: PR1 (higher
priority) and PR2 (lowed priority). The results of applying this PolicyGroup
to a policy target is the same in all the following cases:

      - 100 (PR1) and 1 (PR2)
      - 2 (PR1) and 1 (PR2)
      - or "HIGH" (PR1) and "LOW" (PR2)
      the only thing that matters is the sequence.

      I also realize that in some cases the order is not important. In such
cases a PolicySet would be the appropriate concept.

      Regards,
      Mircea.




      > -----Original Message-----
      > From: Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
      > Sent: Tuesday, February 06, 2001 12:17 PM
      > To: policy
      > Subject: Decision Strategies (Re: Preliminary results from PCIMe
      > technical meeting, 1/24/01 - 1/26/01)
      >
      >
      > John, Here are some responses to your comments on priorities
      > and decision
      > strategies.  Cheers, Lee
      >
      > > >  2.2.6. Priorities and Decision Strategies
      > > >
      > > > Drawing from both QPIM and ICIM, the priority property
      > > > has been deprecated in PolicyRule, and placed instead on
      > > > the associations PolicyRuleInPolicyGroup,
      > > > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule, and
      > > > PolicyRuleInPolicyRule. (Obvious question: would it be
      > > > better to introduce a superclass
      > > > PrioritizedPolicyComponent for these four associations,
      > > > just to contain the priority property?  The answer is
      > > > probably "yes".)  The QPIM rules for resolving relative
      > > > priorities across nested PolicyGroups and PolicyRules
      > > > have been incorporated into PCIMe as well.
      > >
      > > <js>
      > > What's the point of having a PrioritizedPolicyComponent
      > > aggregation (these are aggregations, not associations)? This
      > > only makes sense if there is also a
      > > NonPrioritizedPolicyComponent aggregation. Because
      > > eventually, someone is going to want order or some other
      > > semantic added to one or more of these aggregations, and
      > > then we are going to have to go through the hell of
      > > deprecating things again. Since this is clearly an
      > > optimization, why not wait and get some implementation
      > > experience first?
      > > </js>
      >
      > Bob was, I think, correctly hinting at re-examining some of
      > the inheritance
      > hierarchy for a couple of classes.  While working on the section
about
      > decision strategies, I found myself writing about decision
      > strategy sets,
      > i.e., the abstraction for PolicyGroup and PolicyRule that
      > contain other
      > policy groups and rules and have a homogeneous decision
      > strategy.  This
      > abstraction is natural for the inheritance hierarchy in that
      > a PolicySet
      > (pick a better name of you like) is an abstraction for PolicyGroup
and
      > PolicyRule and it defines the PolicyDecisionStrategy
      > property.  It would
      > then have the PolicySetComponent aggregation (my rename of Bob's
      > PrioritizedPolicyComponent) as an abstraction for the
      > PolicyGroupInPolicyGroup, PolicyGroupInPolicyRule,
      > PolicyRuleInPolicyGroup
      > and PolicyRuleInPolicyRule aggregations wherein the Priority
      > property is
      > defined.  With the complexity being added to groups and rules, this
      > abstraction makes it much easier to think about the concepts
      > of decision
      > strategies and priorities. I've asked the other authors to
      > render an opinion
      > on this suggestion but I haven't heard back yet.  Opinions
      > from the broader
      > community are also welcome.
      >
      > > > With the removal of the priority property from
      > > > PolicyRule, a new modeling dependency has been
      > > > introduced: in order to prioritize a PolicyRule
      > > > relative to other PolicyRules, the rules must be
      > > > placed in a PolicyGroup.
      > >
      > > <js>
      > > I think you missed the reusable case. Assuming that you do
      > > add explicit text saying that you can put anything in a
      > > PolicyRepository, then what if you have a PolicyRule that
      > > contains two reusable PolicyRules? Here, you use the
      > > association (not aggregation)
      > > PolicyElementInPolicyRepository to associate any subclass of
      > > Policy to a PolicyRepository. Therefore, if you REALLY want
      > > to do this, you should add the
      > > PolicyElementInPolicyRepository association, defined in
      > > QPIM, to PCIMe.
      > >
      > > Note that this produces a LOT of additional complexity. I'm
      > > not sure it's a Good Thing. But the facility is there if you
      > > want to explore it.
      > > </js>
      >
      > What Bob missed in his summary was that rules can be in other
      > rules in the
      > proposed rule structure.  But the essential point that rules
      > need a context
      > to have priority is correct and, as a byproduct of the agreement to
      > deprecate the use of PolicyRule.Priority, that context is
      > proposed to be
      > explicitly defined by the aggregation discussed above.
      > PolicyElementInPolicyRepository has nothing to do with
priority...the
      > repository (or "ReusablePolicyContainer" or whatever we call
      > it) does not
      > establish a context for priority evaluation; it's simply a
      > container for
      > reusable policy components.  The context for priority is tied to the
      > decision strategy on a containing group or rule.  Hopefully,
      > this will all
      > be clearer when I've written the section in the new draft.
      >
      > > >    In the absence of any clear, general criterion for
      > > > detecting policy conflicts, the PCIM restriction stating
      > > > that priorities are relevant only in the case of
      > > > conflicts has been removed.  In its place, a
      > > > DecisionStrategy property has been added to PolicyGroup
      > > > class, to allow the policy administrator to select one
      > > > of two behaviors with respect to rule evaluation: either
      > > > perform the actions for all PolicyRules whose
      > > > conditions evaluate to TRUE, or perform the actions
      > > > only for the highest-priority PolicyRule whose conditions
      > > > evaluate to TRUE. The QPIM rules for applying decision
      > > > strategies to a nested set of PolicyGroups and
      > > > PolicyRules were also imported.
      > >
      > > <js>
      > > This begs the question, "What happens if there are multiple
      > > PolicyRules of the same priority"? Then the DecisionStrategy
      > > property doesn't help. So, looking at the paragraph below, I
      > > *guess* that your answer would be that it doesn't matter
      > > which PolicyRule executes, as long as only one executes.
      > > This behavior is inconsistent with introducing the property
      > > in the first place.
      > > </js>
      >
      > Yes.  For "FirstMatching" only one rule gets executed, so if
      > the submodel
      > and adminstrator decide to permit non-deterministic rules,
      > then it up to the
      > implementation to decide which of the equal priority rules to
      > execute when
      > more than one matches.
      >
      > I don't understand how this behavior is inconsistent with the
      > introduction
      > of a priority property.  I don't personally recommend that
      > derived models
      > permit non-deterministic priorities, but when they do, this
      > is the only
      > reasonable interpretation.  The PCIM notion that priority
      > applies only to
      > conflicts has two problems: 1) it doesn't explain the
      > "FirstMatching" use of
      > priority and 2) it relies on an undefined notion of
      > "conflicting."  The
      > obvious conflicts (e.g., set DSCP to x and set DSCP to y are
      > still resolved
      > by priority in both a FirstMatching and AllMatching strategy;
      > either only
      > one gets executed or both get executed and the one evaluated
      > last wins (an
      > interesting notion of priority, I admit).  Perhaps we should
      > rename the
      > Priority property to EvaluationOrder?  (We discussed this as well
and
      > decided to leave it alone, but I'm guessing we could be persuaded
      > otherwise.)
      >
      > Again, hopefully this will all be clear when I've written the
      > section in the
      > new draft.  We discussed having 3 decision strategies:
FirstMatching,
      > AllMatching, AllNonConflictingMatching and decided to only
      > have two...unless
      > someone can define the AllNonConflictingMatching strategy and
      > the underlying
      > definition of "conflicting."
      >
      > > >    The question of whether to require unique priority
      > > > values for the PolicyRules in a PolicyGroup was raised and
      > > > discussed, but the decision was to allow these values to
      > > > collide within a PolicyGroup, to indicate "don't care".
      > > > Submodels of PCIMe are free to add the restriction that
      > > > priority values not collide within a PolicyGroup.
      > > >
      >
      >
      >


------=_NextPart_000_0052_01C092E0.3F3D5E90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Decision Strategies (Re: Preliminary results from PCIMe =
technical meeting, 1/24/01 - 1/26/01)</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D284123419-09022001>IMO,=20
policy set should be modeled by a policy group with a set of rules with=20
identical priority. I don't see the reason for complicating this by =
adding=20
another class.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D284123419-09022001>Yoram,</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
policy-owner@raleigh.ibm.com=20
  [mailto:policy-owner@raleigh.ibm.com]<B>On Behalf Of</B> Mircea=20
  Pana<BR><B>Sent:</B> Friday, February 09, 2001 1:19 AM<BR><B>To:</B> =
'ysnir';=20
  'policy'<BR><B>Subject:</B> RE: Decision Strategies (Re: Preliminary =
results=20
  from PCIMe techn ical meeting, 1/24/01 - 1/26/01)<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064165422-08022001>I=20
  agree that the&nbsp;Priority should be placed on the association =
instead of=20
  the container. What I actually intended to suggest is that (from the =
component=20
  ordering point of view) there are two types of containers: PolicySet =
and=20
  PolicySequence. Wrt. the Decision Strategy, a PolicySet&nbsp;should be =
treated=20
  differently from a PolicySequence.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D064165422-08022001>IMO=20
  the Decision Strategy is not applicable to a Set (which =
should&nbsp;have a=20
  "All" behavior), while it makes perfect sense on a=20
  PolicySequence.</SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
  class=3D064165422-08022001> In addition,&nbsp;a PolicySequence could =
be=20
  restricted&nbsp;to strict-ordering of its components (equal priority =
not=20
  allowed), therefore avoiding the ambiguity described =
by:</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001><FONT size=3D2>&gt; &gt; &lt;js&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; This begs the question, "What happens if there are=20
  multiple</FONT> <BR><FONT size=3D2>&gt; &gt; PolicyRules of the same =
priority"?=20
  Then the DecisionStrategy</FONT> <BR><FONT size=3D2>&gt; &gt; property =
doesn't=20
  help. So, looking at the paragraph below, I</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  *guess* that your answer would be that it doesn't matter</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; which PolicyRule executes, as long as only one=20
  executes.</FONT> <BR><FONT size=3D2>&gt; &gt; This behavior is =
inconsistent with=20
  introducing the property</FONT> <BR><FONT size=3D2>&gt; &gt; in the =
first=20
  place.</FONT> <BR><FONT size=3D2>&gt; &gt; &lt;/js&gt;</FONT>=20
  <BR></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001>Mircea.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001>&nbsp;</DIV></SPAN></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D064165422-08022001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Yoram Snir=20
    [mailto:ysnir@cisco.com]<BR><B>Sent:</B> Thursday, February 08, 2001 =
2:48=20
    PM<BR><B>To:</B> Pana, Mircea [CAR:5E20:EXCH]; =
'policy'<BR><B>Subject:</B>=20
    RE: Decision Strategies (Re: Preliminary results from PCIMe techn =
ical=20
    meeting, 1/24/01 - 1/26/01)<BR><BR></DIV></FONT>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D882114319-08022001>IMO, the priority should be placed int he =

    association and not with the container.The obvious example for why =
the=20
    association is the right place is when a policy rule is used with in =
2=20
    different policy groups. The priority is a property of the =
association, not=20
    the container and not the rule (since the same rule is used by =
different=20
    containers, in different sequence/ priority.</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D882114319-08022001>Yoram</SPAN></FONT></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
      size=3D2>-----Original Message-----<BR><B>From:</B>=20
      policy-owner@raleigh.ibm.com =
[mailto:policy-owner@raleigh.ibm.com]<B>On=20
      Behalf Of</B> Mircea Pana<BR><B>Sent:</B> Tuesday, February 06, =
2001 11:02=20
      PM<BR><B>To:</B> policy<BR><B>Subject:</B> RE: Decision Strategies =
(Re:=20
      Preliminary results from PCIMe techn ical meeting, 1/24/01 -=20
      1/26/01)<BR><BR></DIV></FONT>
      <P><FONT size=3D2>My 2c. worth comments on Priority:</FONT> </P>
      <P><FONT size=3D2>The "migration" of the Priority property from =
PolicyRule=20
      (in QPIM also present in a gpsPolicyGroup) to the =
PolicyXXXInPolicyXXX (or=20
      PolicySet, or PrioritizedPolicyComponent) changes its aspect from =
global=20
      to local. This, definitely, makes it more flexible.</FONT></P>
      <P><FONT size=3D2>However, IMO, the focus should be placed on the =
container=20
      instead of its components. I.e. The concept required here is a =
container=20
      with *sequenced* policy components (I would call it: =
PolicySequence). The=20
      Priority property, placed on the associations is just a way to =
implement=20
      it.</FONT></P>
      <P><FONT size=3D2>For example:</FONT> <BR><FONT size=3D2>Consider =
a=20
      PolicyGroup with two PolicyRules as components: PR1 (higher =
priority) and=20
      PR2 (lowed priority). The results of applying this PolicyGroup to =
a policy=20
      target is the same in all the following cases:</FONT></P>
      <P><FONT size=3D2>- 100 (PR1) and 1 (PR2)</FONT> <BR><FONT =
size=3D2>- 2 (PR1)=20
      and 1 (PR2)</FONT> <BR><FONT size=3D2>- or "HIGH" (PR1) and "LOW"=20
      (PR2)</FONT> <BR><FONT size=3D2>the only thing that matters is the =

      sequence.</FONT> </P>
      <P><FONT size=3D2>I also realize that in some cases the order is =
not=20
      important. In such cases a PolicySet would be the appropriate=20
      concept.</FONT></P>
      <P><FONT size=3D2>Regards,</FONT> <BR><FONT =
size=3D2>Mircea.</FONT>=20
      </P><BR><BR>
      <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =

      size=3D2>&gt; From: Lee Rafalow [<A=20
      =
href=3D"mailto:rafalow@raleigh.ibm.com">mailto:rafalow@raleigh.ibm.com</A=
>]</FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Tuesday, February 06, 2001 12:17 =
PM</FONT>=20
      <BR><FONT size=3D2>&gt; To: policy</FONT> <BR><FONT size=3D2>&gt; =
Subject:=20
      Decision Strategies (Re: Preliminary results from PCIMe</FONT> =
<BR><FONT=20
      size=3D2>&gt; technical meeting, 1/24/01 - 1/26/01)</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
      John, Here are some responses to your comments on priorities=20
      </FONT><BR><FONT size=3D2>&gt; and decision</FONT> <BR><FONT =
size=3D2>&gt;=20
      strategies.&nbsp; Cheers, Lee</FONT> <BR><FONT size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&nbsp; 2.2.6. Priorities =
and=20
      Decision Strategies</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; Drawing from both QPIM and ICIM, =
the=20
      priority property</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; has =
been=20
      deprecated in PolicyRule, and placed instead on</FONT> <BR><FONT=20
      size=3D2>&gt; &gt; &gt; the associations =
PolicyRuleInPolicyGroup,</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; PolicyGroupInPolicyGroup,=20
      PolicyGroupInPolicyRule, and</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
      PolicyRuleInPolicyRule. (Obvious question: would it be</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; better to introduce a superclass</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; PrioritizedPolicyComponent for these four=20
      associations,</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; just to =
contain the=20
      priority property?&nbsp; The answer is</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      &gt; probably "yes".)&nbsp; The QPIM rules for resolving =
relative</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; priorities across nested =
PolicyGroups and=20
      PolicyRules</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; have been =
incorporated=20
      into PCIMe as well.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &lt;js&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
What's the=20
      point of having a PrioritizedPolicyComponent</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; aggregation (these are aggregations, not associations)? =
This</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; only makes sense if there is also =
a</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; NonPrioritizedPolicyComponent =
aggregation.=20
      Because</FONT> <BR><FONT size=3D2>&gt; &gt; eventually, someone is =
going to=20
      want order or some other</FONT> <BR><FONT size=3D2>&gt; &gt; =
semantic added=20
      to one or more of these aggregations, and</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; then we are going to have to go through the hell of</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; deprecating things again. Since this is clearly =
an</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; optimization, why not wait and get =
some=20
      implementation</FONT> <BR><FONT size=3D2>&gt; &gt; experience =
first?</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; Bob was, I think, correctly hinting =
at=20
      re-examining some of </FONT><BR><FONT size=3D2>&gt; the =
inheritance</FONT>=20
      <BR><FONT size=3D2>&gt; hierarchy for a couple of classes.&nbsp; =
While=20
      working on the section about</FONT> <BR><FONT size=3D2>&gt; =
decision=20
      strategies, I found myself writing about decision </FONT><BR><FONT =

      size=3D2>&gt; strategy sets,</FONT> <BR><FONT size=3D2>&gt; i.e., =
the=20
      abstraction for PolicyGroup and PolicyRule that </FONT><BR><FONT=20
      size=3D2>&gt; contain other</FONT> <BR><FONT size=3D2>&gt; policy =
groups and=20
      rules and have a homogeneous decision </FONT><BR><FONT =
size=3D2>&gt;=20
      strategy.&nbsp; This</FONT> <BR><FONT size=3D2>&gt; abstraction is =
natural=20
      for the inheritance hierarchy in that </FONT><BR><FONT =
size=3D2>&gt; a=20
      PolicySet</FONT> <BR><FONT size=3D2>&gt; (pick a better name of =
you like) is=20
      an abstraction for PolicyGroup and</FONT> <BR><FONT size=3D2>&gt; =
PolicyRule=20
      and it defines the PolicyDecisionStrategy </FONT><BR><FONT =
size=3D2>&gt;=20
      property.&nbsp; It would</FONT> <BR><FONT size=3D2>&gt; then have =
the=20
      PolicySetComponent aggregation (my rename of Bob's</FONT> =
<BR><FONT=20
      size=3D2>&gt; PrioritizedPolicyComponent) as an abstraction for =
the</FONT>=20
      <BR><FONT size=3D2>&gt; PolicyGroupInPolicyGroup, =
PolicyGroupInPolicyRule,=20
      </FONT><BR><FONT size=3D2>&gt; PolicyRuleInPolicyGroup</FONT> =
<BR><FONT=20
      size=3D2>&gt; and PolicyRuleInPolicyRule aggregations wherein the =
Priority=20
      </FONT><BR><FONT size=3D2>&gt; property is</FONT> <BR><FONT =
size=3D2>&gt;=20
      defined.&nbsp; With the complexity being added to groups and =
rules,=20
      this</FONT> <BR><FONT size=3D2>&gt; abstraction makes it much =
easier to=20
      think about the concepts </FONT><BR><FONT size=3D2>&gt; of =
decision</FONT>=20
      <BR><FONT size=3D2>&gt; strategies and priorities. I've asked the =
other=20
      authors to </FONT><BR><FONT size=3D2>&gt; render an opinion</FONT> =
<BR><FONT=20
      size=3D2>&gt; on this suggestion but I haven't heard back =
yet.&nbsp;=20
      Opinions </FONT><BR><FONT size=3D2>&gt; from the broader</FONT> =
<BR><FONT=20
      size=3D2>&gt; community are also welcome.</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; &gt; With the removal of the =
priority=20
      property from</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; PolicyRule, =
a new=20
      modeling dependency has been</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
      introduced: in order to prioritize a PolicyRule</FONT> <BR><FONT=20
      size=3D2>&gt; &gt; &gt; relative to other PolicyRules, the rules =
must=20
      be</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; placed in a =
PolicyGroup.</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt;=20
      &lt;js&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; I think you missed =
the=20
      reusable case. Assuming that you do</FONT> <BR><FONT size=3D2>&gt; =
&gt; add=20
      explicit text saying that you can put anything in a</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; PolicyRepository, then what if you have a =
PolicyRule=20
      that</FONT> <BR><FONT size=3D2>&gt; &gt; contains two reusable =
PolicyRules?=20
      Here, you use the</FONT> <BR><FONT size=3D2>&gt; &gt; association =
(not=20
      aggregation)</FONT> <BR><FONT size=3D2>&gt; &gt;=20
      PolicyElementInPolicyRepository to associate any subclass =
of</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; Policy to a PolicyRepository. =
Therefore, if you=20
      REALLY want</FONT> <BR><FONT size=3D2>&gt; &gt; to do this, you =
should add=20
      the</FONT> <BR><FONT size=3D2>&gt; &gt; =
PolicyElementInPolicyRepository=20
      association, defined in</FONT> <BR><FONT size=3D2>&gt; &gt; QPIM, =
to=20
      PCIMe.</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      Note that this produces a LOT of additional complexity. I'm</FONT> =

      <BR><FONT size=3D2>&gt; &gt; not sure it's a Good Thing. But the =
facility is=20
      there if you</FONT> <BR><FONT size=3D2>&gt; &gt; want to explore =
it.</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; What Bob missed in his summary was =
that rules=20
      can be in other </FONT><BR><FONT size=3D2>&gt; rules in the</FONT> =
<BR><FONT=20
      size=3D2>&gt; proposed rule structure.&nbsp; But the essential =
point that=20
      rules </FONT><BR><FONT size=3D2>&gt; need a context</FONT> =
<BR><FONT=20
      size=3D2>&gt; to have priority is correct and, as a byproduct of =
the=20
      agreement to</FONT> <BR><FONT size=3D2>&gt; deprecate the use of=20
      PolicyRule.Priority, that context is </FONT><BR><FONT =
size=3D2>&gt; proposed=20
      to be</FONT> <BR><FONT size=3D2>&gt; explicitly defined by the =
aggregation=20
      discussed above.</FONT> <BR><FONT size=3D2>&gt;=20
      PolicyElementInPolicyRepository has nothing to do with=20
      priority...the</FONT> <BR><FONT size=3D2>&gt; repository (or=20
      "ReusablePolicyContainer" or whatever we call </FONT><BR><FONT =
size=3D2>&gt;=20
      it) does not</FONT> <BR><FONT size=3D2>&gt; establish a context =
for priority=20
      evaluation; it's simply a </FONT><BR><FONT size=3D2>&gt; container =

      for</FONT> <BR><FONT size=3D2>&gt; reusable policy =
components.&nbsp; The=20
      context for priority is tied to the</FONT> <BR><FONT size=3D2>&gt; =
decision=20
      strategy on a containing group or rule.&nbsp; Hopefully, =
</FONT><BR><FONT=20
      size=3D2>&gt; this will all</FONT> <BR><FONT size=3D2>&gt; be =
clearer when=20
      I've written the section in the new draft.</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; In the =
absence of=20
      any clear, general criterion for</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
      detecting policy conflicts, the PCIM restriction stating</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; that priorities are relevant only in the =
case=20
      of</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; conflicts has been=20
      removed.&nbsp; In its place, a</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
      DecisionStrategy property has been added to PolicyGroup</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; class, to allow the policy administrator =
to select=20
      one</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; of two behaviors with =
respect=20
      to rule evaluation: either</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt; perform=20
      the actions for all PolicyRules whose</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      &gt; conditions evaluate to TRUE, or perform the actions</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt; only for the highest-priority PolicyRule =
whose=20
      conditions</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; evaluate to =
TRUE. The=20
      QPIM rules for applying decision</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
      strategies to a nested set of PolicyGroups and</FONT> <BR><FONT=20
      size=3D2>&gt; &gt; &gt; PolicyRules were also imported.</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&lt;js&gt;</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; This begs the question, "What happens =
if there=20
      are multiple</FONT> <BR><FONT size=3D2>&gt; &gt; PolicyRules of =
the same=20
      priority"? Then the DecisionStrategy</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      property doesn't help. So, looking at the paragraph below, =
I</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; *guess* that your answer would be =
that it=20
      doesn't matter</FONT> <BR><FONT size=3D2>&gt; &gt; which =
PolicyRule=20
      executes, as long as only one executes.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      This behavior is inconsistent with introducing the property</FONT> =

      <BR><FONT size=3D2>&gt; &gt; in the first place.</FONT> <BR><FONT=20
      size=3D2>&gt; &gt; &lt;/js&gt;</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; Yes.&nbsp; For "FirstMatching" only one rule gets =
executed, so=20
      if </FONT><BR><FONT size=3D2>&gt; the submodel</FONT> <BR><FONT =
size=3D2>&gt;=20
      and adminstrator decide to permit non-deterministic rules,=20
      </FONT><BR><FONT size=3D2>&gt; then it up to the</FONT> <BR><FONT=20
      size=3D2>&gt; implementation to decide which of the equal priority =
rules to=20
      </FONT><BR><FONT size=3D2>&gt; execute when</FONT> <BR><FONT =
size=3D2>&gt;=20
      more than one matches.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; I don't understand how this behavior is inconsistent =
with the=20
      </FONT><BR><FONT size=3D2>&gt; introduction</FONT> <BR><FONT =
size=3D2>&gt; of=20
      a priority property.&nbsp; I don't personally recommend that=20
      </FONT><BR><FONT size=3D2>&gt; derived models</FONT> <BR><FONT =
size=3D2>&gt;=20
      permit non-deterministic priorities, but when they do, this=20
      </FONT><BR><FONT size=3D2>&gt; is the only</FONT> <BR><FONT =
size=3D2>&gt;=20
      reasonable interpretation.&nbsp; The PCIM notion that priority=20
      </FONT><BR><FONT size=3D2>&gt; applies only to</FONT> <BR><FONT =
size=3D2>&gt;=20
      conflicts has two problems: 1) it doesn't explain the =
</FONT><BR><FONT=20
      size=3D2>&gt; "FirstMatching" use of</FONT> <BR><FONT =
size=3D2>&gt; priority=20
      and 2) it relies on an undefined notion of </FONT><BR><FONT =
size=3D2>&gt;=20
      "conflicting."&nbsp; The</FONT> <BR><FONT size=3D2>&gt; obvious =
conflicts=20
      (e.g., set DSCP to x and set DSCP to y are </FONT><BR><FONT =
size=3D2>&gt;=20
      still resolved</FONT> <BR><FONT size=3D2>&gt; by priority in both =
a=20
      FirstMatching and AllMatching strategy; </FONT><BR><FONT =
size=3D2>&gt;=20
      either only</FONT> <BR><FONT size=3D2>&gt; one gets executed or =
both get=20
      executed and the one evaluated </FONT><BR><FONT size=3D2>&gt; last =
wins=20
      (an</FONT> <BR><FONT size=3D2>&gt; interesting notion of priority, =
I=20
      admit).&nbsp; Perhaps we should </FONT><BR><FONT size=3D2>&gt; =
rename=20
      the</FONT> <BR><FONT size=3D2>&gt; Priority property to=20
      EvaluationOrder?&nbsp; (We discussed this as well and</FONT> =
<BR><FONT=20
      size=3D2>&gt; decided to leave it alone, but I'm guessing we could =
be=20
      persuaded</FONT> <BR><FONT size=3D2>&gt; otherwise.)</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Again, hopefully this =
will all be=20
      clear when I've written the </FONT><BR><FONT size=3D2>&gt; section =
in=20
      the</FONT> <BR><FONT size=3D2>&gt; new draft.&nbsp; We discussed =
having 3=20
      decision strategies: FirstMatching,</FONT> <BR><FONT size=3D2>&gt; =

      AllMatching, AllNonConflictingMatching and decided to only=20
      </FONT><BR><FONT size=3D2>&gt; have two...unless</FONT> <BR><FONT=20
      size=3D2>&gt; someone can define the AllNonConflictingMatching =
strategy and=20
      </FONT><BR><FONT size=3D2>&gt; the underlying</FONT> <BR><FONT =
size=3D2>&gt;=20
      definition of "conflicting."</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; The question of whether =
to require=20
      unique priority</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; values =
for the=20
      PolicyRules in a PolicyGroup was raised and</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; &gt; discussed, but the decision was to allow these values =
to</FONT>=20
      <BR><FONT size=3D2>&gt; &gt; &gt; collide within a PolicyGroup, to =
indicate=20
      "don't care".</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; Submodels =
of PCIMe=20
      are free to add the restriction that</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      &gt; priority values not collide within a PolicyGroup.</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0052_01C092E0.3F3D5E90--



From majordomo@raleigh.ibm.com  Wed Feb 14 03:47:34 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24959
	for <policy-archive@odin.ietf.org>; Wed, 14 Feb 2001 03:47:34 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA19736;
	Wed, 14 Feb 2001 03:23:59 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA29184;
	Wed, 14 Feb 2001 03:19:59 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27484; Wed, 14 Feb 2001 02:37:45 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54248; Wed, 14 Feb 2001 02:37:33 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA28060
	for <policy@raleigh.ibm.com>; Wed, 14 Feb 2001 02:37:33 -0500
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA33868
	for <policy@raleigh.ibm.com>; Wed, 14 Feb 2001 02:37:28 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA16227;
	Tue, 13 Feb 2001 23:37:04 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-123.cisco.com [171.68.181.252])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ALB24631;
	Tue, 13 Feb 2001 23:36:44 -0800 (PST)
Message-Id: <4.3.2.7.2.20010213113819.00b64bb0@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 13 Feb 2001 11:50:44 -0800
To: "Joel M. Halpern" <joel@longsys.com>
From: John Strassner <jstrassn@cisco.com>
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe
  technical meeting, 1/24/01 - 1/26/01)
Cc: John Strassner <jstrassn@cisco.com>, "Robert Moore" <remoore@us.ibm.com>,
        <policy@raleigh.ibm.com>, johns@cisco.com
In-Reply-To: <4.2.2.20010209133237.00bbba00@localhost>
References: <4.3.2.7.2.20010207111219.00b13368@mira-sjcm-1.cisco.com>
 <OFBB76AE44.2FF5D4DA-ON852569EB.0067B982@raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Hi Joel,

Let me see if I understand your point. Looking at the current version of 
QDDIM, I see the following class inheritance:

...
   FilterEntryBase
     FilterEntry
       IP6TupleFilter
       8021Filter
         8021PQFilter

This is relevant because every property in these classes EXCEPT ONE 
(OtherMatchCondition) is defined. There is NO flexibility in this model, 
beyond the simple ability to aggregate different instances of the classes 
together to form a new filter.

In that respect, the QPIM model of using expressions with constraints is a 
LOT more flexible.

I think what you're asking for is limitations on QPIM such that we can be 
assured of a bi-directional mapping. The problem is that QDDIM defines some 
attributes that aren't explicitly defined in QPIM, and vice-versa. I would 
argue that this in and of itself isn't the problem, as such attributes can 
be easily added. What the real problem is that QPIM has introduced several 
notions that are completely lacking in QDDIM:

   - constraining the values of a variable or constant
   - constraining the data types of a variable or constant
   - binding a variable to a value

Is it these things that you are worried about, or something else?

regards,
John

At 01:35 PM 2/9/2001 -0500, Joel M. Halpern wrote:
>Actually, we need to be careful about the phrase "map between the two".
>1) One can create variable condition expressions to represent (with 
>suitable variables) filters
>2) For variable expressions that correspond to filters, one can (usually) 
>create the filter.
>
>However, it is certainly not the case that all variable conditions can be 
>reasonably expressed in the filter mechanisms that we are looking at.  One 
>of the nice things about filters and filter classes is that you can 
>describe what set of filters the underlying system can support.  Simply 
>describing what set of variables can be tested in expressions does not 
>give one the same level of clarity.  Hence, we will probably find 
>ourselves needing to write somewhere textual restrictions on the variable 
>expressions if we want them to be "mappable" to useable filters.
>
>Yours,
>Joel M. Halpern
>
>At 11:19 AM 2/7/01 -0800, John Strassner wrote:
>
>>Bob,
>>
>>first, I didn't think that people were asking us to pick one method. This 
>>is dictatorial without due cause. If one can map between the two, which 
>>you agreed could be done in your note, why not let people choose what 
>>method is most appropriate for their application? I don't think we'll 
>>ever be able to say that one method is better than the other, because 
>>applications will use these tools differently.
>>
>>Furthermore, I don't understand your reasoning. First, you say that 
>>people want us to pick one method. Then, you say that it is perfectly 
>>acceptable for us to have one method in PCIMe and another method in ICIM. 
>>This contradicts your goal of having us pick one.
>>
>>In addition, I don't understand the point of your message, unless it was 
>>to underscore that PCIMe didn't do what people wanted. My point was 
>>simply that the two mechanisms are equivalent and either could be used in 
>>a given application. Since that is what is happening, why can't we just 
>>document that?
>>
>>John
>>
>>p.s.: still waiting for responses on my other points...
>>
>>At 02:13 PM 2/6/2001 -0500, Robert Moore wrote:
>>>John,
>>>
>>>Here are your comments on the "Packet Filtering" section
>>>of my PCIMe note.  My responses are below your comments.
>>>
>>>
>>> >  2.2.5. Packet Filtering
>>> >
>>> >    For packet filtering done in the context of a
>>> > PolicyCondition, a set of PolicyVariables and
>>> > PolicyValues were defined, corresponding to the
>>> > fields in an IP packet header plus the most common
>>> > Layer 2 frame header fields.  It is expected that policy
>>> > conditions that filter on these header fields will be
>>> > expressed in terms of CompoundPolicyConditions built up
>>> > from SimplePolicyConditions that use these variables and
>>> > values.
>>> > An additional PolicyVariable, PacketDirection, was also
>>> > defined, to indicate whether a packet being filtered is
>>> > traveling inbound or outbound on an interface.
>>> >
>>> >    For packet filtering in other contexts (specifically,
>>> > for the packet classifier filters modeled in QDDIM),
>>> > these variables and values need not be used.  Filter
>>> > classes derived from the CIM FilterEntryBase class
>>> > hierarchy may still be used in these contexts.
>>>
>>><js>
>>>This last sentence is misleading. One can easily define
>>>equivalences between the FilterEntry.MatchConditionType and
>>>the PolicyVariable classes and also between the
>>>FilterEntry.MatchConditionValue and the PolicyValue classes.
>>>The perception that PolicyVariables and PolicyValues somehow
>>>break FilterEntries is just plain wrong.
>>>
>>>Perhaps some additional wording to this effect should be
>>>included in PCIMe. The designer can specify a filter using
>>>either FilterEntries and/or {variable, operator, value}
>>>triplets.
>>></js>
>>>
>>>I'm not sure I understand your basic point here, since
>>>I think it's been a given all along that one can construct
>>>equivalent filters using the two technologies.  I thought
>>>that what people were asking us to do was simply to pick
>>>one or the other mechanism as *the* way to represent
>>>packet filtering for all IP-related policy models.
>>>
>>>So, people asked us to pick one method or the other, and we
>>>didn't quite do that.  We picked Variables&Values for
>>>filters in Policy Conditions, but left FilterEntries as an
>>>option for non-policy contexts like QDDIM.  This is what
>>>we've proposed for PCIMe to say.
>>>
>>>There's also the reality of staging, stability, and
>>>schedules.  Even if PCIMe is going to end up saying that
>>>Policy Conditions SHALL use Variables&Values to represent
>>>packet filters, Lee and Jamie have elected to say that
>>>for March, at least, ICIM is too far down the FilterEntry
>>>path to change at this point.  So we'll have the anomaly
>>>in ICIM of Policy Conditions that do packet filtering
>>>using FilterEntries rather than Variables&Values.
>>>
>>>Bottom line:  I think that your last sentence ("The
>>>designer can specify a filter using either FilterEntries
>>>and/or {variable, operator, value} triplets.") is
>>>precisely what people *don't* want PCIMe to say.  Even if
>>>we have to hedge it a little, I think they would rather
>>>have us make a choice one way or the other.
>>>
>>>Regards,
>>>Bob
>>>
>>>Bob Moore
>>>IBM Networking Software
>>>+1-919-254-4436
>>>remoore@us.ibm.com



From majordomo@raleigh.ibm.com  Wed Feb 14 12:04:30 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07158
	for <policy-archive@odin.ietf.org>; Wed, 14 Feb 2001 12:04:30 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA23336;
	Wed, 14 Feb 2001 11:57:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA31150;
	Wed, 14 Feb 2001 11:57:21 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37816; Wed, 14 Feb 2001 11:18:52 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37796; Wed, 14 Feb 2001 11:18:48 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27046
	for <policy@raleigh.ibm.com>; Wed, 14 Feb 2001 11:18:52 -0500
Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA20918
	for <policy@raleigh.ibm.com>; Wed, 14 Feb 2001 11:18:47 -0500
Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21)
	id <1Z640K8K>; Wed, 14 Feb 2001 11:09:08 -0500
Message-Id: <A3617F281546D411958C00D0B760121CEBDD2A@bor.ellacoya.com>
From: "Weiss, Walter" <wweiss@ellacoya.com>
To: "'John Strassner'" <jstrassn@cisco.com>,
        "Joel M. Halpern"
	 <joel@longsys.com>
Cc: Robert Moore <remoore@us.ibm.com>, policy@raleigh.ibm.com, johns@cisco.com
Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe technica
	l meeting, 1/24/01 - 1/26/01)
Date: Wed, 14 Feb 2001 11:09:08 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C096A0.75CDA3DE"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Weiss, Walter" <wweiss@ellacoya.com>

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_01C096A0.75CDA3DE
Content-Type: text/plain;
	charset="iso-8859-1"

John,

I am confused by the following statements:

> What the real problem is that QPIM has 
> introduced several 
> notions that are completely lacking in QDDIM:
> 
>    - constraining the values of a variable or constant
Doesn't an information model explicitly constrain the allowable values of an
attribute?
>    - constraining the data types of a variable or constant
Can you explain what you mean here? Are you refering to the semantics of
variables within an expression? If so, isn't this more a function of the
language semantics for the expression of variables (ie. Perl notion of a
variable is somewhat different from C).
>    - binding a variable to a value
Isn't this also a language semantic? 
> 

It seems to me that QDDIM fits rather nicely into an expression based
language. If we consider a QDDIM object as a structured data type, it maps
rather well. The ultimate question with respect to variables is where the
base variables are defined. Do we use QDDIM or a derivative or do we define
a whole new set of variables that duplicates all the semantics described in
QDDIM?

If we start from scratch, the most convenient approach is to create a list
of possible variables. However, as the list grows longer, organizing the
attributes is inevitable. A good parallel would be Fortran with flat
attributes, C with structures, and Java with classes. Since experience tells
us that structure is inevitable, we may as well define the structures now.
If we do, we have come full circle back to where QDDIM is now.

regards,

-Walter

------_=_NextPart_001_01C096A0.75CDA3DE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Packet Filtering (Re: Preliminary results from PCIMe =
technical meeting, 1/24/01 - 1/26/01)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>I am confused by the following statements:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; What the real problem is that QPIM has </FONT>
<BR><FONT SIZE=3D2>&gt; introduced several </FONT>
<BR><FONT SIZE=3D2>&gt; notions that are completely lacking in =
QDDIM:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - constraining the values of =
a variable or constant</FONT>
<BR><FONT SIZE=3D2>Doesn't an information model explicitly constrain =
the allowable values of an attribute?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - constraining the data types =
of a variable or constant</FONT>
<BR><FONT SIZE=3D2>Can you explain what you mean here? Are you refering =
to the semantics of variables within an expression? If so, isn't this =
more a function of the language semantics for the expression of =
variables (ie. Perl notion of a variable is somewhat different from =
C).</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - binding a variable to a =
value</FONT>
<BR><FONT SIZE=3D2>Isn't this also a language semantic? </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>It seems to me that QDDIM fits rather nicely into an =
expression based language. If we consider a QDDIM object as a =
structured data type, it maps rather well. The ultimate question with =
respect to variables is where the base variables are defined. Do we use =
QDDIM or a derivative or do we define a whole new set of variables that =
duplicates all the semantics described in QDDIM?</FONT></P>

<P><FONT SIZE=3D2>If we start from scratch, the most convenient =
approach is to create a list of possible variables. However, as the =
list grows longer, organizing the attributes is inevitable. A good =
parallel would be Fortran with flat attributes, C with structures, and =
Java with classes. Since experience tells us that structure is =
inevitable, we may as well define the structures now. If we do, we have =
come full circle back to where QDDIM is now.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>-Walter</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C096A0.75CDA3DE--


From majordomo@raleigh.ibm.com  Thu Feb 15 09:52:06 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19427
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 09:52:05 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA26572;
	Thu, 15 Feb 2001 09:37:30 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA27250;
	Thu, 15 Feb 2001 09:37:25 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43168; Thu, 15 Feb 2001 08:52:58 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54936; Thu, 15 Feb 2001 08:52:55 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA36450
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 08:52:59 -0500
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA21012
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 08:52:56 -0500
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345)
	id BFD174F83; Thu, 15 Feb 2001 08:52:27 -0500 (EST)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id C62E84EA3
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 08:52:24 -0500 (EST)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <1VHK293A>; Thu, 15 Feb 2001 14:52:23 +0100
Message-Id: <C1434589DE6ED411885900508BDF604D014B18CD@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
To: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: About Policy :)
Date: Thu, 15 Feb 2001 14:52:01 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>

Hello everyone,
I am a newcomer in this list. I am currently working on Policy Management to
implement it's principle to our product TeMIP.
After reading lots of documentation, there is some point I did not
get!!Sorry if some of my questions looks stupid but I'm really discovering
PM.
To begin, I would have a simple question: when a PDP send a policy request
to a PEP (A cisco router for example), where is the intelligence that is 
going to say to that router to act in a specific way. Is there a process
that interface with IOS command to set up the router or Is there an
"intelligence" within the router that understand the request and apply it
(COPS ??) ?
Thanks a lot,
Reda.


From majordomo@raleigh.ibm.com  Thu Feb 15 11:46:35 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22893
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 11:46:35 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA12246;
	Thu, 15 Feb 2001 11:39:32 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA35892;
	Thu, 15 Feb 2001 11:39:23 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46572; Thu, 15 Feb 2001 11:08:34 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58850; Thu, 15 Feb 2001 11:08:28 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA02694
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 11:08:31 -0500
Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA30972
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 11:08:07 -0500
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80])
        by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id RAA01789;
        Thu, 15 Feb 2001 17:06:35 +0100
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1])
        by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA21814;
        Thu, 15 Feb 2001 17:02:51 +0100 (MET)
Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93])
	by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id RAA11385;
	Thu, 15 Feb 2001 17:07:42 +0100 (MET)
Received: from pc50062 ([188.9.248.194])
	by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id RAA21281;
	Thu, 15 Feb 2001 17:07:45 +0100 (MET)
Message-Id: <044f01c09769$2f6b5f20$c2f809bc@ms.alcatel.fr>
From: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
Cc: <policy@raleigh.ibm.com>
References: <C1434589DE6ED411885900508BDF604D014B18CD@vbeexc01.vbe.cpqcorp.net>
Subject: Re: About Policy :)
Date: Thu, 15 Feb 2001 17:05:58 +0100
Organization: Alcatel CRC
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Yacine El Mghazli" <yacine.el_mghazli@ms.alcatel.fr>
Content-Transfer-Encoding: 7bit

Hi Reda (like my brother !),

See comments bellow :

> Hello everyone,
> I am a newcomer in this list. I am currently working on Policy Management
to
> implement it's principle to our product TeMIP.
> After reading lots of documentation, there is some point I did not
> get!!Sorry if some of my questions looks stupid but I'm really discovering
> PM.
> To begin, I would have a simple question: when a PDP send a policy request
You mean a policy DECISION ;-)

> to a PEP (A cisco router for example), where is the intelligence that is
> going to say to that router to act in a specific way. Is there a process
> that interface with IOS command to set up the router or Is there an
> "intelligence" within the router that understand the request and apply it
> (COPS ??) ?
In a native Policy (COPS) situation, your second alternative is the good one
: the control plane of the router is in charge of getting the PDP decisions
(via COPS for instance) and driving the router forwarding plane (=install
the downloaded policy rule).
However, you can use the first solution in the framework of a proxy-like
configuration, in the case where your old Cisco router does not fit with
Policy features ;-)

Regards,
Yacine
> Thanks a lot,
> Reda.




From majordomo@raleigh.ibm.com  Thu Feb 15 12:35:15 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24754
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 12:35:14 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA39046;
	Thu, 15 Feb 2001 12:24:24 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA25124;
	Thu, 15 Feb 2001 12:24:24 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58244; Thu, 15 Feb 2001 11:49:51 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50536; Thu, 15 Feb 2001 11:49:45 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32684
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 11:49:50 -0500
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA06940
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 11:49:47 -0500
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id C0421B9EA; Thu, 15 Feb 2001 11:49:18 -0500 (EST)
Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP
	id 97728B81D; Thu, 15 Feb 2001 11:49:17 -0500 (EST)
Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <1VSVT350>; Thu, 15 Feb 2001 17:40:31 +0100
Message-Id: <C1434589DE6ED411885900508BDF604D014B18CE@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
To: "'Yacine El Mghazli'" <yacine.el_mghazli@ms.alcatel.fr>
Cc: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: RE: About Policy :)
Date: Thu, 15 Feb 2001 17:40:06 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>

Thanks a lot Yacine for your help.
Just one other question, when the control plane of the router is in charge
of getting the PDP decisions, what sort of command do they exchange
(name-value pair,...?).
Do you know where can I get precise information or example of code?
Thanks.
regards,
 Reda.

-----Original Message-----
From: Yacine El Mghazli [mailto:yacine.el_mghazli@ms.alcatel.fr]
Sent: Thursday, February 15, 2001 5:06 PM
To: Bouarich, Reda
Cc: policy@raleigh.ibm.com
Subject: Re: About Policy :)


Hi Reda (like my brother !),

See comments bellow :

> Hello everyone,
> I am a newcomer in this list. I am currently working on Policy Management
to
> implement it's principle to our product TeMIP.
> After reading lots of documentation, there is some point I did not
> get!!Sorry if some of my questions looks stupid but I'm really discovering
> PM.
> To begin, I would have a simple question: when a PDP send a policy request
You mean a policy DECISION ;-)

> to a PEP (A cisco router for example), where is the intelligence that is
> going to say to that router to act in a specific way. Is there a process
> that interface with IOS command to set up the router or Is there an
> "intelligence" within the router that understand the request and apply it
> (COPS ??) ?
In a native Policy (COPS) situation, your second alternative is the good one
: the control plane of the router is in charge of getting the PDP decisions
(via COPS for instance) and driving the router forwarding plane (=install
the downloaded policy rule).
However, you can use the first solution in the framework of a proxy-like
configuration, in the case where your old Cisco router does not fit with
Policy features ;-)

Regards,
Yacine
> Thanks a lot,
> Reda.



From majordomo@raleigh.ibm.com  Thu Feb 15 12:38:52 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24896
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 12:38:51 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA36488;
	Thu, 15 Feb 2001 12:29:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA13686;
	Thu, 15 Feb 2001 12:24:39 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA39602; Thu, 15 Feb 2001 12:01:05 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51624; Thu, 15 Feb 2001 12:01:01 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA35924
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 12:01:05 -0500
Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA27044
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 12:01:01 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id MAA21826;
	Thu, 15 Feb 2001 12:00:42 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 15 Feb 2001 17:00:42 UT
Received: from mears.indy.cr.irs.gov (mailhub-2 [10.7.8.10])
	by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id MAA04143;
	Thu, 15 Feb 2001 12:00:32 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id MAA11592;
	Thu, 15 Feb 2001 12:00:30 -0500
Message-Id: <3A8C0B2D.7487A73B@parnelli.indy.cr.irs.gov>
Date: Thu, 15 Feb 2001 12:00:29 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: Rob Byrne <Robert.Byrne@france.Sun.COM>
Cc: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        ietf-ldapext@netscape.com, estokes@tivoli.com, blakley@tivoli.com,
        djbrink@us.ibm.com, IETF Policy WG LIST <policy@raleigh.ibm.com>
Subject: Re: ACL Model and application defined permission
References: <5.0.2.1.0.20010214170548.00a6f4b0@pop.walltech.com> <3A8BE557.6535A170@france.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

The early ACL Model drafts proposed to support a functionality similar
to what Bruce describes. The ACL element was called "use", and was meant
to provide an indication of authorization to access or exercise the
targeted object or resource.

Subsequent discussions in ldapext revealed objections. Some argued
that the issue was simply out of scope, that the model should focus
solely on Directory operations. Others asserted that attempting to
support such functionality in the ACL Model amounted to the first
step down a slippery slope of extreme complexity.      

Consensus (at that time) resolved that the ACL Model should be limited
to supporting Directory operations. As a consequence, the "use" term and
its intended functionality disappeared from the ACL Model drafts.

This is a Good Thing. The ACL Model should be limited to support of
Directory operations. This is not to say that the Directory shouldn't 
be involved in supporting access, authorization, and usage decisions for
entities which are external to the Directory.  

Analysis in other venues (such as DMTF's CIM and IETF's Policy WG)
has revealed that authorization is a much larger question than can be
supported by a binary "go/no-go" indicator. Network resources,
distributed
objects, and applications require a richer information model.

The Directory is the place to do it, but the ACL Model is not the
way to do it. Policy is the way to go.
    

Rob Byrne wrote:
> 
> Bruce Greenblatt wrote:
> >
> > As I understand it, in the current ACL Model draft, the kinds of
> > permissions that an LDAP server understands are limited to those defined in
> > clause 4.1.1.  Is this accurate?  The reason that I ask, is that I would
> 
> Hi Bruce,
> 
> That's the way it's written right now.  I agree that the idea of having
> an extensible access control model is very attractive.  The reason is
> that we could all then be legitimately claim to be running version 1.0,
> say, of the LDAP access control model...but with our own little tweaks.
> It would also hopefully allow writers of new LDAP extended operations
> and controls to define the required permissions for their new stuff
> without having to ramp the version number of the LDAP access control
> model.  I started to work on this idea but haven't had time to get it in
> a reviewable state...basically the idea would be to allow the permission
> list to be extended and in addition to allow an extended permission to
> have some "extended fields" associated with it which would contain any
> data that the permission required.  The problem is of course, what
> happens if you send an aci with extended stuff to another server that
> doesn't support it...reject it...? OK, but that's a big pain for
> replication...Ok, publish the "supported extended permissions" in the
> rootDSE and make it part of the replication agreement that both servers
> check they support the same stuff...I'm just giving you an idea of the
> things we need to think about to get an extensible model to work.  It's
> conceivable that it would be too much work for this pass of the draft.
> 
> > like to store application defined permissions as well.  For example, I have
> > an application the allows users to perform several different actions on
> > various types of objects.  Let's call these objects foo objects, and the
> > actions foo-1 through foo-n.  None of these correspond to the add, delete,
> > export, etc. permissions defined in clause 4.1.1.  I would like to be able
> > to have a ACI assigned to an entry that represents a foo object that grants
> > permissions to perform some foo-i actions to some list of subject entries
> > (i.e. users, groups, organizationalUnits, domainContexts, etc.).  Can I
> > grant these permissions with the mechanisms currently defined in the ACL
> > Model draft.  My presumption is that this would require a new permission
> > level, but I don't see how to shoe-horn this in to the BNF of 4.1.1 or the
> > ASN.1 of 4.1.2.
> >
> > I would also like to be able to verify that a subject entry has the
> > appropriate rights to perform an operation against a specified object.  How
> > is this supposed to work in the existing model?  Either the effective
> > rights control or extended operation ought to be able to work for this, but
> > the definitions are confusing to me.  There should be a new clause 11.1.4
> 
> Agree 100%...I started working on clarifying these...again...not done.
> I think I agree with the spirit of what you want to do here but I don't
> think for example you need to be able to specify the action "foo" when
> you ask for the effective rights...I think it's easier to specify the
> user, the object and get all the rights back--the requestor can then
> check to see if "foo" happens to be in there.  Anyway, that's kind of a
> detail.
> One thing I was hoping to do was drop the extended operation entirely
> and just have the control...I think you can do everything you want with
> a control if you get it right.
> 
> Rob.
> 
> > that gives a specific example of a Search request with the control that
> > shows how to do permission verification.  Similarly, there should be a new
> > clause 12.2 that gives a specific example of the use of the extended
> > operation.  I'd note that in both of these cases, there ought to be a way
> > for the LDAP client to list out the permissions in which it is interested.
> >
> > I'd also like to be able to find all of the entries in a specified scope to
> > which a specified user has permission to perform action foo.  I'm guessing
> > that I'm supposed to use the effective rights control for this, but without
> > the example, I'm at a loss as to how to build the search and the control
> > appropriately.
> >
> > Overall, the model appears to be very close to meeting the requirements for
> > application defined permissions.
> >
> > Thanks,
> >
> > Bruce Greenblatt

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Thu Feb 15 14:54:20 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28807
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 14:54:20 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA11704;
	Thu, 15 Feb 2001 14:43:44 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA30954;
	Thu, 15 Feb 2001 14:43:45 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58058; Thu, 15 Feb 2001 14:11:51 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA24770; Thu, 15 Feb 2001 14:11:48 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA27290
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 14:11:54 -0500
Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA32106
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 14:11:49 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id OAA13981;
	Thu, 15 Feb 2001 14:11:25 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 15 Feb 2001 19:11:25 UT
Received: from mears.indy.cr.irs.gov (mailhub-2 [10.7.8.10])
	by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id OAA19430;
	Thu, 15 Feb 2001 14:11:14 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id OAA11803;
	Thu, 15 Feb 2001 14:11:12 -0500
Message-Id: <3A8C29CF.8D4F6767@parnelli.indy.cr.irs.gov>
Date: Thu, 15 Feb 2001 14:11:11 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: Bruce Greenblatt <bgreenblatt@directory-applications.com>
Cc: Rob Byrne <Robert.Byrne@france.Sun.COM>, ietf-ldapext@netscape.com,
        estokes@tivoli.com, blakley@tivoli.com, djbrink@us.ibm.com,
        IETF Policy WG LIST <policy@raleigh.ibm.com>
Subject: Re: ACL Model and application defined permission
References: <5.0.2.1.0.20010214170548.00a6f4b0@pop.walltech.com>
	 <3A8BE557.6535A170@france.sun.com> <5.0.2.1.0.20010215092438.00a86650@pop.walltech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

Bruce Greenblatt wrote:
> 
> At 12:00 PM 2/15/2001 -0500, Larry S. Bartz wrote:
> 
> >The ACL Model should be limited to support of
> >Directory operations. This is not to say that the Directory shouldn't
> >be involved in supporting access, authorization, and usage decisions for
> >entities which are external to the Directory.
> >
> 
> Larry,
> 
> I couldn't disagree more.  What you fail to mention, is that ALL entities
> are external to the directory.  The information that is stored in the
> directory is a partial representation of an external entity.  For example,
> there are many more attributes of a user than are stored in the
> directory.  Why are users, organizations, file servers, etc. internal to a
> directory, and a book or a hat external to the directory?  There is no
> obvious reason, because the directory is just keeping track certain
> properties of these entities.  The more information that is kept in the
> directory,the more valuable it is.
> 
> Bruce
> 

Bruce,

I agree with your assertion regarding the difference between an object
and the representation of an object in the Directory. My bad. I
shouldn't 
have used a double negative in the sentence which you quoted above.
Restated,
"The Directory should be involved in supporting access, authorization,
and
usage decisions for entities which are external to the Directory." We
agree to that, I think.

I also agree that the value of the Directory is proportional to the 
information it contains. Further, I agree that the Directory is a
natural
platform for associating principals and services, consumers and
suppliers,
for convenience and/or in support of security goals.

I disagree with your suggestion that the scope of the ACL Model should
be extended. 
 
The ACL is the place to manage access to the Directory representation, 
the motes of data which comprise the Directory itself. The ACL Model is
scoped to manage access of Directory operations, Directory CRUD. The ACL
Model should stay in scope.

This very issue was discussed by several participants in ldapext in the 
spring and summer of 1998, and maybe again later. The discussion was 
initiated by those who objected to the "use" term (and its intended
functionality) of the original and early ACL Model drafts. The outcome,
the result of those discussions, was the focused and purposeful scope of
the current ACL Model.  

Users, organizations, file servers, books, hats, and whatever else can
be represented in the Directory, but they are not a part of the ACL
Model. 

By the same token, Policies (which can include authorization policies)
which apply to certain entities can also be represented in the
Directory.
As proof, see the work products of the Policy WG and the work products
of
DMTF CIM. These Policies should not be part of the ACL Model.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Thu Feb 15 21:14:13 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04385
	for <policy-archive@odin.ietf.org>; Thu, 15 Feb 2001 21:14:13 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA08722;
	Thu, 15 Feb 2001 21:08:22 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA30696;
	Thu, 15 Feb 2001 21:08:12 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33924; Thu, 15 Feb 2001 20:39:38 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43132; Thu, 15 Feb 2001 20:39:33 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id UAA35508
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 20:39:33 -0500
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA39038
	for <policy@raleigh.ibm.com>; Thu, 15 Feb 2001 20:39:31 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA15230;
	Thu, 15 Feb 2001 17:39:17 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (sj-dial-3-68.cisco.com [171.68.180.69])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ALE00564;
	Thu, 15 Feb 2001 17:38:35 -0800 (PST)
Message-Id: <4.3.2.7.2.20010215173031.00b2dce0@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 15 Feb 2001 17:37:37 -0800
To: "Weiss, Walter" <wweiss@ellacoya.com>
From: John Strassner <jstrassn@cisco.com>
Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe
  technica l meeting, 1/24/01 - 1/26/01)
Cc: "'John Strassner'" <jstrassn@cisco.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        Robert Moore <remoore@us.ibm.com>, policy@raleigh.ibm.com,
        johns@cisco.com
In-Reply-To: <A3617F281546D411958C00D0B760121CEBDD2A@bor.ellacoya.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_26270635==_.ALT"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

--=====================_26270635==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Walter, please see inline.

regards,
John

At 11:09 AM 2/14/2001 -0500, Weiss, Walter wrote:

>John,
>
>I am confused by the following statements:
>
> > What the real problem is that QPIM has
> > introduced several
> > notions that are completely lacking in QDDIM:
> >
> >    - constraining the values of a variable or constant
>Doesn't an information model explicitly constrain the allowable values of 
>an attribute?

<js>
No. What I'm talking about here is the ability to specify and model 
constraints. Saying that an attribute is a uint8 explicitly constrains the 
legal range of values that the attribute can take. What I'm looking at is 
in addition, constraining the allowable range of values that an attribute 
can have for a particular application (e.g., 0-63 instead of 0-127), 
attaching special semantics to certain values (as is commonly done in 
MIBs), and defining special relationships between a value of an attribute 
and something else. OCL would be the easiest (though possibly not the most 
efficient) way to do this with our model.
</js>

> >    - constraining the data types of a variable or constant
>Can you explain what you mean here? Are you refering to the semantics of 
>variables within an expression? If so, isn't this more a function of the 
>language semantics for the expression of variables (ie. Perl notion of a 
>variable is somewhat different from C).

<js> See above </js>


> >    - binding a variable to a value
>Isn't this also a language semantic?

<js>
No. For example, in QPIM we may be dealing with an IPAddress, and want to 
restrict the values of said variable to just IPv4 addresses that are in 
CIDR format.
</js>

> >
>
>It seems to me that QDDIM fits rather nicely into an expression based 
>language. If we consider a QDDIM object as a structured data type, it maps 
>rather well. The ultimate question with respect to variables is where the 
>base variables are defined. Do we use QDDIM or a derivative or do we 
>define a whole new set of variables that duplicates all the semantics 
>described in QDDIM?
>
>If we start from scratch, the most convenient approach is to create a list 
>of possible variables. However, as the list grows longer, organizing the 
>attributes is inevitable. A good parallel would be Fortran with flat 
>attributes, C with structures, and Java with classes. Since experience 
>tells us that structure is inevitable, we may as well define the 
>structures now. If we do, we have come full circle back to where QDDIM is now.

<js> Sorry, you lost me here. Can you please elaborate? </js>


>regards,
>
>-Walter

--=====================_26270635==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Walter, please see inline.<br>
<br>
regards,<br>
John<br>
<br>
At 11:09 AM 2/14/2001 -0500, Weiss, Walter wrote:<br>
<br>
<blockquote type=cite cite><font size=2>John,</font> <br>
<br>
<font size=2>I am confused by the following statements:</font> <br>
<br>
<font size=2>&gt; What the real problem is that QPIM has </font><br>
<font size=2>&gt; introduced several </font><br>
<font size=2>&gt; notions that are completely lacking in QDDIM:</font>
<br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp; - constraining the values of a variable or constant</font> <br>
<font size=2>Doesn't an information model explicitly constrain the allowable values of an attribute?</font> </blockquote><br>
&lt;js&gt;<br>
No. What I'm talking about here is the ability to specify and model constraints. Saying that an attribute is a uint8 explicitly constrains the legal range of values that the attribute can take. What I'm looking at is in addition, constraining the allowable range of values that an attribute can have for a particular application (e.g., 0-63 instead of 0-127), attaching special semantics to certain values (as is commonly done in MIBs), and defining special relationships between a value of an attribute and something else. OCL would be the easiest (though possibly not the most efficient) way to do this with our model.<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite><font size=2>&gt;&nbsp;&nbsp;&nbsp; - constraining the data types of a variable or constant</font> <br>
<font size=2>Can you explain what you mean here? Are you refering to the semantics of variables within an expression? If so, isn't this more a function of the language semantics for the expression of variables (ie. Perl notion of a variable is somewhat different from C).</font></blockquote><br>
&lt;js&gt; See above &lt;/js&gt;<br>
<br>
<br>
<blockquote type=cite cite><font size=2>&gt;&nbsp;&nbsp;&nbsp; - binding a variable to a value</font> <br>
<font size=2>Isn't this also a language semantic? </font></blockquote><br>
&lt;js&gt;<br>
No. For example, in QPIM we may be dealing with an IPAddress, and want to restrict the values of said variable to just IPv4 addresses that are in CIDR format.<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite><font size=2>&gt; <br>
</font><br>
<font size=2>It seems to me that QDDIM fits rather nicely into an expression based language. If we consider a QDDIM object as a structured data type, it maps rather well. The ultimate question with respect to variables is where the base variables are defined. Do we use QDDIM or a derivative or do we define a whole new set of variables that duplicates all the semantics described in QDDIM?<br>
</font><br>
<font size=2>If we start from scratch, the most convenient approach is to create a list of possible variables. However, as the list grows longer, organizing the attributes is inevitable. A good parallel would be Fortran with flat attributes, C with structures, and Java with classes. Since experience tells us that structure is inevitable, we may as well define the structures now. If we do, we have come full circle back to where QDDIM is now.</font></blockquote><br>
&lt;js&gt; Sorry, you lost me here. Can you please elaborate? &lt;/js&gt;<br>
<br>
<br>
<blockquote type=cite cite><font size=2>regards,</font> <br>
<br>
<font size=2>-Walter</font> </blockquote></html>

--=====================_26270635==_.ALT--



From majordomo@raleigh.ibm.com  Fri Feb 16 05:53:39 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26015
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 05:53:39 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA22182;
	Fri, 16 Feb 2001 05:42:36 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA36686;
	Fri, 16 Feb 2001 05:42:27 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28544; Fri, 16 Feb 2001 05:03:21 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51830; Fri, 16 Feb 2001 05:03:17 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA21270
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 05:03:20 -0500
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA19472
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 05:03:17 -0500
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345)
	id 78B1857FB; Fri, 16 Feb 2001 05:02:47 -0500 (EST)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP id CA1C55852
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 05:02:46 -0500 (EST)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <1VHKJHT4>; Fri, 16 Feb 2001 11:02:45 +0100
Message-Id: <C1434589DE6ED411885900508BDF604D014B18D0@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
To: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: example of a  Policy Core Inofrmation Model to XML mapping
Date: Fri, 16 Feb 2001 11:02:21 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>

Dear All,
I am trying to specify a certain policy (if a bandwidth overload occurs
between 9am and 6pm then limit the ftp transfert
to 100 kb/sec for example) using the DMTF Policy COre Information Model.
First I have to map my policy properties on the standardized policy classes
defined by the DMTF then I have to map this Information model to XML.
Can anyone tell me where can I find some kind of concrete examples
representing such mapping cause it is the first time I do that and it not
clear in my mind!!.
Thanks a lot.
Reda Bouarich.		


From majordomo@raleigh.ibm.com  Fri Feb 16 07:34:33 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27422
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 07:34:33 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA31386;
	Fri, 16 Feb 2001 07:21:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA31088;
	Fri, 16 Feb 2001 07:21:43 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35192; Fri, 16 Feb 2001 06:35:33 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA28512; Fri, 16 Feb 2001 06:35:30 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA25266
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 06:35:33 -0500
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA12228
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 06:35:30 -0500
Received: from odin.France.Sun.COM ([129.157.192.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11680;
	Fri, 16 Feb 2001 03:35:16 -0800 (PST)
Received: from france.sun.com (hamble [129.157.192.53])
	by odin.France.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with ESMTP id MAA26604;
	Fri, 16 Feb 2001 12:33:54 +0100 (MET)
Message-Id: <3A8D1061.FF14D1EE@france.sun.com>
Date: Fri, 16 Feb 2001 12:34:57 +0100
From: Rob Byrne <Robert.Byrne@france.sun.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
Mime-Version: 1.0
To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Cc: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        ietf-ldapext@netscape.com, estokes@tivoli.com, blakley@tivoli.com,
        djbrink@us.ibm.com, IETF Policy WG LIST <policy@raleigh.ibm.com>
Subject: Re: ACL Model and application defined permission
References: <5.0.2.1.0.20010214170548.00a6f4b0@pop.walltech.com>
		 <3A8BE557.6535A170@france.sun.com> <5.0.2.1.0.20010215092438.00a86650@pop.walltech.com> <3A8C29CF.8D4F6767@parnelli.indy.cr.irs.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Rob Byrne <Robert.Byrne@france.sun.com>
Content-Transfer-Encoding: 7bit


Larry,

I think you are absolutely right that the access control model must stay
focused and that there will be "other policy" that will be quite rightly
expressed external to the access control model.  I just want to clarify
that the kind of extensiblity I was talking about trying to define is
motivated by the need to support evolving directory "stuff" and so I
think is in scope.
The point is that it seems a shame not to be able to incorporate new
controls or extended operations, as much as we can, within one access
control model.  A good example would be the Proxy Authorisation
Control.  Classically an access control statement makes an assertion
about the rights of some subject on an object--so there are two
important "bits".  Along comes the Proxy Control and now there ia an
extra bit, namely the other subject that the original subject can proxy
as.  So unless the original model provides a way to extend itslef to
accomodate the new subject, it has to be redone.  If we can design a
model to allow this kind of extensibility then I think that is
desirable--there will always be new controls/extended operations coming
along.
In relation to Bruce's issue, I guesss what you would dislike would be
if Bruce used this mechanism to say define a new extended permission
"sitOn" and then represented a chair as cn=brucesChair,o=chezBruce and
then started granting and denying access using this permission and
object in the obvious way.  I kind of see both sides here--"sitOn"
clearly has nothing to do with a directory operation and so is therefore
out of place as a permission....on the other hand if an application
wanted to leverage the directory's support for notions of user, objects
and permissions...then why not...?  We haven't explicitly included that
in the model...it's just allowed by it.

Rob.  

"Larry S. Bartz" wrote:
> 
> Bruce Greenblatt wrote:
> >
> > At 12:00 PM 2/15/2001 -0500, Larry S. Bartz wrote:
> >
> > >The ACL Model should be limited to support of
> > >Directory operations. This is not to say that the Directory shouldn't
> > >be involved in supporting access, authorization, and usage decisions for
> > >entities which are external to the Directory.
> > >
> >
> > Larry,
> >
> > I couldn't disagree more.  What you fail to mention, is that ALL entities
> > are external to the directory.  The information that is stored in the
> > directory is a partial representation of an external entity.  For example,
> > there are many more attributes of a user than are stored in the
> > directory.  Why are users, organizations, file servers, etc. internal to a
> > directory, and a book or a hat external to the directory?  There is no
> > obvious reason, because the directory is just keeping track certain
> > properties of these entities.  The more information that is kept in the
> > directory,the more valuable it is.
> >
> > Bruce
> >
> 
> Bruce,
> 
> I agree with your assertion regarding the difference between an object
> and the representation of an object in the Directory. My bad. I
> shouldn't
> have used a double negative in the sentence which you quoted above.
> Restated,
> "The Directory should be involved in supporting access, authorization,
> and
> usage decisions for entities which are external to the Directory." We
> agree to that, I think.
> 
> I also agree that the value of the Directory is proportional to the
> information it contains. Further, I agree that the Directory is a
> natural
> platform for associating principals and services, consumers and
> suppliers,
> for convenience and/or in support of security goals.
> 
> I disagree with your suggestion that the scope of the ACL Model should
> be extended.
> 
> The ACL is the place to manage access to the Directory representation,
> the motes of data which comprise the Directory itself. The ACL Model is
> scoped to manage access of Directory operations, Directory CRUD. The ACL
> Model should stay in scope.
> 
> This very issue was discussed by several participants in ldapext in the
> spring and summer of 1998, and maybe again later. The discussion was
> initiated by those who objected to the "use" term (and its intended
> functionality) of the original and early ACL Model drafts. The outcome,
> the result of those discussions, was the focused and purposeful scope of
> the current ACL Model.
> 
> Users, organizations, file servers, books, hats, and whatever else can
> be represented in the Directory, but they are not a part of the ACL
> Model.
> 
> By the same token, Policies (which can include authorization policies)
> which apply to certain entities can also be represented in the
> Directory.
> As proof, see the work products of the Policy WG and the work products
> of
> DMTF CIM. These Policies should not be part of the ACL Model.
> 
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Feb 16 09:04:50 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29128
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 09:04:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA20630;
	Fri, 16 Feb 2001 08:51:31 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA25144;
	Fri, 16 Feb 2001 08:46:37 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44306; Fri, 16 Feb 2001 08:07:05 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52682; Fri, 16 Feb 2001 08:06:59 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA36050
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 08:07:02 -0500
Received: from mail.viridien.com (Mail.Viridien.com [63.209.241.243])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA26970
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 08:06:59 -0500
Received: by mail.viridien.com with Internet Mail Service (5.5.2653.19)
	id <1Z5NRL1C>; Fri, 16 Feb 2001 08:06:55 -0500
Message-Id: <CCDD4CB06BDBD311956600508B2C9D98E3F6F1@mail.viridien.com>
From: Brian Sandberg <bsandberg@viridien.com>
To: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: Re: example of a  Policy Core Inofrmation Model to XML mapping
Date: Fri, 16 Feb 2001 08:06:54 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Brian Sandberg <bsandberg@viridien.com>

Why wasn't XML used for the policy model?


--------------------------
Brian Sandberg


-----Original Message-----
From: Bouarich, Reda <Reda.Bouarich@compaq.com>
To: 'policy@raleigh.ibm.com' <policy@raleigh.ibm.com>
Sent: Fri Feb 16 05:02:21 2001
Subject: example of a  Policy Core Inofrmation Model to XML mapping

Dear All,
I am trying to specify a certain policy (if a bandwidth overload occurs
between 9am and 6pm then limit the ftp transfert
to 100 kb/sec for example) using the DMTF Policy COre Information Model.
First I have to map my policy properties on the standardized policy classes
defined by the DMTF then I have to map this Information model to XML.
Can anyone tell me where can I find some kind of concrete examples
representing such mapping cause it is the first time I do that and it not
clear in my mind!!.
Thanks a lot.
Reda Bouarich.		


From majordomo@raleigh.ibm.com  Fri Feb 16 10:19:13 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01582
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 10:19:12 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA37940;
	Fri, 16 Feb 2001 09:58:25 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA30096;
	Fri, 16 Feb 2001 09:58:25 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA35248; Fri, 16 Feb 2001 09:26:01 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA44968; Fri, 16 Feb 2001 09:25:58 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA29682
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 09:26:01 -0500
Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA07030
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 09:25:58 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id JAA02735;
	Fri, 16 Feb 2001 09:25:29 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 16 Feb 2001 14:25:29 UT
Received: from mears.indy.cr.irs.gov (mailhub-2 [10.7.8.10])
	by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id JAA09644;
	Fri, 16 Feb 2001 09:25:22 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id JAA12640;
	Fri, 16 Feb 2001 09:25:21 -0500
Message-Id: <3A8D3851.677EAD37@parnelli.indy.cr.irs.gov>
Date: Fri, 16 Feb 2001 09:25:21 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: Rob Byrne <Robert.Byrne@france.sun.com>
Cc: Bruce Greenblatt <bgreenblatt@directory-applications.com>,
        ietf-ldapext@netscape.com, estokes@tivoli.com, blakley@tivoli.com,
        djbrink@us.ibm.com, IETF Policy WG LIST <policy@raleigh.ibm.com>
Subject: Re: ACL Model and application defined permission
References: <5.0.2.1.0.20010214170548.00a6f4b0@pop.walltech.com>
			 <3A8BE557.6535A170@france.sun.com> <5.0.2.1.0.20010215092438.00a86650@pop.walltech.com> <3A8C29CF.8D4F6767@parnelli.indy.cr.irs.gov> <3A8D1061.FF14D1EE@france.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

Thanks, Rob.

You have succinctly summarized my position and explained the
extensibility
strategy to my satisfaction.

Rob Byrne wrote:
> 
> Larry,
> 
> I think you are absolutely right that the access control model must stay
> focused and that there will be "other policy" that will be quite rightly
> expressed external to the access control model.  I just want to clarify
> that the kind of extensiblity I was talking about trying to define is
> motivated by the need to support evolving directory "stuff" and so I
> think is in scope.
> The point is that it seems a shame not to be able to incorporate new
> controls or extended operations, as much as we can, within one access
> control model.  A good example would be the Proxy Authorisation
> Control.  Classically an access control statement makes an assertion
> about the rights of some subject on an object--so there are two
> important "bits".  Along comes the Proxy Control and now there ia an
> extra bit, namely the other subject that the original subject can proxy
> as.  So unless the original model provides a way to extend itslef to
> accomodate the new subject, it has to be redone.  If we can design a
> model to allow this kind of extensibility then I think that is
> desirable--there will always be new controls/extended operations coming
> along.
> In relation to Bruce's issue, I guesss what you would dislike would be
> if Bruce used this mechanism to say define a new extended permission
> "sitOn" and then represented a chair as cn=brucesChair,o=chezBruce and
> then started granting and denying access using this permission and
> object in the obvious way.  I kind of see both sides here--"sitOn"
> clearly has nothing to do with a directory operation and so is therefore
> out of place as a permission....on the other hand if an application
> wanted to leverage the directory's support for notions of user, objects
> and permissions...then why not...?  We haven't explicitly included that
> in the model...it's just allowed by it.
> 
> Rob.
> 
> "Larry S. Bartz" wrote:
> >
> > Bruce Greenblatt wrote:
> > >
> > > At 12:00 PM 2/15/2001 -0500, Larry S. Bartz wrote:
> > >
> > > >The ACL Model should be limited to support of
> > > >Directory operations. This is not to say that the Directory shouldn't
> > > >be involved in supporting access, authorization, and usage decisions for
> > > >entities which are external to the Directory.
> > > >
> > >
> > > Larry,
> > >
> > > I couldn't disagree more.  What you fail to mention, is that ALL entities
> > > are external to the directory.  The information that is stored in the
> > > directory is a partial representation of an external entity.  For example,
> > > there are many more attributes of a user than are stored in the
> > > directory.  Why are users, organizations, file servers, etc. internal to a
> > > directory, and a book or a hat external to the directory?  There is no
> > > obvious reason, because the directory is just keeping track certain
> > > properties of these entities.  The more information that is kept in the
> > > directory,the more valuable it is.
> > >
> > > Bruce
> > >
> >
> > Bruce,
> >
> > I agree with your assertion regarding the difference between an object
> > and the representation of an object in the Directory. My bad. I
> > shouldn't
> > have used a double negative in the sentence which you quoted above.
> > Restated,
> > "The Directory should be involved in supporting access, authorization,
> > and
> > usage decisions for entities which are external to the Directory." We
> > agree to that, I think.
> >
> > I also agree that the value of the Directory is proportional to the
> > information it contains. Further, I agree that the Directory is a
> > natural
> > platform for associating principals and services, consumers and
> > suppliers,
> > for convenience and/or in support of security goals.
> >
> > I disagree with your suggestion that the scope of the ACL Model should
> > be extended.
> >
> > The ACL is the place to manage access to the Directory representation,
> > the motes of data which comprise the Directory itself. The ACL Model is
> > scoped to manage access of Directory operations, Directory CRUD. The ACL
> > Model should stay in scope.
> >
> > This very issue was discussed by several participants in ldapext in the
> > spring and summer of 1998, and maybe again later. The discussion was
> > initiated by those who objected to the "use" term (and its intended
> > functionality) of the original and early ACL Model drafts. The outcome,
> > the result of those discussions, was the focused and purposeful scope of
> > the current ACL Model.
> >
> > Users, organizations, file servers, books, hats, and whatever else can
> > be represented in the Directory, but they are not a part of the ACL
> > Model.
> >
> > By the same token, Policies (which can include authorization policies)
> > which apply to certain entities can also be represented in the
> > Directory.
> > As proof, see the work products of the Policy WG and the work products
> > of
> > DMTF CIM. These Policies should not be part of the ACL Model.
> >

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Feb 16 10:55:05 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02401
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 10:55:05 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA19534;
	Fri, 16 Feb 2001 10:47:12 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA25468;
	Fri, 16 Feb 2001 10:47:04 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA27688; Fri, 16 Feb 2001 10:13:23 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51740; Fri, 16 Feb 2001 10:13:20 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA32234
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 10:13:23 -0500
Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA23438
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 10:13:18 -0500
Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14])
	by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAA27269;
	Fri, 16 Feb 2001 10:13:18 -0500 (EST)
Received: from mailhub.net.treas.gov by tias4.treas.gov
          via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 16 Feb 2001 15:13:18 UT
Received: from mears.indy.cr.irs.gov (mailhub-3 [10.7.8.11])
	by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id KAA02803;
	Fri, 16 Feb 2001 10:10:42 -0500 (EST)
Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1])
	by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id KAA13785;
	Fri, 16 Feb 2001 10:13:15 -0500
Message-Id: <3A8D4388.4A3E888E@parnelli.indy.cr.irs.gov>
Date: Fri, 16 Feb 2001 10:13:12 -0500
From: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686)
X-Accept-Language: en
Mime-Version: 1.0
To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>,
        IETF Policy WG LIST <policy@raleigh.ibm.com>
Subject: Re: example of a  Policy Core Inofrmation Model to XML mapping
References: <C1434589DE6ED411885900508BDF604D014B18D0@vbeexc01.vbe.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
Content-Transfer-Encoding: 7bit

Reda,

Is your Policy data implemented in an LDAP-accessible repository?

If it is, you could retrieve the information as XML, via a DSML
facility, such as Castor or JNDI's DSML SPI. Once you have the
DSML, you might be only one or two XSL transformations away from
the particular XML format you desire.

Although it is not Policy-specific, this article is a good tutorial
on the use of DSML and XSL transformation:

http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html


"Bouarich, Reda" wrote:
> 
> Dear All,
> I am trying to specify a certain policy (if a bandwidth overload occurs
> between 9am and 6pm then limit the ftp transfert
> to 100 kb/sec for example) using the DMTF Policy COre Information Model.
> First I have to map my policy properties on the standardized policy classes
> defined by the DMTF then I have to map this Information model to XML.
> Can anyone tell me where can I find some kind of concrete examples
> representing such mapping cause it is the first time I do that and it not
> clear in my mind!!.
> Thanks a lot.
> Reda Bouarich.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|


From majordomo@raleigh.ibm.com  Fri Feb 16 12:13:55 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04214
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 12:13:54 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA34060;
	Fri, 16 Feb 2001 12:06:25 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA09780;
	Fri, 16 Feb 2001 12:06:23 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45056; Fri, 16 Feb 2001 11:35:46 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45816; Fri, 16 Feb 2001 11:35:42 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32934
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 11:35:46 -0500
Received: from dcn.infos.ru (dcn.infos.ru [195.209.228.109])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA34942
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 11:35:39 -0500
Received: from advanced2 (unknown [213.172.17.250])
	by dcn.infos.ru (Postfix) with SMTP id E7FD137EF8
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 19:29:32 +0300 (MSK)
From: "Andrey Mishchenko" <andrew@dcn.nord.nw.ru>
To: <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Fri, 16 Feb 2001 19:34:57 +0300
Message-Id: <DJEEKEDKNOBLNMOFPNAJGECCCBAA.andrew@dcn.nord.nw.ru>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A8D4388.4A3E888E@parnelli.indy.cr.irs.gov>
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrey Mishchenko" <andrew@dcn.nord.nw.ru>
Content-Transfer-Encoding: 7bit

Larry & Reda,

Why may one want to use XML to represent policies
if they are initially stored in the LDAP-based repository?
Is this useful to aggregate all policy-related information,
such as reusable condition variables and actions in the
single object?

Thanks,

Andrey Mishchenko
andrew@dcn.nord.nw.ru

> Reda,
>
> Is your Policy data implemented in an LDAP-accessible repository?
>
> If it is, you could retrieve the information as XML, via a DSML
> facility, such as Castor or JNDI's DSML SPI. Once you have the
> DSML, you might be only one or two XSL transformations away from
> the particular XML format you desire.
>
> Although it is not Policy-specific, this article is a good tutorial
> on the use of DSML and XSL transformation:
>
> http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html
>
>
> "Bouarich, Reda" wrote:
> >
> > Dear All,
> > I am trying to specify a certain policy (if a bandwidth overload occurs
> > between 9am and 6pm then limit the ftp transfert
> > to 100 kb/sec for example) using the DMTF Policy COre Information Model.
> > First I have to map my policy properties on the standardized
> policy classes
> > defined by the DMTF then I have to map this Information model to XML.
> > Can anyone tell me where can I find some kind of concrete examples
> > representing such mapping cause it is the first time I do that
> and it not
> > clear in my mind!!.
> > Thanks a lot.
> > Reda Bouarich.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
>



From majordomo@raleigh.ibm.com  Fri Feb 16 12:29:24 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04565
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 12:29:24 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA23390;
	Fri, 16 Feb 2001 12:18:03 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA20656;
	Fri, 16 Feb 2001 12:18:04 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43472; Fri, 16 Feb 2001 11:47:09 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA49556; Fri, 16 Feb 2001 11:47:02 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA34846
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 11:46:48 -0500
Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA44098
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 11:46:38 -0500
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f1GGlAw26467;
	Fri, 16 Feb 2001 17:47:10 +0100 (CET)
Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79])
	by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP
	id 65F09C08B; Fri, 16 Feb 2001 18:54:08 +0100 (CET)
Date: Fri, 16 Feb 2001 17:48:00 +0100
From: Marcus Brunner <brunner@ccrle.nec.de>
To: traffic engineering WG <te-wg@UU.NET>
Cc: Policy Mailing List <policy@raleigh.ibm.com>
Subject: include MPLS information model as work item
Message-Id: <3093137091.982345680@[192.168.102.79]>
X-Mailer: Mulberry/2.0.6 (Win32)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

We ask for inclusion of the MPLS information model and the corresponding 
policy model as a work item in the TE-WG.

The draft in the second version can be found under
http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt

Marcus

- --------------------------------------
Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v2.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
PYZGnFnsd2OPFz+GqAI3avgc
=wbMS
-----END PGP SIGNATURE-----



From majordomo@raleigh.ibm.com  Fri Feb 16 16:29:13 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09999
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 16:29:13 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA30938;
	Fri, 16 Feb 2001 16:23:03 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA32698;
	Fri, 16 Feb 2001 16:22:46 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA62492; Fri, 16 Feb 2001 15:51:08 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA56850; Fri, 16 Feb 2001 15:51:05 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA33286
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 15:50:34 -0500
Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA38920
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 15:50:18 -0500
Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21)
	id <FCMGQY8K>; Fri, 16 Feb 2001 15:40:36 -0500
Message-Id: <A3617F281546D411958C00D0B760121CEBDD38@bor.ellacoya.com>
From: "Weiss, Walter" <wweiss@ellacoya.com>
To: "'John Strassner'" <jstrassn@cisco.com>
Cc: "Joel M. Halpern" <joel@longsys.com>, Robert Moore
	 <remoore@us.ibm.com>,
        policy@raleigh.ibm.com
Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe technica
	 l meeting, 1/24/01 - 1/26/01)
Date: Fri, 16 Feb 2001 15:40:36 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C09858.B7444EA8"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Weiss, Walter" <wweiss@ellacoya.com>

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_01C09858.B7444EA8
Content-Type: text/plain;
	charset="iso-8859-1"

John,

Thanks for the comments. Additional clarifications follow inline:

John, 

I am confused by the following statements: 

> What the real problem is that QPIM has 
> introduced several 
> notions that are completely lacking in QDDIM: 
> 
>    - constraining the values of a variable or constant 
Doesn't an information model explicitly constrain the allowable values of an
attribute? 

<js>
No. What I'm talking about here is the ability to specify and model
constraints. Saying that an attribute is a uint8 explicitly constrains the
legal range of values that the attribute can take. What I'm looking at is in
addition, constraining the allowable range of values that an attribute can
have for a particular application (e.g., 0-63 instead of 0-127), attaching
special semantics to certain values (as is commonly done in MIBs), and
defining special relationships between a value of an attribute and something
else. OCL would be the easiest (though possibly not the most efficient) way
to do this with our model.
</js>
<ww>
Are you really suggesting dynamic bindings of constraints on attribute? On
my last reading of QPIM, I did not see semantics for this. Is this a new
feature? Can you give an example of how it is specified?
</ww>

>    - constraining the data types of a variable or constant 
Can you explain what you mean here? Are you refering to the semantics of
variables within an expression? If so, isn't this more a function of the
language semantics for the expression of variables (ie. Perl notion of a
variable is somewhat different from C).

<js> See above </js>



>    - binding a variable to a value 
Isn't this also a language semantic? 

<js>
No. For example, in QPIM we may be dealing with an IPAddress, and want to
restrict the values of said variable to just IPv4 addresses that are in CIDR
format.
</js>
<ww>
Does binding refer to an assignment or a dynamic constraint on allowable
values of the variable? In my comment I was assuming the former.
</ww>


> 

It seems to me that QDDIM fits rather nicely into an expression based
language. If we consider a QDDIM object as a structured data type, it maps
rather well. The ultimate question with respect to variables is where the
base variables are defined. Do we use QDDIM or a derivative or do we define
a whole new set of variables that duplicates all the semantics described in
QDDIM?

If we start from scratch, the most convenient approach is to create a list
of possible variables. However, as the list grows longer, organizing the
attributes is inevitable. A good parallel would be Fortran with flat
attributes, C with structures, and Java with classes. Since experience tells
us that structure is inevitable, we may as well define the structures now.
If we do, we have come full circle back to where QDDIM is now.

<js> Sorry, you lost me here. Can you please elaborate? </js>
<ww>
The set of attributes defined as "variables" in QPIM is a subset of a much
larger number of variables that would facilitate the configuration of
network devices. In fact, I would be hard pressed to find an attribute in
QDDIM that would not eventually end up in this list of "variables". That is
just in the QoS space. When we add security, admission control, traffic
engineering, and user identity, the size of this list explodes. Further,
because the list is flat, the interactions between different variables,
reusability, semantic consistency, interrelationships to "extension"
variables also increased the complexity. These are the classic arguements
for why structures are important. This inevitably leads to questions of
scoping which migrates structured variables to classes. Once you have
decided to manage variables within the context of classes, you have QDDIM :)
</ww>

regards, 

-Walter 

------_=_NextPart_001_01C09858.B7444EA8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Packet Filtering (Re: Preliminary results from PCIMe =
technica l meeting, 1/24/01 - 1/26/01)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the comments. Additional clarifications =
follow inline:</FONT>
</P>

<P><FONT SIZE=3D2>John, </FONT>
</P>

<P><FONT SIZE=3D2>I am confused by the following statements: </FONT>
</P>

<P><FONT SIZE=3D2>&gt; What the real problem is that QPIM has </FONT>
<BR><FONT SIZE=3D2>&gt; introduced several </FONT>
<BR><FONT SIZE=3D2>&gt; notions that are completely lacking in QDDIM: =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - constraining the values of =
a variable or constant </FONT>
<BR><FONT SIZE=3D2>Doesn't an information model explicitly constrain =
the allowable values of an attribute? </FONT>
</P>

<P><FONT SIZE=3D2>&lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>No. What I'm talking about here is the ability to =
specify and model constraints. Saying that an attribute is a uint8 =
explicitly constrains the legal range of values that the attribute can =
take. What I'm looking at is in addition, constraining the allowable =
range of values that an attribute can have for a particular application =
(e.g., 0-63 instead of 0-127), attaching special semantics to certain =
values (as is commonly done in MIBs), and defining special =
relationships between a value of an attribute and something else. OCL =
would be the easiest (though possibly not the most efficient) way to do =
this with our model.</FONT></P>

<P><FONT SIZE=3D2>&lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;ww&gt;</FONT>
<BR><FONT SIZE=3D2>Are you really suggesting dynamic bindings of =
constraints on attribute? On my last reading of QPIM, I did not see =
semantics for this. Is this a new feature? Can you give an example of =
how it is specified?</FONT></P>

<P><FONT SIZE=3D2>&lt;/ww&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - constraining the data types =
of a variable or constant </FONT>
<BR><FONT SIZE=3D2>Can you explain what you mean here? Are you refering =
to the semantics of variables within an expression? If so, isn't this =
more a function of the language semantics for the expression of =
variables (ie. Perl notion of a variable is somewhat different from =
C).</FONT></P>

<P><FONT SIZE=3D2>&lt;js&gt; See above &lt;/js&gt;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; - binding a variable to a =
value </FONT>
<BR><FONT SIZE=3D2>Isn't this also a language semantic? </FONT>
</P>

<P><FONT SIZE=3D2>&lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>No. For example, in QPIM we may be dealing with an =
IPAddress, and want to restrict the values of said variable to just =
IPv4 addresses that are in CIDR format.</FONT></P>

<P><FONT SIZE=3D2>&lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;ww&gt;</FONT>
<BR><FONT SIZE=3D2>Does binding refer to an assignment or a dynamic =
constraint on allowable values of the variable? In my comment I was =
assuming the former.</FONT></P>

<P><FONT SIZE=3D2>&lt;/ww&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>It seems to me that QDDIM fits rather nicely into an =
expression based language. If we consider a QDDIM object as a =
structured data type, it maps rather well. The ultimate question with =
respect to variables is where the base variables are defined. Do we use =
QDDIM or a derivative or do we define a whole new set of variables that =
duplicates all the semantics described in QDDIM?</FONT></P>

<P><FONT SIZE=3D2>If we start from scratch, the most convenient =
approach is to create a list of possible variables. However, as the =
list grows longer, organizing the attributes is inevitable. A good =
parallel would be Fortran with flat attributes, C with structures, and =
Java with classes. Since experience tells us that structure is =
inevitable, we may as well define the structures now. If we do, we have =
come full circle back to where QDDIM is now.</FONT></P>

<P><FONT SIZE=3D2>&lt;js&gt; Sorry, you lost me here. Can you please =
elaborate? &lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&lt;ww&gt;</FONT>
<BR><FONT SIZE=3D2>The set of attributes defined as =
&quot;variables&quot; in QPIM is a subset of a much larger number of =
variables that would facilitate the configuration of network devices. =
In fact, I would be hard pressed to find an attribute in QDDIM that =
would not eventually end up in this list of &quot;variables&quot;. That =
is just in the QoS space. When we add security, admission control, =
traffic engineering, and user identity, the size of this list explodes. =
Further, because the list is flat, the interactions between different =
variables, reusability, semantic consistency, interrelationships to =
&quot;extension&quot; variables also increased the complexity. These =
are the classic arguements for why structures are important. This =
inevitably leads to questions of scoping which migrates structured =
variables to classes. Once you have decided to manage variables within =
the context of classes, you have QDDIM :)</FONT></P>

<P><FONT SIZE=3D2>&lt;/ww&gt;</FONT>
</P>

<P><FONT SIZE=3D2>regards, </FONT>
</P>

<P><FONT SIZE=3D2>-Walter </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C09858.B7444EA8--


From majordomo@raleigh.ibm.com  Fri Feb 16 17:01:20 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10475
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 17:01:19 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA31798;
	Fri, 16 Feb 2001 16:52:16 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA33302;
	Fri, 16 Feb 2001 16:52:17 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA08308; Fri, 16 Feb 2001 16:18:59 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52330; Fri, 16 Feb 2001 16:18:55 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA29666
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 16:18:54 -0500
From: steven.wright@snt.BellSouth.com
Received: from blsmsgims01.bls.com (connectandcreate2.bls.com [139.76.64.29])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA35738
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 16:18:50 -0500
Received: from SMTP (blsmsgims01.bls.com [139.76.86.20]) by blsmsgims01.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FA66L5BM; Fri, 16 Feb 2001 16:18:18 -0500
Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.20
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 16 Feb 2001 21:18:18 0000 (GMT)
Received: from snt1.bst.bls.com (snt1 [90.30.213.3])
	by snt.bellsouth.com (8.9.3+Sun/8.9.1) with ESMTP id QAA01791;
	Fri, 16 Feb 2001 16:17:57 -0500 (EST)
Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt1.bst.bls.com (8.8.8+Sun/8.6.12) with SMTP id QAA12613; Fri, 16 Feb 2001 16:18:07 -0500 (EST)
To: "'Jim Boyle'" <jboyle@Level3.net>,
        "'Marcus Brunner'" <brunner@ccrle.nec.de>
Cc: "'traffic engineering WG'" <te-wg@UU.NET>,
        "'Policy Mailing List'" <policy@raleigh.ibm.com>
Subject: RE: include MPLS information model as work item
Date: Fri, 16 Feb 2001 16:18:03 -0500
Message-Id: <06EABA5FD323D411B733009027DCF1B0175918@natasha.snt.bst.bls.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <06EABA5FD323D411B733009027DCF1B029CF0D@natasha.snt.bst.bls.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: steven.wright@snt.BellSouth.com
Content-Transfer-Encoding: 7bit

tewg covers the te related MIBs  so I would think that it should cover the
te related policy work.

IMHO the policy wg folks are focused on the generic policy issues -e.g. how
to structure a policy definition, policy protocol religions (e.g. COPS vs
SNMP vs LDAP vs XML) etc. What is more interesting to discuss here is what
are the appropriate policies to use when operating a network for traffic
engineering purposes?

We can have a discussion about relative priorities, but with a trail of
internet drafts on related subjects in the past year, from folks in at least
five different companies, I think there is demonstrated demand for some
progress in this area.

regards
Steven Wright, Ph.D.
Network Architecture
Science and Technology
BellSouth Telecommunications
phone (404) 332-2194
fax (404) 529-8025


> -----Original Message-----
> From: owner-te-wg@UU.NET [mailto:owner-te-wg@UU.NET]On Behalf Of Jim
> Boyle
> Sent: Friday, February 16, 2001 1:58 PM
> To: Marcus Brunner
> Cc: traffic engineering WG; Policy Mailing List
> Subject: Re: include MPLS information model as work item
>
>
>
>
>
> It currently isn't in our charter, nor does there appear to
> be an immenent
> demand for this type of interaction with the network elements, judging
> from the response in the WG meetings (and the list traffic).
> Perhaps a
> policy WG (or individual work) might be the better place to
> show how one
> could use, for instance, RFC2749 type of techniques to
> control either TE
> cores, or LSP based L2 VPNs.  But currently we have our hands full
> documenting current uses, practices, and pressing demands.
>
> regards,
>
> Jim
>
>
>
> On Fri, 16 Feb 2001, Marcus Brunner wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear all,
> >
> > We ask for inclusion of the MPLS information model and the
> corresponding
> > policy model as a work item in the TE-WG.
> >
> > The draft in the second version can be found under
> >
http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
>
> Marcus
>
> - --------------------------------------
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155
>
> -----BEGIN PGP SIGNATURE-----
> Version: Mulberry PGP Plugin v2.0
> Comment: processed by Mulberry PGP Plugin
>
> iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> PYZGnFnsd2OPFz+GqAI3avgc
> =wbMS
> -----END PGP SIGNATURE-----
>






From majordomo@raleigh.ibm.com  Fri Feb 16 17:13:50 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10599
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 17:13:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA19792;
	Fri, 16 Feb 2001 17:08:12 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA28736;
	Fri, 16 Feb 2001 17:08:07 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA62054; Fri, 16 Feb 2001 16:39:46 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52330; Fri, 16 Feb 2001 16:18:55 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA29666
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 16:18:54 -0500
From: steven.wright@snt.BellSouth.com
Received: from blsmsgims01.bls.com (connectandcreate2.bls.com [139.76.64.29])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA35738
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 16:18:50 -0500
Received: from SMTP (blsmsgims01.bls.com [139.76.86.20]) by blsmsgims01.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id FA66L5BM; Fri, 16 Feb 2001 16:18:18 -0500
Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.20
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 16 Feb 2001 21:18:18 0000 (GMT)
Received: from snt1.bst.bls.com (snt1 [90.30.213.3])
	by snt.bellsouth.com (8.9.3+Sun/8.9.1) with ESMTP id QAA01791;
	Fri, 16 Feb 2001 16:17:57 -0500 (EST)
Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt1.bst.bls.com (8.8.8+Sun/8.6.12) with SMTP id QAA12613; Fri, 16 Feb 2001 16:18:07 -0500 (EST)
To: "'Jim Boyle'" <jboyle@Level3.net>,
        "'Marcus Brunner'" <brunner@ccrle.nec.de>
Cc: "'traffic engineering WG'" <te-wg@UU.NET>,
        "'Policy Mailing List'" <policy@raleigh.ibm.com>
Subject: RE: include MPLS information model as work item
Date: Fri, 16 Feb 2001 16:18:03 -0500
Message-Id: <06EABA5FD323D411B733009027DCF1B0175918@natasha.snt.bst.bls.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <06EABA5FD323D411B733009027DCF1B029CF0D@natasha.snt.bst.bls.com>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: steven.wright@snt.BellSouth.com
Content-Transfer-Encoding: 7bit

tewg covers the te related MIBs  so I would think that it should cover the
te related policy work.

IMHO the policy wg folks are focused on the generic policy issues -e.g. how
to structure a policy definition, policy protocol religions (e.g. COPS vs
SNMP vs LDAP vs XML) etc. What is more interesting to discuss here is what
are the appropriate policies to use when operating a network for traffic
engineering purposes?

We can have a discussion about relative priorities, but with a trail of
internet drafts on related subjects in the past year, from folks in at least
five different companies, I think there is demonstrated demand for some
progress in this area.

regards
Steven Wright, Ph.D.
Network Architecture
Science and Technology
BellSouth Telecommunications
phone (404) 332-2194
fax (404) 529-8025


> -----Original Message-----
> From: owner-te-wg@UU.NET [mailto:owner-te-wg@UU.NET]On Behalf Of Jim
> Boyle
> Sent: Friday, February 16, 2001 1:58 PM
> To: Marcus Brunner
> Cc: traffic engineering WG; Policy Mailing List
> Subject: Re: include MPLS information model as work item
>
>
>
>
>
> It currently isn't in our charter, nor does there appear to
> be an immenent
> demand for this type of interaction with the network elements, judging
> from the response in the WG meetings (and the list traffic).
> Perhaps a
> policy WG (or individual work) might be the better place to
> show how one
> could use, for instance, RFC2749 type of techniques to
> control either TE
> cores, or LSP based L2 VPNs.  But currently we have our hands full
> documenting current uses, practices, and pressing demands.
>
> regards,
>
> Jim
>
>
>
> On Fri, 16 Feb 2001, Marcus Brunner wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear all,
> >
> > We ask for inclusion of the MPLS information model and the
> corresponding
> > policy model as a work item in the TE-WG.
> >
> > The draft in the second version can be found under
> >
http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
>
> Marcus
>
> - --------------------------------------
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: brunner@ccrle.nec.de
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155
>
> -----BEGIN PGP SIGNATURE-----
> Version: Mulberry PGP Plugin v2.0
> Comment: processed by Mulberry PGP Plugin
>
> iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> PYZGnFnsd2OPFz+GqAI3avgc
> =wbMS
> -----END PGP SIGNATURE-----
>






From majordomo@raleigh.ibm.com  Fri Feb 16 18:00:49 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11376
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 18:00:48 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA27660;
	Fri, 16 Feb 2001 17:54:43 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA28662;
	Fri, 16 Feb 2001 17:54:40 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA58900; Fri, 16 Feb 2001 17:30:34 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34818; Fri, 16 Feb 2001 17:30:28 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA26182
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 17:30:29 -0500
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA33364
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 17:30:24 -0500
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1GMT4r00759;
	Fri, 16 Feb 2001 16:29:04 -0600 (CST)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f1GMOsY16183;
	Fri, 16 Feb 2001 16:24:54 -0600 (CST)
Received: from LMC37.lmc.ericsson.se (lmc51.lmc.ericsson.se [142.133.16.191])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id f1GMT3703302;
	Fri, 16 Feb 2001 17:29:03 -0500 (EST)
Received: by lmc37.lmc.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <1Z5TMVCQ>; Fri, 16 Feb 2001 17:29:03 -0500
Message-Id: <32CD630F6CBED411AE180008C7894CBC72CBFF@lmc37.lmc.ericsson.se>
From: "Youcef Dahmane (LMC)" <lmcytah@lmc.ericsson.se>
To: "'ydahmane@yahoo.com'" <ydahmane@yahoo.com>
Cc: "'traffic engineering WG'" <te-wg@UU.NET>,
        "'Policy Mailing List'"
	 <policy@raleigh.ibm.com>
Subject: RE: include MPLS information model as work item
Date: Fri, 16 Feb 2001 17:28:53 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Youcef Dahmane (LMC)" <lmcytah@lmc.ericsson.se>



> -----Original Message-----
> From:	steven.wright@snt.BellSouth.com
> [SMTP:steven.wright@snt.BellSouth.com]
> Sent:	Friday, February 16, 2001 4:18 PM
> To:	'Jim Boyle'; 'Marcus Brunner'
> Cc:	'traffic engineering WG'; 'Policy Mailing List'
> Subject:	RE: include MPLS information model as work item
> 
> tewg covers the te related MIBs  so I would think that it should cover the
> te related policy work.
> 
> IMHO the policy wg folks are focused on the generic policy issues -e.g.
> how
> to structure a policy definition, policy protocol religions (e.g. COPS vs
> SNMP vs LDAP vs XML) etc. What is more interesting to discuss here is what
> are the appropriate policies to use when operating a network for traffic
> engineering purposes?
> 
> We can have a discussion about relative priorities, but with a trail of
> internet drafts on related subjects in the past year, from folks in at
> least
> five different companies, I think there is demonstrated demand for some
> progress in this area.
> 
> regards
> Steven Wright, Ph.D.
> Network Architecture
> Science and Technology
> BellSouth Telecommunications
> phone (404) 332-2194
> fax (404) 529-8025
> 
> 
> > -----Original Message-----
> > From: owner-te-wg@UU.NET [mailto:owner-te-wg@UU.NET]On Behalf Of Jim
> > Boyle
> > Sent: Friday, February 16, 2001 1:58 PM
> > To: Marcus Brunner
> > Cc: traffic engineering WG; Policy Mailing List
> > Subject: Re: include MPLS information model as work item
> >
> >
> >
> >
> >
> > It currently isn't in our charter, nor does there appear to
> > be an immenent
> > demand for this type of interaction with the network elements, judging
> > from the response in the WG meetings (and the list traffic).
> > Perhaps a
> > policy WG (or individual work) might be the better place to
> > show how one
> > could use, for instance, RFC2749 type of techniques to
> > control either TE
> > cores, or LSP based L2 VPNs.  But currently we have our hands full
> > documenting current uses, practices, and pressing demands.
> >
> > regards,
> >
> > Jim
> >
> >
> >
> > On Fri, 16 Feb 2001, Marcus Brunner wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Dear all,
> > >
> > > We ask for inclusion of the MPLS information model and the
> > corresponding
> > > policy model as a work item in the TE-WG.
> > >
> > > The draft in the second version can be found under
> > >
> http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
> >
> > Marcus
> >
> > - --------------------------------------
> > Dr. Marcus Brunner
> > C&C Research Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW:    http://www.ccrle.nec.de/
> > personal home page: http://www.tik.ee.ethz.ch/~brunner
> >
> > Adenauerplatz 6
> > D-69115 Heidelberg
> > Germany
> >
> > Phone: +49 (0)6221/ 9051129
> > Fax:   +49 (0)6221/ 9051155
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: Mulberry PGP Plugin v2.0
> > Comment: processed by Mulberry PGP Plugin
> >
> > iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> > PYZGnFnsd2OPFz+GqAI3avgc
> > =wbMS
> > -----END PGP SIGNATURE-----
> >
> 
> 
> 


From majordomo@raleigh.ibm.com  Fri Feb 16 21:57:54 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14615
	for <policy-archive@odin.ietf.org>; Fri, 16 Feb 2001 21:57:53 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA21416;
	Fri, 16 Feb 2001 21:52:21 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA29262;
	Fri, 16 Feb 2001 21:52:19 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA55858; Fri, 16 Feb 2001 21:25:33 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA15146; Fri, 16 Feb 2001 21:25:30 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA27292
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 21:25:31 -0500
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA40096
	for <policy@raleigh.ibm.com>; Fri, 16 Feb 2001 21:25:29 -0500
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14Tx3g-0000pG-00; Fri, 16 Feb 2001 18:25:12 -0800
From: Randy Bush <randy@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ritu Chadha <chadha@research.telcordia.com>
Cc: policy@raleigh.ibm.com, te-wg@UU.NET
Subject: Re: include MPLS information model as work item
References: <200102170049.TAA00748@monday.research.telcordia.com>
Message-Id: <E14Tx3g-0000pG-00@rip.psg.com>
Date: Fri, 16 Feb 2001 18:25:12 -0800
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Randy Bush <randy@psg.com>
Content-Transfer-Encoding: 7bit

bert may choose to speak for policy, but this is not within the scope of
tewg.

randy, with AD hat on

---

> This topic has been discussed at the Pittsburgh and the San Diego
> meetings of the Policy WG. The consensus there was that work
> on a policy model for MPLS TE should be done in a workgroup
> where the subject matter experts for MPLS TE reside - for the
> same reason that SNMP MIBs are developed by the technology
> experts rather than in the SNMPv3 WG.
> 
> I don't believe that there was a lack of interest in MPLS TE
> policy at the San Diego tewg meeting. There was a reasonable
> show of hands of people who were interested in seeing this
> work pursued. 
> 
> Ritu
> 
> 
> >It currently isn't in our charter, nor does there appear to be an immenent
> >demand for this type of interaction with the network elements, judging
> >from the response in the WG meetings (and the list traffic).  Perhaps a
> >policy WG (or individual work) might be the better place to show how one
> >could use, for instance, RFC2749 type of techniques to control either TE
> >cores, or LSP based L2 VPNs.  But currently we have our hands full
> >documenting current uses, practices, and pressing demands.
> >
> >regards,
> >
> >Jim
> >
> >
> >
> >On Fri, 16 Feb 2001, Marcus Brunner wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> 
> >> Dear all,
> >> 
> >> We ask for inclusion of the MPLS information model and the corresponding 
> >> policy model as a work item in the TE-WG.
> >> 
> >> The draft in the second version can be found under
> >> http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
> >> 
> >> Marcus
> >> 
> >> - --------------------------------------
> >> Dr. Marcus Brunner
> >> C&C Research Laboratories
> >> NEC Europe Ltd.
> >> 
> >> E-Mail: brunner@ccrle.nec.de
> >> WWW:    http://www.ccrle.nec.de/
> >> personal home page: http://www.tik.ee.ethz.ch/~brunner
> >> 
> >> Adenauerplatz 6
> >> D-69115 Heidelberg
> >> Germany
> >> 
> >> Phone: +49 (0)6221/ 9051129
> >> Fax:   +49 (0)6221/ 9051155
> >> 
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: Mulberry PGP Plugin v2.0
> >> Comment: processed by Mulberry PGP Plugin
> >> 
> >> iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> >> PYZGnFnsd2OPFz+GqAI3avgc
> >> =wbMS
> >> -----END PGP SIGNATURE-----
> >> 
> >
> >


From majordomo@raleigh.ibm.com  Sun Feb 18 00:10:01 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12524
	for <policy-archive@odin.ietf.org>; Sun, 18 Feb 2001 00:10:01 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA05982;
	Sun, 18 Feb 2001 00:02:49 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA24934;
	Sun, 18 Feb 2001 00:02:35 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA63252; Sat, 17 Feb 2001 23:20:32 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA63756; Sat, 17 Feb 2001 23:20:28 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA19286
	for <policy@raleigh.ibm.com>; Sat, 17 Feb 2001 23:20:31 -0500
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA20574
	for <policy@raleigh.ibm.com>; Sat, 17 Feb 2001 23:20:28 -0500
Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA19576;
	Sat, 17 Feb 2001 20:20:13 -0800 (PST)
Received: from JSTRASSN-W2K1.cisco.com (sj-dial-4-70.cisco.com [171.68.181.199])
	by mira-sjcm-1.cisco.com (Mirapoint)
	with ESMTP id ALO03199;
	Sat, 17 Feb 2001 20:19:45 -0800 (PST)
Message-Id: <4.3.2.7.2.20010217140303.00b207d0@mira-sjcm-1.cisco.com>
X-Sender: jstrassn@mira-sjcm-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 17 Feb 2001 14:08:31 -0800
To: "Weiss, Walter" <wweiss@ellacoya.com>
From: John Strassner <jstrassn@cisco.com>
Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe
  technica l meeting, 1/24/01 - 1/26/01)
Cc: "'John Strassner'" <jstrassn@cisco.com>,
        "Joel M. Halpern" <joel@longsys.com>,
        Robert Moore <remoore@us.ibm.com>, policy@raleigh.ibm.com
In-Reply-To: <A3617F281546D411958C00D0B760121CEBDD38@bor.ellacoya.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: John Strassner <jstrassn@cisco.com>

Please see inline, look for <js2>..</js2>.

regards,
John

At 03:40 PM 2/16/2001 -0500, Weiss, Walter wrote:

>John,
>
>Thanks for the comments. Additional clarifications follow inline:
>
>John,
>
>I am confused by the following statements:
>
> > What the real problem is that QPIM has
> > introduced several
> > notions that are completely lacking in QDDIM:
> >
> >    - constraining the values of a variable or constant
>Doesn't an information model explicitly constrain the allowable values of 
>an attribute?
>
><js>
>No. What I'm talking about here is the ability to specify and model 
>constraints. Saying that an attribute is a uint8 explicitly constrains the 
>legal range of values that the attribute can take. What I'm looking at is 
>in addition, constraining the allowable range of values that an attribute 
>can have for a particular application (e.g., 0-63 instead of 0-127), 
>attaching special semantics to certain values (as is commonly done in 
>MIBs), and defining special relationships between a value of an attribute 
>and something else. OCL would be the easiest (though possibly not the most 
>efficient) way to do this with our model.
>
></js>
><ww>
>Are you really suggesting dynamic bindings of constraints on attribute? On 
>my last reading of QPIM, I did not see semantics for this. Is this a new 
>feature? Can you give an example of how it is specified?
></ww>

<js2>
You're reading too much into what I said. I never used the word "dynamic". 
I simply said that there are additional constraints that one can impose on 
an attribute. Restricting the range of a uint8 to 0..63 is one such example.
</js2>

> >    - constraining the data types of a variable or constant
>Can you explain what you mean here? Are you refering to the semantics of 
>variables within an expression? If so, isn't this more a function of the 
>language semantics for the expression of variables (ie. Perl notion of a 
>variable is somewhat different from C).
>
><js> See above </js>
>
>
> >    - binding a variable to a value
>Isn't this also a language semantic?
>
><js>
>No. For example, in QPIM we may be dealing with an IPAddress, and want to 
>restrict the values of said variable to just IPv4 addresses that are in 
>CIDR format.
>
></js>
><ww>
>Does binding refer to an assignment or a dynamic constraint on allowable 
>values of the variable? In my comment I was assuming the former.
></ww>

<js2>
Not sure why you're hung up on dynamic entries. I never said the word dynamic.
</js2>

> >It seems to me that QDDIM fits rather nicely into an expression based 
> language. If we consider a QDDIM object as a structured data type, it 
> maps rather well. The ultimate question with respect to variables is 
> where the base variables are defined. Do we use QDDIM or a derivative or 
> do we define a whole new set of variables that duplicates all the 
> semantics described in QDDIM?
>
>If we start from scratch, the most convenient approach is to create a list 
>of possible variables. However, as the list grows longer, organizing the 
>attributes is inevitable. A good parallel would be Fortran with flat 
>attributes, C with structures, and Java with classes. Since experience 
>tells us that structure is inevitable, we may as well define the 
>structures now. If we do, we have come full circle back to where QDDIM is now.
>
><js> Sorry, you lost me here. Can you please elaborate? </js>
><ww>
>The set of attributes defined as "variables" in QPIM is a subset of a much 
>larger number of variables that would facilitate the configuration of 
>network devices. In fact, I would be hard pressed to find an attribute in 
>QDDIM that would not eventually end up in this list of "variables". That 
>is just in the QoS space. When we add security, admission control, traffic 
>engineering, and user identity, the size of this list explodes. Further, 
>because the list is flat, the interactions between different variables, 
>reusability, semantic consistency, interrelationships to "extension" 
>variables also increased the complexity. These are the classic arguements 
>for why structures are important. This inevitably leads to questions of 
>scoping which migrates structured variables to classes. Once you have 
>decided to manage variables within the context of classes, you have QDDIM :)
></ww>

<js2>
I see no requirement to force people to represent variables or not. 
Furthermore, if they want to represent variables, then this wg has given 
them two different means to accomplish the same task. They can use a 
class-based approach, as in QDDIM, or they can use a finer-grained 
approach, as in QPIM. We should not dictate which representation people 
choose, but it is application-specific.
</js2>


>regards,
>
>-Walter



From majordomo@raleigh.ibm.com  Sun Feb 18 21:20:59 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13137
	for <policy-archive@odin.ietf.org>; Sun, 18 Feb 2001 21:20:58 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA26904;
	Sun, 18 Feb 2001 21:08:02 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA27928;
	Sun, 18 Feb 2001 21:07:59 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA15254; Sun, 18 Feb 2001 17:34:26 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA38542; Sun, 18 Feb 2001 17:34:23 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA33682
	for <policy@raleigh.ibm.com>; Sun, 18 Feb 2001 17:34:24 -0500
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA19712
	for <policy@raleigh.ibm.com>; Sun, 18 Feb 2001 17:34:21 -0500
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id WAA17262;
	Sun, 18 Feb 2001 22:33:07 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Sun, 18 Feb 2001 22:33:10 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <17GBNRYQ>; Sun, 18 Feb 2001 14:33:08 -0800
Message-Id: <4148FEAAD879D311AC5700A0C969E8905730B7@orsmsx35.jf.intel.com>
From: "Hahn, Scott" <scott.hahn@intel.com>
To: "'Randy Bush'" <randy@psg.com>,
        Ritu Chadha
	 <chadha@research.telcordia.com>
Cc: policy@raleigh.ibm.com, te-wg@UU.NET
Subject: RE: include MPLS information model as work item
Date: Sun, 18 Feb 2001 14:33:06 -0800
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Hahn, Scott" <scott.hahn@intel.com>

I would like some clarification on this. The charter states that the WG is
concerned with "measurement and control aspects" of TE. To this end the WG
has accepted the MIB as a WG item. Given the lively discussion on whether
the MIB should be read-only vs. read-write, it seems that the MIB is not the
sole answer to the "measurement and control" aspect. This work might fit
into the control aspect of TE and as such, would fit into the charter. Why
is this not the case?


> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Friday, February 16, 2001 6:25 PM
> To: Ritu Chadha
> Cc: policy@raleigh.ibm.com; te-wg@UU.NET
> Subject: Re: include MPLS information model as work item
> 
> 
> bert may choose to speak for policy, but this is not within 
> the scope of
> tewg.
> 
> randy, with AD hat on
> 
> ---
> 
> > This topic has been discussed at the Pittsburgh and the San Diego
> > meetings of the Policy WG. The consensus there was that work
> > on a policy model for MPLS TE should be done in a workgroup
> > where the subject matter experts for MPLS TE reside - for the
> > same reason that SNMP MIBs are developed by the technology
> > experts rather than in the SNMPv3 WG.
> > 
> > I don't believe that there was a lack of interest in MPLS TE
> > policy at the San Diego tewg meeting. There was a reasonable
> > show of hands of people who were interested in seeing this
> > work pursued. 
> > 
> > Ritu
> > 
> > 
> > >It currently isn't in our charter, nor does there appear 
> to be an immenent
> > >demand for this type of interaction with the network 
> elements, judging
> > >from the response in the WG meetings (and the list 
> traffic).  Perhaps a
> > >policy WG (or individual work) might be the better place 
> to show how one
> > >could use, for instance, RFC2749 type of techniques to 
> control either TE
> > >cores, or LSP based L2 VPNs.  But currently we have our hands full
> > >documenting current uses, practices, and pressing demands.
> > >
> > >regards,
> > >
> > >Jim
> > >
> > >
> > >
> > >On Fri, 16 Feb 2001, Marcus Brunner wrote:
> > >
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >> 
> > >> Dear all,
> > >> 
> > >> We ask for inclusion of the MPLS information model and 
> the corresponding 
> > >> policy model as a work item in the TE-WG.
> > >> 
> > >> The draft in the second version can be found under
> > >> 
http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
> >> 
> >> Marcus
> >> 
> >> - --------------------------------------
> >> Dr. Marcus Brunner
> >> C&C Research Laboratories
> >> NEC Europe Ltd.
> >> 
> >> E-Mail: brunner@ccrle.nec.de
> >> WWW:    http://www.ccrle.nec.de/
> >> personal home page: http://www.tik.ee.ethz.ch/~brunner
> >> 
> >> Adenauerplatz 6
> >> D-69115 Heidelberg
> >> Germany
> >> 
> >> Phone: +49 (0)6221/ 9051129
> >> Fax:   +49 (0)6221/ 9051155
> >> 
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: Mulberry PGP Plugin v2.0
> >> Comment: processed by Mulberry PGP Plugin
> >> 
> >> iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> >> PYZGnFnsd2OPFz+GqAI3avgc
> >> =wbMS
> >> -----END PGP SIGNATURE-----
> >> 
> >
> >



From majordomo@raleigh.ibm.com  Mon Feb 19 07:06:25 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02069
	for <policy-archive@odin.ietf.org>; Mon, 19 Feb 2001 07:06:25 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA17408;
	Mon, 19 Feb 2001 06:59:01 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA27570;
	Mon, 19 Feb 2001 06:58:55 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA53268; Mon, 19 Feb 2001 06:20:07 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51450; Mon, 19 Feb 2001 06:20:03 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA30208
	for <policy@raleigh.ibm.com>; Mon, 19 Feb 2001 06:20:03 -0500
Received: from cisco.com (sigma.cisco.com [171.69.26.43])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA35560
	for <policy@raleigh.ibm.com>; Mon, 19 Feb 2001 06:20:01 -0500
Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id DAA15568;
	Mon, 19 Feb 2001 03:19:30 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>, <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Mon, 19 Feb 2001 03:20:52 -0800
Message-Id: <GGEOLLMKEOKMFKADFNHOEEGODFAA.andreaw@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: <C1434589DE6ED411885900508BDF604D014B18D0@vbeexc01.vbe.cpqcorp.net>
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrea Westerinen" <andreaw@cisco.com>
Content-Transfer-Encoding: 7bit

There is a DTD defined by the DMTF for mapping CIM into XML.  See
http://www.dmtf.org/spec/wbem.html and page down to Specifications.

Andrea

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bouarich, Reda
Sent: Friday, February 16, 2001 2:02 AM
To: 'policy@raleigh.ibm.com'
Subject: example of a Policy Core Inofrmation Model to XML mapping


Dear All,
I am trying to specify a certain policy (if a bandwidth overload occurs
between 9am and 6pm then limit the ftp transfert
to 100 kb/sec for example) using the DMTF Policy COre Information Model.
First I have to map my policy properties on the standardized policy classes
defined by the DMTF then I have to map this Information model to XML.
Can anyone tell me where can I find some kind of concrete examples
representing such mapping cause it is the first time I do that and it not
clear in my mind!!.
Thanks a lot.
Reda Bouarich.



From majordomo@raleigh.ibm.com  Mon Feb 19 19:12:19 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18622
	for <policy-archive@odin.ietf.org>; Mon, 19 Feb 2001 19:12:19 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA07172;
	Mon, 19 Feb 2001 19:05:21 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA30276;
	Mon, 19 Feb 2001 19:05:13 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA51766; Mon, 19 Feb 2001 18:30:41 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA33824; Mon, 19 Feb 2001 18:30:37 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA25360
	for <policy@raleigh.ibm.com>; Mon, 19 Feb 2001 18:30:41 -0500
Received: from longsys.com (dmz.longsys.com [63.111.150.5])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA31060
	for <policy@raleigh.ibm.com>; Mon, 19 Feb 2001 18:30:37 -0500
Received: from joel (discordian.longsys.com [63.111.150.74])
	by longsys.com (8.10.0/8.10.0) with ESMTP id f1JMtf229301
	for <policy@raleigh.ibm.com>; Mon, 19 Feb 2001 22:55:41 GMT
Message-Id: <4.2.2.20010219175332.00c40e10@localhost>
X-Sender: joel@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 19 Feb 2001 17:54:06 -0500
To: policy@raleigh.ibm.com
From: "Joel M. Halpern" <joel@longsys.com>
Subject: Fwd: RFC 3060 on Policy Core Information Model 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Joel M. Halpern" <joel@longsys.com>

My congratulations and thanks to the authors and the working group.  We 
have an RFC.  Now lets get the rest done.
Yours,
Joel M. Halpern

> >From sendmail  Fri Feb 16 20:36:36 2001
>To: IETF-Announce: ;
>Subject: RFC 3060 on Policy Core Information Model
>Cc: rfc-ed@ISI.EDU, policy@RALEIGH.IBM.COM
>Date: Fri, 16 Feb 2001 10:40:09 -0800
>From: RFC Editor <rfc-ed@ISI.EDU>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 3060
>
>         Title:      Policy Core Information Model -- Version 1
>                     Specification
>         Author(s):  B. Moore, E. Ellesson, J. Strassner, A. Westerinen
>         Status:     Standards Track
>         Date:       February 2001
>         Mailbox:    eellesson@lboard.com, remoore@us.ibm.com,
>                     johns@cisco.com, andreaw@cisco.com
>         Pages:      100
>         Characters: 240309
>         Updates/Obsoletes/SeeAlso:  None
>
>         I-D Tag:    draft-ietf-policy-core-info-model-08.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3060.txt
>
>
>This document presents the object-oriented information model for
>representing policy information developed jointly in the IETF Policy
>Framework WG and as extensions to the Common Information Model (CIM)
>activity in the Distributed Management Task Force (DMTF).  This model
>defines two hierarchies of object classes:  structural classes
>representing policy information and control of policies, and
>association classes that indicate how instances of the structural
>classes are related to each other. Subsequent documents will define
>mappings of this information model to various concrete
>implementations, for example, to a directory that uses LDAPv3 as its
>access protocol.
>
>This document is a product of the Policy Framework Working Group of
>the IETF.
>
>This is now a Proposed Standard Protocol.
>
>This document specifies an Internet standards track protocol for
>the Internet community, and requests discussion and suggestions
>for improvements.  Please refer to the current edition of the
>"Internet Official Protocol Standards" (STD 1) for the
>standardization state and status of this protocol.  Distribution
>of this memo is unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
>help: ways_to_get_rfcs.  For example:
>
>         To: rfc-info@RFC-EDITOR.ORG
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.echo
>Submissions for Requests for Comments should be sent to
>RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>Joyce K. Reynolds and Sandy Ginoza
>USC/Information Sciences Institute
>
>...
>
>Below is the data which will enable a MIME compliant Mail Reader
>implementation to automatically retrieve the ASCII version
>of the RFCs.
>Content-Type: text/plain
>Content-ID: <010216103736.RFC@RFC-EDITOR.ORG>



From majordomo@raleigh.ibm.com  Tue Feb 20 03:28:07 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08871
	for <policy-archive@odin.ietf.org>; Tue, 20 Feb 2001 03:28:07 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA37180;
	Tue, 20 Feb 2001 03:16:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA23536;
	Tue, 20 Feb 2001 03:16:41 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52246; Tue, 20 Feb 2001 02:42:19 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA07586; Tue, 20 Feb 2001 02:42:10 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA30286
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 02:42:11 -0500
Received: from galaxy.npi.stpn.soft.net (IDENT:root@[12.10.197.146])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA24528
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 02:42:03 -0500
Received: from npi.stpn.soft.net ([192.9.201.124])
          by galaxy.npi.stpn.soft.net (8.9.3/8.8.4) with ESMTP
	  id NAA14150 for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 13:16:58 +0530
Message-Id: <3A921E98.C783BE81@npi.stpn.soft.net>
Date: Tue, 20 Feb 2001 13:06:57 +0530
From: Upma <upma@npi.stpn.soft.net>
Organization: npi
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
Mime-Version: 1.0
To: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: LDAP Schema 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Upma <upma@npi.stpn.soft.net>
Content-Transfer-Encoding: 7bit

Hello All,
    could we create our own schema ( like we have in RDBMS) in LDAP or
it's like we are only having certain fixed number of attributes meant
for Directory searching only ?

Thanx a lot
 Upma





From majordomo@raleigh.ibm.com  Tue Feb 20 12:38:58 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17999
	for <policy-archive@odin.ietf.org>; Tue, 20 Feb 2001 12:38:57 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA33700;
	Tue, 20 Feb 2001 12:30:25 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA25308;
	Tue, 20 Feb 2001 12:30:19 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA48078; Tue, 20 Feb 2001 11:59:31 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA52166; Tue, 20 Feb 2001 11:59:27 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA30332
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 11:59:30 -0500
Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24940
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 11:59:27 -0500
Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345)
	id 58868BA4F; Tue, 20 Feb 2001 11:58:59 -0500 (EST)
Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160])
	by zmamail03.zma.compaq.com (Postfix) with ESMTP id 74265B907
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 11:58:58 -0500 (EST)
Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <1VSVVMJN>; Tue, 20 Feb 2001 17:58:57 +0100
Message-Id: <C1434589DE6ED411885900508BDF604D014B18E2@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
To: "'Andrey Mishchenko'" <andrew@dcn.nord.nw.ru>
Cc: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Tue, 20 Feb 2001 17:58:53 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>

Hi Andrey,

Regarding to your reply, it seems that the LDAP repositery and the XML
description play the same role?
Is it true?
	regards,

Reda Bouarich
Compaq Telecom Engineering
tel +33 4 92 95 68 03
    +33 6 64 63 00 34

















-----Original Message-----
From: Andrey Mishchenko [mailto:andrew@dcn.nord.nw.ru]
Sent: Friday, February 16, 2001 5:35 PM
To: policy@raleigh.ibm.com
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


Larry & Reda,

Why may one want to use XML to represent policies
if they are initially stored in the LDAP-based repository?
Is this useful to aggregate all policy-related information,
such as reusable condition variables and actions in the
single object?

Thanks,

Andrey Mishchenko
andrew@dcn.nord.nw.ru

> Reda,
>
> Is your Policy data implemented in an LDAP-accessible repository?
>
> If it is, you could retrieve the information as XML, via a DSML
> facility, such as Castor or JNDI's DSML SPI. Once you have the
> DSML, you might be only one or two XSL transformations away from
> the particular XML format you desire.
>
> Although it is not Policy-specific, this article is a good tutorial
> on the use of DSML and XSL transformation:
>
> http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html
>
>
> "Bouarich, Reda" wrote:
> >
> > Dear All,
> > I am trying to specify a certain policy (if a bandwidth overload occurs
> > between 9am and 6pm then limit the ftp transfert
> > to 100 kb/sec for example) using the DMTF Policy COre Information Model.
> > First I have to map my policy properties on the standardized
> policy classes
> > defined by the DMTF then I have to map this Information model to XML.
> > Can anyone tell me where can I find some kind of concrete examples
> > representing such mapping cause it is the first time I do that
> and it not
> > clear in my mind!!.
> > Thanks a lot.
> > Reda Bouarich.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
>


From majordomo@raleigh.ibm.com  Tue Feb 20 14:50:58 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22515
	for <policy-archive@odin.ietf.org>; Tue, 20 Feb 2001 14:50:57 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA30022;
	Tue, 20 Feb 2001 14:42:21 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA34866;
	Tue, 20 Feb 2001 14:42:19 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA57300; Tue, 20 Feb 2001 14:15:37 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA45516; Tue, 20 Feb 2001 14:15:33 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA33732
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 14:15:37 -0500
Received: from cisco.com (sigma.cisco.com [171.69.26.43])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA24662
	for <policy@raleigh.ibm.com>; Tue, 20 Feb 2001 14:15:34 -0500
Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA12479;
	Tue, 20 Feb 2001 11:15:00 -0800 (PST)
From: "Andrea Westerinen" <andreaw@cisco.com>
To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>,
        "'Andrey Mishchenko'" <andrew@dcn.nord.nw.ru>
Cc: <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Tue, 20 Feb 2001 11:16:14 -0800
Message-Id: <GGEOLLMKEOKMFKADFNHOIEJEDFAA.andreaw@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <C1434589DE6ED411885900508BDF604D014B18E2@vbeexc01.vbe.cpqcorp.net>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrea Westerinen" <andreaw@cisco.com>
Content-Transfer-Encoding: 7bit

No, not the same roles.  An LDAP repository is just that - a repository of
information with defined access mechanisms.  The XML description of classes
is only an encoding.  This is very different.

Andrea

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bouarich, Reda
Sent: Tuesday, February 20, 2001 8:59 AM
To: 'Andrey Mishchenko'
Cc: 'policy@raleigh.ibm.com'
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


Hi Andrey,

Regarding to your reply, it seems that the LDAP repositery and the XML
description play the same role?
Is it true?
	regards,

Reda Bouarich
Compaq Telecom Engineering
tel +33 4 92 95 68 03
    +33 6 64 63 00 34

















-----Original Message-----
From: Andrey Mishchenko [mailto:andrew@dcn.nord.nw.ru]
Sent: Friday, February 16, 2001 5:35 PM
To: policy@raleigh.ibm.com
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


Larry & Reda,

Why may one want to use XML to represent policies
if they are initially stored in the LDAP-based repository?
Is this useful to aggregate all policy-related information,
such as reusable condition variables and actions in the
single object?

Thanks,

Andrey Mishchenko
andrew@dcn.nord.nw.ru

> Reda,
>
> Is your Policy data implemented in an LDAP-accessible repository?
>
> If it is, you could retrieve the information as XML, via a DSML
> facility, such as Castor or JNDI's DSML SPI. Once you have the
> DSML, you might be only one or two XSL transformations away from
> the particular XML format you desire.
>
> Although it is not Policy-specific, this article is a good tutorial
> on the use of DSML and XSL transformation:
>
> http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html
>
>
> "Bouarich, Reda" wrote:
> >
> > Dear All,
> > I am trying to specify a certain policy (if a bandwidth overload occurs
> > between 9am and 6pm then limit the ftp transfert
> > to 100 kb/sec for example) using the DMTF Policy COre Information Model.
> > First I have to map my policy properties on the standardized
> policy classes
> > defined by the DMTF then I have to map this Information model to XML.
> > Can anyone tell me where can I find some kind of concrete examples
> > representing such mapping cause it is the first time I do that
> and it not
> > clear in my mind!!.
> > Thanks a lot.
> > Reda Bouarich.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
>



From majordomo@raleigh.ibm.com  Wed Feb 21 05:45:09 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21765
	for <policy-archive@odin.ietf.org>; Wed, 21 Feb 2001 05:45:09 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA28190;
	Wed, 21 Feb 2001 05:29:14 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA02202;
	Wed, 21 Feb 2001 05:26:49 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA25278; Wed, 21 Feb 2001 04:54:31 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA43356; Wed, 21 Feb 2001 04:54:24 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA31412
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 04:54:26 -0500
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA16904
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 04:54:24 -0500
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345)
	id CB2DF550D; Wed, 21 Feb 2001 04:53:54 -0500 (EST)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by zmamail04.zma.compaq.com (Postfix) with ESMTP
	id DA57B5409; Wed, 21 Feb 2001 04:53:51 -0500 (EST)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <1VHKKS69>; Wed, 21 Feb 2001 10:53:50 +0100
Message-Id: <C1434589DE6ED411885900508BDF604D014B18E7@vbeexc01.vbe.cpqcorp.net>
From: "Bouarich, Reda" <Reda.Bouarich@compaq.com>
To: "'Andrea Westerinen'" <andreaw@cisco.com>
Cc: "'policy@raleigh.ibm.com'" <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Wed, 21 Feb 2001 10:53:45 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>

Ok, but in a PDP <----> PEP architecture, I understand that the PDP can
retrieve it's policies from the LDAP repositery (this policies are LDAP
standardized classes) and use them to reply to a PEP Request.
What I don't understand, is what the PDP will do with an XML descriptions of
classes since it can construct its Decision based on the LDAP policy-DIT! 
Thanks.
Reda.



-----Original Message-----
From: Andrea Westerinen [mailto:andreaw@cisco.com]
Sent: Tuesday, February 20, 2001 8:16 PM
To: Bouarich, Reda; 'Andrey Mishchenko'
Cc: policy@raleigh.ibm.com
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


No, not the same roles.  An LDAP repository is just that - a repository of
information with defined access mechanisms.  The XML description of classes
is only an encoding.  This is very different.

Andrea

-----Original Message-----
From: policy-owner@raleigh.ibm.com
[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bouarich, Reda
Sent: Tuesday, February 20, 2001 8:59 AM
To: 'Andrey Mishchenko'
Cc: 'policy@raleigh.ibm.com'
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


Hi Andrey,

Regarding to your reply, it seems that the LDAP repositery and the XML
description play the same role?
Is it true?
	regards,

Reda Bouarich
Compaq Telecom Engineering
tel +33 4 92 95 68 03
    +33 6 64 63 00 34

















-----Original Message-----
From: Andrey Mishchenko [mailto:andrew@dcn.nord.nw.ru]
Sent: Friday, February 16, 2001 5:35 PM
To: policy@raleigh.ibm.com
Subject: RE: example of a Policy Core Inofrmation Model to XML mapping


Larry & Reda,

Why may one want to use XML to represent policies
if they are initially stored in the LDAP-based repository?
Is this useful to aggregate all policy-related information,
such as reusable condition variables and actions in the
single object?

Thanks,

Andrey Mishchenko
andrew@dcn.nord.nw.ru

> Reda,
>
> Is your Policy data implemented in an LDAP-accessible repository?
>
> If it is, you could retrieve the information as XML, via a DSML
> facility, such as Castor or JNDI's DSML SPI. Once you have the
> DSML, you might be only one or two XSL transformations away from
> the particular XML format you desire.
>
> Although it is not Policy-specific, this article is a good tutorial
> on the use of DSML and XSL transformation:
>
> http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html
>
>
> "Bouarich, Reda" wrote:
> >
> > Dear All,
> > I am trying to specify a certain policy (if a bandwidth overload occurs
> > between 9am and 6pm then limit the ftp transfert
> > to 100 kb/sec for example) using the DMTF Policy COre Information Model.
> > First I have to map my policy properties on the standardized
> policy classes
> > defined by the DMTF then I have to map this Information model to XML.
> > Can anyone tell me where can I find some kind of concrete examples
> > representing such mapping cause it is the first time I do that
> and it not
> > clear in my mind!!.
> > Thanks a lot.
> > Reda Bouarich.
>
> --
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> # Larry Bartz                           |                              |
> #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> #                                       | Ooo, ooo, oooooo!            |
> #                                       | I've got a gnu attitude!     |
> #  voice (317) 226-7060                 |                              |
> #  FAX   (317) 226-6378                 |                              |
> #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
>


From majordomo@raleigh.ibm.com  Wed Feb 21 11:17:06 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01432
	for <policy-archive@odin.ietf.org>; Wed, 21 Feb 2001 11:17:05 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA17324;
	Wed, 21 Feb 2001 11:09:47 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA23082;
	Wed, 21 Feb 2001 11:09:39 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA32598; Wed, 21 Feb 2001 10:36:21 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA59214; Wed, 21 Feb 2001 10:36:18 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA02272
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 10:36:22 -0500
Received: from dcn.infos.ru (dcn.infos.ru [195.209.228.109])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA31566
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 10:35:54 -0500
Received: from advanced2 (unknown [213.172.17.250])
	by dcn.infos.ru (Postfix) with SMTP
	id 1A03837F1B; Wed, 21 Feb 2001 18:29:47 +0300 (MSK)
From: "Andrey Mishchenko" <andrew@dcn.nord.nw.ru>
To: "Bouarich, Reda" <Reda.Bouarich@compaq.com>,
        "'Andrea Westerinen'" <andreaw@cisco.com>
Cc: <policy@raleigh.ibm.com>
Subject: RE: example of a  Policy Core Inofrmation Model to XML mapping
Date: Wed, 21 Feb 2001 18:35:06 +0300
Message-Id: <DJEEKEDKNOBLNMOFPNAJKECNCBAA.andrew@dcn.nord.nw.ru>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <C1434589DE6ED411885900508BDF604D014B18E7@vbeexc01.vbe.cpqcorp.net>
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Andrey Mishchenko" <andrew@dcn.nord.nw.ru>
Content-Transfer-Encoding: 7bit

Yes, LDAP repository and XML representation play different roles.

But I think XML framework could help only if it was possible to use
XML to retrieve complex objects (for example, policy with associated
reusable filters). But, as I understood, existing technology (DSML
and its implementations) does not offers such functionality.
So, XML can only serve as a wrapper for the LDAP classes,
and one can easy use his own mapping instead of XML without
any disadvantages.

Am I right?

Andrey Mishchenko
andrew@dcn.nord.nw.ru


> -----Original Message-----
> From: policy-owner@raleigh.ibm.com
> [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bouarich, Reda
> Sent: Wednesday, February 21, 2001 12:54 PM
> To: 'Andrea Westerinen'
> Cc: 'policy@raleigh.ibm.com'
> Subject: RE: example of a Policy Core Inofrmation Model to XML mapping
>
>
> Ok, but in a PDP <----> PEP architecture, I understand that the PDP can
> retrieve it's policies from the LDAP repositery (this policies are LDAP
> standardized classes) and use them to reply to a PEP Request.
> What I don't understand, is what the PDP will do with an XML
> descriptions of
> classes since it can construct its Decision based on the LDAP policy-DIT!
> Thanks.
> Reda.
>
>
>
> -----Original Message-----
> From: Andrea Westerinen [mailto:andreaw@cisco.com]
> Sent: Tuesday, February 20, 2001 8:16 PM
> To: Bouarich, Reda; 'Andrey Mishchenko'
> Cc: policy@raleigh.ibm.com
> Subject: RE: example of a Policy Core Inofrmation Model to XML mapping
>
>
> No, not the same roles.  An LDAP repository is just that - a repository of
> information with defined access mechanisms.  The XML description
> of classes
> is only an encoding.  This is very different.
>
> Andrea
>
> -----Original Message-----
> From: policy-owner@raleigh.ibm.com
> [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bouarich, Reda
> Sent: Tuesday, February 20, 2001 8:59 AM
> To: 'Andrey Mishchenko'
> Cc: 'policy@raleigh.ibm.com'
> Subject: RE: example of a Policy Core Inofrmation Model to XML mapping
>
>
> Hi Andrey,
>
> Regarding to your reply, it seems that the LDAP repositery and the XML
> description play the same role?
> Is it true?
> 	regards,
>
> Reda Bouarich
> Compaq Telecom Engineering
> tel +33 4 92 95 68 03
>     +33 6 64 63 00 34
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Andrey Mishchenko [mailto:andrew@dcn.nord.nw.ru]
> Sent: Friday, February 16, 2001 5:35 PM
> To: policy@raleigh.ibm.com
> Subject: RE: example of a Policy Core Inofrmation Model to XML mapping
>
>
> Larry & Reda,
>
> Why may one want to use XML to represent policies
> if they are initially stored in the LDAP-based repository?
> Is this useful to aggregate all policy-related information,
> such as reusable condition variables and actions in the
> single object?
>
> Thanks,
>
> Andrey Mishchenko
> andrew@dcn.nord.nw.ru
>
> > Reda,
> >
> > Is your Policy data implemented in an LDAP-accessible repository?
> >
> > If it is, you could retrieve the information as XML, via a DSML
> > facility, such as Castor or JNDI's DSML SPI. Once you have the
> > DSML, you might be only one or two XSL transformations away from
> > the particular XML format you desire.
> >
> > Although it is not Policy-specific, this article is a good tutorial
> > on the use of DSML and XSL transformation:
> >
> > http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-dsml_p.html
> >
> >
> > "Bouarich, Reda" wrote:
> > >
> > > Dear All,
> > > I am trying to specify a certain policy (if a bandwidth
> overload occurs
> > > between 9am and 6pm then limit the ftp transfert
> > > to 100 kb/sec for example) using the DMTF Policy COre
> Information Model.
> > > First I have to map my policy properties on the standardized
> > policy classes
> > > defined by the DMTF then I have to map this Information model to XML.
> > > Can anyone tell me where can I find some kind of concrete examples
> > > representing such mapping cause it is the first time I do that
> > and it not
> > > clear in my mind!!.
> > > Thanks a lot.
> > > Reda Bouarich.
> >
> > --
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> > # Larry Bartz                           |                              |
> > #  lbartz@parnelli.indy.cr.irs.gov      | Ooo, ooo,                    |
> > #                                       | Ooo, ooo, oooooo!            |
> > #                                       | I've got a gnu attitude!     |
> > #  voice (317) 226-7060                 |                              |
> > #  FAX   (317) 226-6378                 |                              |
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> >
>



From majordomo@raleigh.ibm.com  Wed Feb 21 15:44:19 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09655
	for <policy-archive@odin.ietf.org>; Wed, 21 Feb 2001 15:44:17 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA33958;
	Wed, 21 Feb 2001 15:34:37 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA29640;
	Wed, 21 Feb 2001 15:34:34 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA54222; Wed, 21 Feb 2001 15:03:31 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA59586; Wed, 21 Feb 2001 15:03:28 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA07944
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 15:03:34 -0500
Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA29826
	for <policy@raleigh.ibm.com>; Wed, 21 Feb 2001 15:03:22 -0500
Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21)
	id <FCMGR1JQ>; Wed, 21 Feb 2001 14:53:28 -0500
Message-Id: <A3617F281546D411958C00D0B760121CEBDD43@bor.ellacoya.com>
From: "Weiss, Walter" <wweiss@ellacoya.com>
To: "'John Strassner'" <jstrassn@cisco.com>
Cc: "Joel M. Halpern" <joel@longsys.com>, Robert Moore
	 <remoore@us.ibm.com>,
        policy@raleigh.ibm.com
Subject: RE: Packet Filtering (Re: Preliminary results from PCIMe technica
	 l meeting, 1/24/01 - 1/26/01)
Date: Wed, 21 Feb 2001 14:53:27 -0500
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C09C3F.F57D4838"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Weiss, Walter" <wweiss@ellacoya.com>

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_01C09C3F.F57D4838
Content-Type: text/plain;
	charset="iso-8859-1"

John,

[Snip]

> <js2>
> You're reading too much into what I said. I never used the 
> word "dynamic". 
> I simply said that there are additional constraints that one 
> can impose on 
> an attribute. Restricting the range of a uint8 to 0..63 is 
> one such example.
> </js2>
> 
Perhaps my use of "dynamic" was poor. I was trying to understand whether
this range was a property of the variable itself. If so, how is that
different from a data type. For example, QDDIM specifies a DSCP as having a
valid range between 0 and 63. I am trying to understand the difference
between a variable with the data type of DSCP and what you are proposing. I
am also trying to understand why it is better.

> > >    - constraining the data types of a variable or constant
> >Can you explain what you mean here? Are you refering to the 
> semantics of 
> >variables within an expression? If so, isn't this more a 
> function of the 
> >language semantics for the expression of variables (ie. Perl 
> notion of a 
> >variable is somewhat different from C).
> >
> ><js> See above </js>
> >
> >
> > >    - binding a variable to a value
> >Isn't this also a language semantic?
> >
> ><js>
> >No. For example, in QPIM we may be dealing with an 
> IPAddress, and want to 
> >restrict the values of said variable to just IPv4 addresses 
> that are in 
> >CIDR format.
> >
> ></js>
> ><ww>
> >Does binding refer to an assignment or a dynamic constraint 
> on allowable 
> >values of the variable? In my comment I was assuming the former.
> ></ww>
> 
> <js2>
> Not sure why you're hung up on dynamic entries. I never said 
> the word dynamic.
> </js2>
> 
I am just trying to understand how you are using the term "binding".

[Snip]

> <js2>
> I see no requirement to force people to represent variables or not. 
> Furthermore, if they want to represent variables, then this 
> wg has given 
> them two different means to accomplish the same task. They can use a 
> class-based approach, as in QDDIM, or they can use a finer-grained 
> approach, as in QPIM. We should not dictate which 
> representation people 
> choose, but it is application-specific.
> </js2>

I don't know about the WG giving them two means. I do know that there is a
proposal for variables on the table (that I endorse) and two possible ways
of using variables. My goal is to contrast them to understand the
differences between them and the benefits of each so that we can justify one
as optimal. If both approaches have merits, I would minimally expect the
working group to provide some guidance for usage.

regards,

-Walter

------_=_NextPart_001_01C09C3F.F57D4838
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Packet Filtering (Re: Preliminary results from PCIMe =
technica l meeting, 1/24/01 - 1/26/01)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>John,</FONT>
</P>

<P><FONT SIZE=3D2>[Snip]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &lt;js2&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; You're reading too much into what I said. I =
never used the </FONT>
<BR><FONT SIZE=3D2>&gt; word &quot;dynamic&quot;. </FONT>
<BR><FONT SIZE=3D2>&gt; I simply said that there are additional =
constraints that one </FONT>
<BR><FONT SIZE=3D2>&gt; can impose on </FONT>
<BR><FONT SIZE=3D2>&gt; an attribute. Restricting the range of a uint8 =
to 0..63 is </FONT>
<BR><FONT SIZE=3D2>&gt; one such example.</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;/js2&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>Perhaps my use of &quot;dynamic&quot; was poor. I =
was trying to understand whether this range was a property of the =
variable itself. If so, how is that different from a data type. For =
example, QDDIM specifies a DSCP as having a valid range between 0 and =
63. I am trying to understand the difference between a variable with =
the data type of DSCP and what you are proposing. I am also trying to =
understand why it is better.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; - constraining the =
data types of a variable or constant</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Can you explain what you mean here? Are you =
refering to the </FONT>
<BR><FONT SIZE=3D2>&gt; semantics of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;variables within an expression? If so, =
isn't this more a </FONT>
<BR><FONT SIZE=3D2>&gt; function of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;language semantics for the expression of =
variables (ie. Perl </FONT>
<BR><FONT SIZE=3D2>&gt; notion of a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;variable is somewhat different from =
C).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;js&gt; See above &lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp; - binding a =
variable to a value</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Isn't this also a language semantic?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;No. For example, in QPIM we may be dealing =
with an </FONT>
<BR><FONT SIZE=3D2>&gt; IPAddress, and want to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;restrict the values of said variable to =
just IPv4 addresses </FONT>
<BR><FONT SIZE=3D2>&gt; that are in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;CIDR format.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;/js&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;ww&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Does binding refer to an assignment or a =
dynamic constraint </FONT>
<BR><FONT SIZE=3D2>&gt; on allowable </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;values of the variable? In my comment I was =
assuming the former.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&lt;/ww&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &lt;js2&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Not sure why you're hung up on dynamic entries. =
I never said </FONT>
<BR><FONT SIZE=3D2>&gt; the word dynamic.</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;/js2&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>I am just trying to understand how you are using the =
term &quot;binding&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>[Snip]</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &lt;js2&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I see no requirement to force people to =
represent variables or not. </FONT>
<BR><FONT SIZE=3D2>&gt; Furthermore, if they want to represent =
variables, then this </FONT>
<BR><FONT SIZE=3D2>&gt; wg has given </FONT>
<BR><FONT SIZE=3D2>&gt; them two different means to accomplish the same =
task. They can use a </FONT>
<BR><FONT SIZE=3D2>&gt; class-based approach, as in QDDIM, or they can =
use a finer-grained </FONT>
<BR><FONT SIZE=3D2>&gt; approach, as in QPIM. We should not dictate =
which </FONT>
<BR><FONT SIZE=3D2>&gt; representation people </FONT>
<BR><FONT SIZE=3D2>&gt; choose, but it is application-specific.</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;/js2&gt;</FONT>
</P>

<P><FONT SIZE=3D2>I don't know about the WG giving them two means. I do =
know that there is a proposal for variables on the table (that I =
endorse) and two possible ways of using variables. My goal is to =
contrast them to understand the differences between them and the =
benefits of each so that we can justify one as optimal. If both =
approaches have merits, I would minimally expect the working group to =
provide some guidance for usage.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>-Walter</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C09C3F.F57D4838--


From majordomo@raleigh.ibm.com  Thu Feb 22 17:46:56 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29379
	for <policy-archive@odin.ietf.org>; Thu, 22 Feb 2001 17:46:55 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA27176;
	Thu, 22 Feb 2001 17:34:51 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA37328;
	Thu, 22 Feb 2001 17:34:50 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA65790; Thu, 22 Feb 2001 16:53:04 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA125686; Thu, 22 Feb 2001 16:53:00 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA07982
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 16:53:03 -0500
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA30736
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 16:52:58 -0500
Received: from breeze-41 (breeze-41 [128.96.41.3])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f1MLpDO19000;
	Thu, 22 Feb 2001 16:51:13 -0500 (EST)
Date: Thu, 22 Feb 2001 16:51:13 -0500 (EST)
From: Ravichander Vaidyanathan <vravi@research.telcordia.com>
X-Sender: vravi@breeze
To: te-wg@UU.NET, Jim Boyle <jboyle@level3.net>,
        "'Randy Bush'" <randy@psg.com>
Cc: policy@raleigh.ibm.com
Subject: RE: include MPLS information model as work item
In-Reply-To: <4148FEAAD879D311AC5700A0C969E8905730B7@orsmsx35.jf.intel.com>
Message-Id: <Pine.GSO.4.21.0102221638100.12021-100000@breeze>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ravichander Vaidyanathan <vravi@research.telcordia.com>


	As a vendor providing Operations Support Systems, this is one of
the things that we see repeatedly on our customer's wish lists for control
and management of their networks. Repeated questions have been posed to
this mailing list as to why this work is considered out of scope for this
WG, but thus far have evoked only flippant responses from the powers that
be.

Do the WG chairs/ADs deem it beneath themselves to respond to the
concerns/questions raised on this mailing list in a responsible fashion? 

-Ravi

On Sun, 18 Feb 2001, Hahn, Scott wrote:

> I would like some clarification on this. The charter states that the WG is
> concerned with "measurement and control aspects" of TE. To this end the WG
> has accepted the MIB as a WG item. Given the lively discussion on whether
> the MIB should be read-only vs. read-write, it seems that the MIB is not the
> sole answer to the "measurement and control" aspect. This work might fit
> into the control aspect of TE and as such, would fit into the charter. Why
> is this not the case?
> 
> 
> > -----Original Message-----
> > From: Randy Bush [mailto:randy@psg.com]
> > Sent: Friday, February 16, 2001 6:25 PM
> > To: Ritu Chadha
> > Cc: policy@raleigh.ibm.com; te-wg@UU.NET
> > Subject: Re: include MPLS information model as work item
> > 
> > 
> > bert may choose to speak for policy, but this is not within 
> > the scope of
> > tewg.
> > 
> > randy, with AD hat on
> > 
> > ---
> > 
> > > This topic has been discussed at the Pittsburgh and the San Diego
> > > meetings of the Policy WG. The consensus there was that work
> > > on a policy model for MPLS TE should be done in a workgroup
> > > where the subject matter experts for MPLS TE reside - for the
> > > same reason that SNMP MIBs are developed by the technology
> > > experts rather than in the SNMPv3 WG.
> > > 
> > > I don't believe that there was a lack of interest in MPLS TE
> > > policy at the San Diego tewg meeting. There was a reasonable
> > > show of hands of people who were interested in seeing this
> > > work pursued. 
> > > 
> > > Ritu
> > > 
> > > 
> > > >It currently isn't in our charter, nor does there appear 
> > to be an immenent
> > > >demand for this type of interaction with the network 
> > elements, judging
> > > >from the response in the WG meetings (and the list 
> > traffic).  Perhaps a
> > > >policy WG (or individual work) might be the better place 
> > to show how one
> > > >could use, for instance, RFC2749 type of techniques to 
> > control either TE
> > > >cores, or LSP based L2 VPNs.  But currently we have our hands full
> > > >documenting current uses, practices, and pressing demands.
> > > >
> > > >regards,
> > > >
> > > >Jim
> > > >
> > > >
> > > >
> > > >On Fri, 16 Feb 2001, Marcus Brunner wrote:
> > > >
> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > > >> Hash: SHA1
> > > >> 
> > > >> Dear all,
> > > >> 
> > > >> We ask for inclusion of the MPLS information model and 
> > the corresponding 
> > > >> policy model as a work item in the TE-WG.
> > > >> 
> > > >> The draft in the second version can be found under
> > > >> 
> http://www.ietf.org/internet-drafts/draft-chadha-policy-mpls-te-01.txt
> > >> 
> > >> Marcus
> > >> 
> > >> - --------------------------------------
> > >> Dr. Marcus Brunner
> > >> C&C Research Laboratories
> > >> NEC Europe Ltd.
> > >> 
> > >> E-Mail: brunner@ccrle.nec.de
> > >> WWW:    http://www.ccrle.nec.de/
> > >> personal home page: http://www.tik.ee.ethz.ch/~brunner
> > >> 
> > >> Adenauerplatz 6
> > >> D-69115 Heidelberg
> > >> Germany
> > >> 
> > >> Phone: +49 (0)6221/ 9051129
> > >> Fax:   +49 (0)6221/ 9051155
> > >> 
> > >> -----BEGIN PGP SIGNATURE-----
> > >> Version: Mulberry PGP Plugin v2.0
> > >> Comment: processed by Mulberry PGP Plugin
> > >> 
> > >> iQA/AwUBOo1Lt1hvF0PcuRgqEQJLbgCdFc71Q5pQvWg0Ig7LJWBZzTkGz2MAoOWe
> > >> PYZGnFnsd2OPFz+GqAI3avgc
> > >> =wbMS
> > >> -----END PGP SIGNATURE-----
> > >> 
> > >
> > >
> 
> 






From majordomo@raleigh.ibm.com  Thu Feb 22 17:59:51 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29601
	for <policy-archive@odin.ietf.org>; Thu, 22 Feb 2001 17:59:51 -0500 (EST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA21884;
	Thu, 22 Feb 2001 17:34:56 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA05662;
	Thu, 22 Feb 2001 17:34:49 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA122460; Thu, 22 Feb 2001 16:57:53 -0500
Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA123476; Thu, 22 Feb 2001 16:57:50 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA29600
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 16:57:52 -0500
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA31488
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 16:57:47 -0500
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14W3k7-0002DB-00; Thu, 22 Feb 2001 13:57:43 -0800
From: Randy Bush <randy@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ravichander Vaidyanathan <vravi@research.telcordia.com>
Cc: te-wg@uu.net, policy@raleigh.ibm.com
Subject: RE: include MPLS information model as work item
References: <4148FEAAD879D311AC5700A0C969E8905730B7@orsmsx35.jf.intel.com>
	<Pine.GSO.4.21.0102221638100.12021-100000@breeze>
Message-Id: <E14W3k7-0002DB-00@rip.psg.com>
Date: Thu, 22 Feb 2001 13:57:43 -0800
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Randy Bush <randy@psg.com>
Content-Transfer-Encoding: 7bit

> Do the WG chairs/ADs deem it beneath themselves to respond to the
> concerns/questions raised on this mailing list in a responsible fashion? 

apologies, but what part of

>>> bert may choose to speak for policy, but this is not within the scope of
>>> tewg.

do you find this reference to the working group's charter flippant or
unclear?

randy


From majordomo@raleigh.ibm.com  Thu Feb 22 18:13:50 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29945
	for <policy-archive@odin.ietf.org>; Thu, 22 Feb 2001 18:13:50 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA33740;
	Thu, 22 Feb 2001 18:03:06 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA23170;
	Thu, 22 Feb 2001 18:02:41 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA37190; Thu, 22 Feb 2001 17:26:08 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA119102; Thu, 22 Feb 2001 17:26:05 -0500
Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA34784
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 17:26:06 -0500
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA08270
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 17:26:04 -0500
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14W4BU-0002PA-00; Thu, 22 Feb 2001 14:26:00 -0800
From: Randy Bush <randy@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ravichander Vaidyanathan <vravi@research.telcordia.com>
Cc: te-wg@uu.net, policy@raleigh.ibm.com
Subject: RE: include MPLS information model as work item
References: <E14W3k7-0002DB-00@rip.psg.com>
	<Pine.GSO.4.21.0102221710510.12021-100000@breeze>
Message-Id: <E14W4BU-0002PA-00@rip.psg.com>
Date: Thu, 22 Feb 2001 14:26:00 -0800
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Randy Bush <randy@psg.com>
Content-Transfer-Encoding: 7bit

> Since there is no attempt to explain why the work is out of scope 

the work is out of scope because it is not in the wg's charter which you
will find at <http://ietf.org/html.charters/tewg-charter.html>.  you might
also review the mailing list archive from when the charter was developed
and discussed.  you may also find rfc 2418 helpful in understanding the wg
process in the ietf.

and we discuss these processes and how we might change them in the poisson
working group, not here.

randy


From majordomo@raleigh.ibm.com  Thu Feb 22 18:16:43 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00017
	for <policy-archive@odin.ietf.org>; Thu, 22 Feb 2001 18:16:43 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA46444;
	Thu, 22 Feb 2001 18:00:55 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA33550;
	Thu, 22 Feb 2001 18:00:52 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA114270; Thu, 22 Feb 2001 17:17:08 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA67670; Thu, 22 Feb 2001 17:17:04 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA32418
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 17:17:05 -0500
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA34448
	for <policy@raleigh.ibm.com>; Thu, 22 Feb 2001 17:17:01 -0500
Received: from breeze-41 (breeze-41 [128.96.41.3])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f1MMG1O20599;
	Thu, 22 Feb 2001 17:16:01 -0500 (EST)
Date: Thu, 22 Feb 2001 17:16:00 -0500 (EST)
From: Ravichander Vaidyanathan <vravi@research.telcordia.com>
X-Sender: vravi@breeze
To: Randy Bush <randy@psg.com>
Cc: te-wg@uu.net, policy@raleigh.ibm.com
Subject: RE: include MPLS information model as work item
In-Reply-To: <E14W3k7-0002DB-00@rip.psg.com>
Message-Id: <Pine.GSO.4.21.0102221710510.12021-100000@breeze>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Ravichander Vaidyanathan <vravi@research.telcordia.com>


<snip>
> 
> apologies, but what part of
> 
> >>> bert may choose to speak for policy, but this is not within the scope of
> >>> tewg.
> 
> do you find this reference to the working group's charter flippant or
> unclear?
> 
> randy

Since there is no attempt to explain why the work is out of scope or to
respond to arguments as to why it should be considered within the scope;
Yes, I do find it flippant.

Perhaps you could take a shot at answering concerns raised in this mail:

On Sun, 18 Feb 2001, Hahn, Scott wrote:

> I would like some clarification on this. The charter states that the WG
is
> concerned with "measurement and control aspects" of TE. To this end the
WG
> has accepted the MIB as a WG item. Given the lively discussion on
whether
> the MIB should be read-only vs. read-write, it seems that the MIB is not
the
> sole answer to the "measurement and control" aspect. This work might fit
> into the control aspect of TE and as such, would fit into the
charter. Why
> is this not the case?
> 





From majordomo@raleigh.ibm.com  Fri Feb 23 10:15:53 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04625
	for <policy-archive@odin.ietf.org>; Fri, 23 Feb 2001 10:15:52 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA42728;
	Fri, 23 Feb 2001 09:48:46 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA02238;
	Fri, 23 Feb 2001 09:46:31 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46466; Fri, 23 Feb 2001 09:06:51 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA124026; Fri, 23 Feb 2001 09:06:47 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA34398
	for <policy@raleigh.ibm.com>; Fri, 23 Feb 2001 09:06:48 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1NE6fx65756;
	Fri, 23 Feb 2001 09:06:42 -0500
Importance: Normal
Subject: RE: include MPLS information model as work item
To: Randy Bush <randy@psg.com>
Cc: Ravichander Vaidyanathan <vravi@research.telcordia.com>, te-wg@uu.net,
        policy@raleigh.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OF52036FBB.B48424C2-ON852569FC.004C66AF@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Fri, 23 Feb 2001 09:12:59 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/23/2001 09:06:43 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>


Randy,

Let me try to articulate at least my confusion.  Like a MIB,
a Policy information model for a specific technology like
MPLS stands at the intersection of two different fields.
There's no "right" answer to the question of where the work
to define such a model should be done: it's wholly a matter
of IETF/IESG policy(!).  For MIBs, the policy for some time
was that the work would be done in MIB-specific WGs, most
of which were collected into the Network Management Area.
Then the policy was changed, and the responsibility for
defining MIBs was distributed out into the WGs defining the
various technologies to be managed.

With Policy information models, we seem to be getting
conflicting signals from you and Bert as to what the
IETF/IESG policy is.  (Bert, if I'm misrepresenting your
position, I'm sure you'll speak up.)  I think Bert has said
that we won't do technology-specific Policy information
models in the Policy Framework WG -- they'll instead be the
responsibility of the WGs defining the technologies.  You
seem to be saying exactly the opposite: that this
responsibility does not lie with these WGs, at least not in
this case.

Since this is an IETF policy question, there's no objective
right answer that people can divine.  We need the IESG to
say which way it's going to be.

I don't know that this is something that poisson even needs
to be involved with.  I don't remember if they were involved
with the decision to distribute the responsibility for
defining MIBs to the technology-specific WGs.  Even if they
were, though, this case strikes me as just a second
application of a principle/precedent that was already
established with MIBs.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com



Randy Bush <randy@psg.com>@raleigh.ibm.com on 02/22/2001 05:26:00 PM

Please respond to Randy Bush <randy@psg.com>

Sent by:  policy-owner@raleigh.ibm.com


To:   Ravichander Vaidyanathan <vravi@research.telcordia.com>
cc:   te-wg@uu.net, policy@raleigh.ibm.com
Subject:  RE: include MPLS information model as work item



> Since there is no attempt to explain why the work is out of scope

the work is out of scope because it is not in the wg's charter which you
will find at <http://ietf.org/html.charters/tewg-charter.html>.  you might
also review the mailing list archive from when the charter was developed
and discussed.  you may also find rfc 2418 helpful in understanding the wg
process in the ietf.

and we discuss these processes and how we might change them in the poisson
working group, not here.

randy





From majordomo@raleigh.ibm.com  Fri Feb 23 14:11:58 2001
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16041
	for <policy-archive@odin.ietf.org>; Fri, 23 Feb 2001 14:11:57 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA41282;
	Fri, 23 Feb 2001 14:03:15 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA19882;
	Fri, 23 Feb 2001 14:03:15 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA103730; Fri, 23 Feb 2001 12:22:16 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA97834; Fri, 23 Feb 2001 12:22:13 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA27274
	for <policy@raleigh.ibm.com>; Fri, 23 Feb 2001 12:22:14 -0500
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA21304
	for <policy@raleigh.ibm.com>; Fri, 23 Feb 2001 12:22:11 -0500
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA05238
	for <policy@raleigh.ibm.com>; Fri, 23 Feb 2001 12:22:12 -0500 (EST)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA05205
	for <policy@raleigh.ibm.com>; Fri, 23 Feb 2001 12:22:11 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <FMZ69JZZ>; Fri, 23 Feb 2001 18:07:07 +0100
Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0B5C8FB9@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Robert Moore <remoore@us.ibm.com>
Cc: Ravichander Vaidyanathan <vravi@research.telcordia.com>, te-wg@uu.net,
        Policy Mailing List <policy@raleigh.ibm.com>,
        Randy Bush <randy@psg.com>
Subject: RE: include MPLS information model as work item
Date: Fri, 23 Feb 2001 18:07:04 +0100
Mime-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>

Bob... this is what I ghave been saying and still say, and I believe
Randy and I are in agreement on this:

> >I think we are understanding each other as follows:
> >
> > > - Policy FW WG only does framework and core model/schema
> > > - Policy FW WG also does a technology specific model/schema
> > >   for QoS... This is to prove the concept.
> > > - If other WGs want to also do a Policy model/schema, then fine
> > >   we (IESG) will probably approve.
> > > - If other WGs do not want to do Policy model/schema, then we
> > >   (IESG) will not enforce that now.
> > >
> >So the question on the table is:
> >   - is there indeed a WG that really wants to do the MPLS
> >     information model now.
> >Not if a few people want it but if a lot of people want it
> >(i.e. WG consensus?).
> >
> >Even if a lot of people want it... we need to make sure that the
> >plate of the target WG does not get overloaded.
> 
Now... if we decide that it is the TE-WG, then that means one has
to get that WG to accept that it is a work-item that gets enuf
priority to be chosen over (or in addition to) other work-items that are
already in their charter.

From the email I have seen, it seems that the TE-WG chairs and the
responsible AD are not convinced that they want to ADD this work
item to their charter now.

Bert


> ----------
> From: 	Robert Moore[SMTP:remoore@us.ibm.com]
> Reply To: 	Robert Moore
> Sent: 	Friday, February 23, 2001 3:12 PM
> To: 	Randy Bush
> Cc: 	Ravichander Vaidyanathan; te-wg@uu.net; policy@raleigh.ibm.com
> Subject: 	RE: include MPLS information model as work item
> 
> 
> Randy,
> 
> Let me try to articulate at least my confusion.  Like a MIB,
> a Policy information model for a specific technology like
> MPLS stands at the intersection of two different fields.
> There's no "right" answer to the question of where the work
> to define such a model should be done: it's wholly a matter
> of IETF/IESG policy(!).  For MIBs, the policy for some time
> was that the work would be done in MIB-specific WGs, most
> of which were collected into the Network Management Area.
> Then the policy was changed, and the responsibility for
> defining MIBs was distributed out into the WGs defining the
> various technologies to be managed.
> 
> With Policy information models, we seem to be getting
> conflicting signals from you and Bert as to what the
> IETF/IESG policy is.  (Bert, if I'm misrepresenting your
> position, I'm sure you'll speak up.)  I think Bert has said
> that we won't do technology-specific Policy information
> models in the Policy Framework WG -- they'll instead be the
> responsibility of the WGs defining the technologies.  You
> seem to be saying exactly the opposite: that this
> responsibility does not lie with these WGs, at least not in
> this case.
> 
> Since this is an IETF policy question, there's no objective
> right answer that people can divine.  We need the IESG to
> say which way it's going to be.
> 
> I don't know that this is something that poisson even needs
> to be involved with.  I don't remember if they were involved
> with the decision to distribute the responsibility for
> defining MIBs to the technology-specific WGs.  Even if they
> were, though, this case strikes me as just a second
> application of a principle/precedent that was already
> established with MIBs.
> 
> Regards,
> Bob
> 
> Bob Moore
> IBM Networking Software
> +1-919-254-4436
> remoore@us.ibm.com
> 
> 
> 
> Randy Bush <randy@psg.com>@raleigh.ibm.com on 02/22/2001 05:26:00 PM
> 
> Please respond to Randy Bush <randy@psg.com>
> 
> Sent by:  policy-owner@raleigh.ibm.com
> 
> 
> To:   Ravichander Vaidyanathan <vravi@research.telcordia.com>
> cc:   te-wg@uu.net, policy@raleigh.ibm.com
> Subject:  RE: include MPLS information model as work item
> 
> 
> 
> > Since there is no attempt to explain why the work is out of scope
> 
> the work is out of scope because it is not in the wg's charter which you
> will find at <http://ietf.org/html.charters/tewg-charter.html>.  you might
> also review the mailing list archive from when the charter was developed
> and discussed.  you may also find rfc 2418 helpful in understanding the wg
> process in the ietf.
> 
> and we discuss these processes and how we might change them in the poisson
> working group, not here.
> 
> randy
> 
> 
> 


From majordomo@raleigh.ibm.com  Sat Feb 24 14:55:21 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21858
	for <policy-archive@odin.ietf.org>; Sat, 24 Feb 2001 14:55:20 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28626;
	Sat, 24 Feb 2001 14:52:46 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA28300;
	Sat, 24 Feb 2001 14:52:45 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA50046; Sat, 24 Feb 2001 14:16:28 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA23658; Sat, 24 Feb 2001 14:16:25 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA27418
	for <policy@raleigh.ibm.com>; Sat, 24 Feb 2001 14:16:30 -0500
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA30720
	for <policy@raleigh.ibm.com>; Sat, 24 Feb 2001 14:16:26 -0500
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14Wk8f-0003cq-00; Sat, 24 Feb 2001 11:13:53 -0800
From: Randy Bush <randy@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ed Ellesson <eellesson@lboard.com>
Cc: Bert Wijnen <bwijnen@lucent.com>, Robert Moore <remoore@us.ibm.com>,
        Ravichander Vaidyanathan <vravi@research.telcordia.com>,
        Policy Mailing List <policy@raleigh.ibm.com>
Subject: RE: include MPLS information model as work item
References: <F2F760C942EBD411B98800A0CC733FCF064FD8@longmail2.lboard.com>
Message-Id: <E14Wk8f-0003cq-00@rip.psg.com>
Date: Sat, 24 Feb 2001 11:13:53 -0800
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Randy Bush <randy@psg.com>
Content-Transfer-Encoding: 7bit

[ note tewg list removed.  enough pollution is enough ]

> Randy, or Bert, do you have any objection to the advocates, for mpls policy
> work, making a request for a bof on this subject?

yup.  same one i have had all along.  you have not finished what was on your
FIRST plate.  and there was clear aggrement at the last minneapolis meeting
that you would not expand beyond it until it was complete.

for supposedly object oriented folk, it is interesting that there seems to
be some problem getting the message. :-)

randy


From majordomo@raleigh.ibm.com  Sat Feb 24 15:13:29 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21990
	for <policy-archive@odin.ietf.org>; Sat, 24 Feb 2001 15:13:28 -0500 (EST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA21690;
	Sat, 24 Feb 2001 15:10:54 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA31798;
	Sat, 24 Feb 2001 15:10:54 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA22550; Sat, 24 Feb 2001 14:38:27 -0500
Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA46862; Sat, 24 Feb 2001 14:38:24 -0500
Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA37352
	for <policy@raleigh.ibm.com>; Sat, 24 Feb 2001 14:38:31 -0500
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA27966
	for <policy@raleigh.ibm.com>; Sat, 24 Feb 2001 14:38:25 -0500
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14WkTu-0003lj-00; Sat, 24 Feb 2001 11:35:50 -0800
From: Randy Bush <randy@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ed Ellesson <eellesson@lboard.com>
Cc: Bert Wijnen <bwijnen@lucent.com>, Robert Moore <remoore@us.ibm.com>,
        Ravichander Vaidyanathan <vravi@research.telcordia.com>,
        Policy Mailing List <policy@raleigh.ibm.com>
Subject: RE: include MPLS information model as work item
References: <F2F760C942EBD411B98800A0CC733FCF064FDA@longmail2.lboard.com>
Message-Id: <E14WkTu-0003lj-00@rip.psg.com>
Date: Sat, 24 Feb 2001 11:35:50 -0800
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: Randy Bush <randy@psg.com>
Content-Transfer-Encoding: 7bit

> My impression is that this is a different set of people that want to work
> on the mpls policy stuff, than have been participating for the last two
> years in the policy and qos policy work.

glad to see new blood.  but this is the same old body.

> So, my interpretation of your message, is that you want to see the proof
> of concept (that is, the policy model sub-classed and applied to qos),
> that the policy framework working group promised in our charter a long
> time ago, before you will be convinced that additional policy work is
> worthwhile in a different discipline, regardless of what working group or
> area it is chartered in.

'zactly!

randy


From majordomo@raleigh.ibm.com  Mon Feb 26 12:30:12 2001
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17684
	for <policy-archive@odin.ietf.org>; Mon, 26 Feb 2001 12:30:10 -0500 (EST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA27204;
	Mon, 26 Feb 2001 12:04:09 -0500
Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA35132;
	Mon, 26 Feb 2001 12:04:07 -0500
Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA49416; Mon, 26 Feb 2001 08:25:31 -0500
Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
          id AA34538; Mon, 26 Feb 2001 08:25:26 -0500
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA23858
	for <policy@raleigh.ibm.com>; Mon, 26 Feb 2001 08:25:27 -0500
Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37])
	by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f1QDPOL33020
	for <policy@raleigh.ibm.com>; Mon, 26 Feb 2001 08:25:25 -0500
Importance: Normal
Subject: New PCIM Extensions draft
To: policy@raleigh.ibm.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-Id: <OFD8D63A1B.E80C8149-ON852569FF.0049928F@raleigh.ibm.com>
From: "Robert Moore" <remoore@us.ibm.com>
Date: Mon, 26 Feb 2001 08:31:46 -0500
X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/26/2001 08:25:24 AM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: policy-owner@raleigh.ibm.com
Precedence: bulk
Reply-To: "Robert Moore" <remoore@us.ibm.com>

I've submitted a -00 draft for PCIM Extensions to the
Internet-Drafts repository.  This draft represents the
work item we began in San Diego, to determine which
elements from the derived models like ICIM and QPIM
should be re-cast as extensions to PCIM itself.  I haven't
seen the WG agenda for Minneapolis yet, but I imagine that
discussions of this draft will have a large slot on it.

Until the draft appears on the Internet-Drafts repository,
you can find it at the following URL:

ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-pcim-ext-00.txt


Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
remoore@us.ibm.com