From majordomo@raleigh.ibm.com Wed Aug 1 04:49:28 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 EAA22855 for ; Wed, 1 Aug 2001 04:49:28 -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 EAA11796; Wed, 1 Aug 2001 04:39:21 -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 EAA37616; Wed, 1 Aug 2001 04:45:03 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23400; Wed, 1 Aug 2001 03:47:22 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23304; Wed, 1 Aug 2001 03:47:17 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA26208 for ; Wed, 1 Aug 2001 03:47:15 -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 DAA14386 for ; Wed, 1 Aug 2001 03:41:24 -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 f717kdI18774; Wed, 1 Aug 2001 09:46:40 +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 E3FDFC112; Wed, 1 Aug 2001 09:38:09 +0200 (CEST) Date: Wed, 01 Aug 2001 09:53:04 +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: <227171453.996659584@[192.168.102.79]> In-Reply-To: <5.0.0.25.1.20010728113301.00a37190@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 We will have a discussion on this in London. Marcus > furthermore, PCIMe should then clearly state what a RBE, operating in EaE > mode, and capable of detecting a violation to the consistency of its > execution context, is to behave. ie. > > 1. should it ignore the offending action ? > 2. should it consider the MayIgnoreAction flag? > 3. should it stop processing the whole policy-set? > 4. should there be another flag? > > > cheers; > rsn > -------------------------------------- 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 Aug 1 16:00:16 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 QAA01745 for ; Wed, 1 Aug 2001 16:00: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 PAA25950; Wed, 1 Aug 2001 15:49:43 -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 PAA35538; Wed, 1 Aug 2001 15:55:29 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26052; Wed, 1 Aug 2001 15:03:29 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33980; Wed, 1 Aug 2001 15:03:25 -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 PAA36856 for ; Wed, 1 Aug 2001 15:03:25 -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 f71J3OI78014 for ; Wed, 1 Aug 2001 15:03:24 -0400 Importance: Normal Subject: Review comments on QPIM-04 To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Wed, 1 Aug 2001 15:15:11 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/01/2001 03:03:24 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've taken a fairly close read through most of draft-ietf-policy-qos-info-model-0411.txt, and I have quite a large number of comments. I'm not going to try to categorize these comments, other than flagging a few as "BIG ISSUES". Many are just editorial, but if nobody ever points them out, they'll never get fixed. I'll leave it up to the QPIM authors to decide which of these comments merit discussion in London. 1. Page 5, second paragraph: it sounds odd to call DiffServ a "QoS management paradigm" - why "management"? 2. Page 5, last paragraph: I know about edge and core devices, but what is a "distribution" device in this context? 3. Page 5, last paragraph: I question the last sentence, but maybe I don't understand what "QPIM" means in this context. Part of specifying a QoS policy involves using PolicyRoles to tie rules to resources (in this case, to specific interfaces on specific devices). And this does involve topological information. 4. Page 6, second paragraph: "QPIM enables a common set of conditioning mechanisms to be specified in a standard manner." This sounds like QDDIM to me, not QPIM. The last sentences of the paragraph ("Therefore, a means is required to specify functionality in a standard way that is independent of the capabilities of different vendors' devices. This is the role of QPIM.") make a slightly different point, which sounds better. It does raise, though, the issue of modeling capabilities, which is something the WG may need to face before long. 5. Page 6, last paragraph: I don't know what point this paragraph is making, probably because I don't know what "This" it's referring to. 6. Page 7, last two paragraphs: The term "application-specific" appears twice. From the context, I was expecting "device-specific". Similarly, I was expecting "device" rather than "application". If the point really is about applications, then more needs to be said. 7. Page 8, first paragraph: To limit terminology creep, "structured as a condition clause and an execution clause" should say "structured as a condition clause and an action clause." 8. Page 8, second paragraph: "Rather, it subclassed the SimplePolicyCondition and the SimplePolicyAction classes." Aside from the one case of QoSPolicyRSVPSimpleAction, this is not at all what QPIM does. Instead, it *uses* the two classes SimplePolicyCondition and SimplePolicyAction from PCIMe. 9. Page 10, section 1.2.6: Just so you don't think I found problems with everything in this draft, this is a very good example, clearly presented. 10. Page 12, third paragraph: "a network element may have configuration options and combinations that are not expressible in QPIM." This is a BIG ISSUE, because is goes to the heart of the question of how QPIM and QDDIM are related. Reading this sentence, I immediately ask myself the question: "Then how does the Policy Administrator take advantage of the features of his network elements whose configuration is not expressible in QPIM?" Is "He simply can't" an acceptable answer? Is "By stepping outside the Policy Framework altogether, and tweaking something via the device's CLI" any better? 11. Page 12, last paragraph: This paragraph seems to assert that if two vendors have *different* LDAP schemas that are both derived from QPIM, then because they had QPIM as a common starting point, the two vendors' products will interoperate. I don't think this is right. The two vendors need to use the same LDAP schema in order to get interoperability. This is why the Policy Framework WG produces **LS drafts to go with our **IM drafts, so that there's one common LDAP mapping for each of our information models. 12. Page 13, second paragraph: There's a BIG ISSUE lurking here, but it's at least as much PCIMe's as it is QPIM's. This paragraph is talking about interoperability, while the question that's been raised for PCIMe is compliance. But they're really the same question. The issue is that in a PDP / PEP environment, the PEP never sees the QPIM information model, or even the specific data model (e.g., an LDAP schema) derived from it. Instead, what it sees is a compiled / predigested version of the model, in the form of device-specific configuration commands created from the model by its PDP. Yet a lot of the compliance / interoperability we want to talk about concerns the behavior of the PEP - for example, the behavior of its Rule Engine. So the question we need to answer is "What does it mean to say that a PEP has correctly implemented a Policy model?" 13. Page 15, paragraph after the first ordered list: This places QPIM between steps 1 and 2, but if you read the text for the steps, if looks like the main role of QPIM is in step 3. This isn't quite a BIG ISSUE, but the question of where QPIM fits into the overall Policy picture is one that needs a very crisp answer. 14. Page 16: Typo in the class diagram: QoSPolicyShapeActionAction-->QoSPolicyShapeAction. 15. Page 18, elsewhere: You're still split about 50-50: is the name of the association QoSPolicyExceedAction, or QoSPolicyExcessAction? 16. Page 19, bottom: The page footer appears twice. 17. Page 20, second paragraph: "Using the direction variable defined in the policy core information model ...." Actually, this variable is specified in PCIMe, not PCIM. 18. Page 21, first paragraph: BIG ISSUE. This whole section is important, because it specifies the nature of the QPIM extensions to the rule-nesting design from PCIMe. But I don't think the core premise of the section is correct. (I'll admit that this could be for either of two reasons: either it *isn't* correct, or else there's some key element of the example that I don't understand.) The assertion that seems wrong to me is this: "Are these two representations identical? The minimal bandwidth guarantees provided by the flat representation are identical to those presented in the hierarchical form." Suppose you have a stream with a very high flow rate, consisting exclusively of UDP packets that are neither TFTP nor NFS. It looks to me like the hierarchical version of the rules guarantees 30% of the available bandwidth to this stream, while the flattened version guarantees it only 15%. Am I reading something wrong here? If so, the text needs to be clarified to keep me (and others!) from making this mistake. If not, then I'm not sure what to make of the whole section. Finally, I don't know how to interpret the conclusion, in the last paragraph on page 21. Is this now saying that the hierarchical version and the flat version *do* yield different results? 19. Page 22, last paragraph: Since there's an important difference between the case where rule hierarchy has contextual implications and the case where it does not, there needs to be a clear test for when each applies. The test given is "introduction of a minimal bandwidth action within a sub-rule." But for this to be meaningful, I need to have a test for what counts as "a minimal bandwidth action." And if we have such a test, do you really mean to say that the *only* cases in QPIM for which rule nesting implies context are those that pass that specific test? 20. Page 23, second paragraph from the bottom: "Though obviously necessary, QoS conditions can be formed by setting appropriate attributes of existing policy condition class instances." As was the case with item 8, this simply doesn't describe what you actually did in QPIM. The properties involved are in the policy variables and policy values, not in the policy conditions. For DiffServ, these variables and values were defined in PCIMe. For RSVP, they are, for the most part, defined in QPIM itself. 21. Page 23, last paragraph: in this paragraph DiffServ is incorrectly expanded to Differential Services, rather than Differentiated Services. 22. Page 26, second paragraph: "DSCP and CoS marking are modeled as sub-classes of the simplePolicyAction class." No, they're not. The only subclass of SimplePolicyAction that QPIM defines is QoSPolicyRSVPSimpleAction. 23. Page 26, second paragraph: "Bandwidth allocation, scheduling and congestion control actions are modeled as sub-classes of the QoS PHB action." I find bandwidth allocation and congestion control, but not scheduling. 24. Page 26, section 3.3.1: BIG ISSUE. Next to the indented example near the bottom of page 26 that starts "If (HTTP) ...," I wrote "What about ExecutionStrategy?" This was going to be a request that QPIM specify for cases like this which of the three PCIMe ExecutionStrategy values to use: Do Until Success, Do All, or Do Until Failure. (Presumably the answer in this case would be Do All.) I realized, though, that there's a much bigger problem here. These actions, in their QPIM form, aren't performed at all. Instead, they're compiled by a PDP, and the resulting device-specific configuration commands are sent down to the PEP. As a result, if ExecutionStrategy means anything at all here, it means something different from what it means in a device-level model like IPsec, where the individual actions really are performed. It sounds like this is a case where PCIMe needs to sort through the problem and devise a solution, and then QPIM needs to reflect that solution. We'll be in touch:-) 25. Page 27, first four paragraphs: since it took me a while to understand it, it's worth pointing out, both here and back in the definitions section, the subtlety with the associated traffic profile. Even though policer actions and shaper actions are tied to a traffic profile via the same inherited association QoSPolicyTrfcProfInAdmissionAction, the semantics of the association are different in the two cases: the policer determines whether the profile is being met, while the shaper takes action to make sure that the profile is met. 26. Page 27, last paragraph: I've mentioned this to the QPIM authors before. The word "marker" is already taken, by the DiffServ WG, to refer to a datapath component that sets one header field to one value, unconditionally. QDDIM follows this usage. It's fine if you want to introduce a term to refer to the constellation of instances consisting of a meter followed by three associated marking actions, which mark with three different DSCPs. But you shouldn't use the term "marker" for this purpose. 27. Page 28, first paragraph: you need to explain exactly what the phrase "masked to the IPP subfield" means, in terms of the classes and associations defined in PCIMe. I know how to use the PCIMe elements to limit the range of a variable, but I don't know how to do the same thing for a value. 28. Page 29, first paragraph: it's OK to say that the PolicyVariableInSimpleAction aggregations are omitted for readability, but you should say verbally where they go: to instances (or do they all go to the same instance?) of PolicyDSCPVariable. 29. Page 29, last sentence on the page: This reinforces item 24. What could success or failure possibly mean for one of these PHB actions? 30. Page 31, third paragraph: these are the wrong names for the threshold max/min properties. 31. Page 31, second paragraph from the bottom. Because both types of nesting are allowed, I don't know whether "The default rule uses a 'match all' decision strategy and specifies the Best Effort rules" is correct, or a typo for "... and specifies the Best Effort actions." 32. Page 34, first paragraph: gpsPolicyTRFCProf is the wrong class name. 33. Page 34, last paragraph of section 4.1: what's the relationship between a zero excess burst size and the three action associations? Must one of these associations be omitted? If so, which one? 34. Page 34, first paragraph of section 4.2: "The admission decision can be based on matching individual RSVP requests against a traffic profile or by matching the aggregated sum of all FLOWSPECs (TSPECs) currently admitted." Is this determined by the qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction instance? If so, you should say this explicitly. If not, you still need to answer the question. 35. Page 36, third paragraph: "All variable classes defined in this document extend the PolicyImplicitVariable class, defined in [PCIMe]." I suppose this is true, but wouldn't it be more informative to say that the variable classes in this document derive immediately from QoSPolicyRSVPVariable, which is itself a subclass of PolicyImplicitVariable? 36. Page 38, last several paragraphs: "The property name is used to specify which of the properties in the object is being used as the condition." How does the Policy Administrator say *which* RSVP object to look at? Also, "A simple condition can be constructed...." You actually need to construct it. You say what the value looks like, but what about the variable? 37. Page 38, same paragraph: gpsPolicyAttributeValue is the wrong class name. 38. Page 39, section 7.1 and subsections: the formal specifications of the cardinalities in section 7.1 are correct, but the explanatory text in sections 7.1.1 and 7.1.2 is incorrect. For example, the correct text for section 7.2 would say "The [1..1] cardinality means that an admission action is associated with exactly one traffic profile" (which makes a lot of sense:-). 39. Pages 40 & 41: similar to item 38, the explanatory text for the three Dependent cardinalities is incorrect. The text for the three Antecedent cardinalities is, however, correct in this case. 40. Page 42, section 8.2: This looks like an editing mistake - the RSVP text doesn't belong up here in the abstract superclass. 41. Page 44, section 8.5.1: Something's wrong here. Regardless of how this flag is set, requests are supposed to be admitted. So how can a request ever be denied? 42. Page 45, section 8.6.1: When it says "... the maximum packet size in bytes of this class of packet," I find myself asking "*What* class of packet?" A sentence saying exactly which packets this property applies to would help. (If this were QDDIM, I'd answer "The packets that reach this point on the datapath." But since this isn't QDDIM, I really don't know how to answer the question.) 43. Page 46, section 8.7.1: It would be good to repeat here the information from page 30, that larger values represent higher priorities. 44. Page 47, sections 8.7.5 and 8.7.6: It's probably relevant for other properties as well, but for the delay properties I'm looking for some statement about *which* hop the phrase "this hop" refers to. And is there some implication about the mapping of this part of the QPIM model to QDDIM's ingress and egress interfaces - for example, that these properties only make sense for an egress interface? 45. Page 61: As it's presented the QoSPolicyRSVPSimpleAction doesn't sound to me like a subclass of SimplePolicyAction. PCIMe's SimplePolicyAction has the semantics "Set to ." I don't see how to reconcile this with the statement in section 8.32.1 that "This property is multi-valued, which means that both action types may be executed." If there's a possibility that you'll be doing two things, how can this be thought of as setting a variable to a value? 46. Page 61: "Only variables that are subclasses of the QoSPolicyRSVPVariable are allowed to be associated with this action." You can express this formally, by subclassing the PCIMe aggregation PolicyVariableInSimplePolicyAction. 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 Aug 7 18:09:58 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13222 for ; Tue, 7 Aug 2001 18:09:57 -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 SAA21762; Tue, 7 Aug 2001 18:05:34 -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 SAA04190; Tue, 7 Aug 2001 18:05:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA281180; Tue, 7 Aug 2001 17:10:59 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA379686; Tue, 7 Aug 2001 16:44:42 -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 QAA26786 for ; Tue, 7 Aug 2001 16:43:46 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA21478 for ; Tue, 7 Aug 2001 14:16:15 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f77IFwY18777 for ; Tue, 7 Aug 2001 11:15:58 -0700 (PDT) Received: from ANDREAWW2K ([10.49.255.240]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AGP01667; Tue, 7 Aug 2001 11:15:22 -0700 (PDT) From: "Andrea Westerinen" To: "Policy@Raleigh. Ibm. Com" Subject: Question on the Terminology Draft Date: Tue, 7 Aug 2001 11:17:50 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit I was approached by someone after the 1st policy meeting at the London session and asked about several definitions that "disappeared" in the -04 draft. "Policy server" was one and "PDP" was another. After checking my local copy and the draft on the IETF server, I find that these terms ARE present in both (nothing was lost). Perhaps there is some confusion with the AAAARCH terminology draft - some of whose terms we included and which were then removed from the AAAARCH draft. Andrea From majordomo@raleigh.ibm.com Wed Aug 8 01:35:30 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24597 for ; Wed, 8 Aug 2001 01:35:29 -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 BAA07922; Wed, 8 Aug 2001 01:31:25 -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 BAA38192; Wed, 8 Aug 2001 01:31:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA402868; Wed, 8 Aug 2001 00:32:57 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA169130; Wed, 8 Aug 2001 00:32:53 -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 AAA41688 for ; Wed, 8 Aug 2001 00:32:53 -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 AAA22942 for ; Wed, 8 Aug 2001 00:32:37 -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 f784WJg19016; Tue, 7 Aug 2001 21:32:19 -0700 (PDT) Received: from YSNIRW2K (ysnir-isdn-home.cisco.com [10.49.112.178]) by kaspit.cisco.com (Mirapoint) with SMTP id AKU15857; Wed, 8 Aug 2001 07:32:08 +0300 (GMT-3) From: "Yoram Snir" To: "Bob Moore \(E-mail\)" , Cc: "'Yoram Snir'" , "Yoram Ramberg \(E-mail\)" , "Ron Cohen \(E-mail\)" , "John Strassner \(E-mail\)" Subject: RE: Review comments on QPIM-04 Date: Tue, 7 Aug 2001 18:56:35 +0200 Message-Id: <009201c11fcb$673d3050$0100007f@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Bob, Thanks for the review, great work. Please see my comments with in the text. Yoram Snir -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Robert Moore Sent: Wed, August 01, 2001 9:15 PM To: policy@raleigh.ibm.com Subject: Review comments on QPIM-04 I've taken a fairly close read through most of draft-ietf-policy-qos-info-model-0411.txt, and I have quite a large number of comments. I'm not going to try to categorize these comments, other than flagging a few as "BIG ISSUES". Many are just editorial, but if nobody ever points them out, they'll never get fixed. I'll leave it up to the QPIM authors to decide which of these comments merit discussion in London. 1. Page 5, second paragraph: it sounds odd to call DiffServ a "QoS management paradigm" - why "management"? OK, we will drop management. 2. Page 5, last paragraph: I know about edge and core devices, but what is a "distribution" device in this context? aggregation devices. you could divide the network to edge and core or edge, aggregation and core both works ;-). 3. Page 5, last paragraph: I question the last sentence, but maybe I don't understand what "QPIM" means in this context. Part of specifying a QoS policy involves using PolicyRoles to tie rules to resources (in this case, to specific interfaces on specific devices). And this does involve topological information. QPIM does not add to PCIMe resources tagging, using roles. It only provides and example of usage. We will add text to clarify the issue. 4. Page 6, second paragraph: "QPIM enables a common set of conditioning mechanisms to be specified in a standard manner." This sounds like QDDIM to me, not QPIM. The last sentences of the paragraph ("Therefore, a means is required to specify functionality in a standard way that is independent of the capabilities of different vendors' devices. This is the role of QPIM.") make a slightly different point, which sounds better. It does raise, though, the issue of modeling capabilities, which is something the WG may need to face before long. Editorial, we would replace "mechanism" with "models" 5. Page 6, last paragraph: I don't know what point this paragraph is making, probably because I don't know what "This" it's referring to. this refers to the policy constructs, we will explicitly say so or remove altogether. 6. Page 7, last two paragraphs: The term "application-specific" appears twice. From the context, I was expecting "device-specific". Similarly, I was expecting "device" rather than "application". If the point really is about applications, then more needs to be said. Editorial, in the first paragraph it should say device specific and in the second application specific. Will be fixed. 7. Page 8, first paragraph: To limit terminology creep, "structured as a condition clause and an execution clause" should say "structured as a condition clause and an action clause." OK 8. Page 8, second paragraph: "Rather, it subclassed the SimplePolicyCondition and the SimplePolicyAction classes." Aside from the one case of QoSPolicyRSVPSimpleAction, this is not at all what QPIM does. Instead, it *uses* the two classes SimplePolicyCondition and SimplePolicyAction from PCIMe. You are right, it is the remains of the process of moving pieces from QPIM to PCIM an PCIMe. 9. Page 10, section 1.2.6: Just so you don't think I found problems with everything in this draft, this is a very good example, clearly presented. Thanks ;-) 10. Page 12, third paragraph: "a network element may have configuration options and combinations that are not expressible in QPIM." This is a BIG ISSUE, because is goes to the heart of the question of how QPIM and QDDIM are related. Reading this sentence, I immediately ask myself the question: "Then how does the Policy Administrator take advantage of the features of his network elements whose configuration is not expressible in QPIM?" It should say same high level policy could be translated to different, non standard low level device configurations. The next sentence "Further explanation of this property of QPIM can be found in section 1.2.10 below." points to the following text, I quote: "First, different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy. Second, different PDPs will also have different capabilities and functions, and may choose to translate the high-level QPIM policy differently depending on the functionality of the PDP as well as the capabilities of the PEPs that are being controlled by the PDP. " Is "He simply can't" an acceptable answer? Is "By stepping outside the Policy Framework altogether, and tweaking something via the device's CLI" any better? No, see section 1.2.10 11. Page 12, last paragraph: This paragraph seems to assert that if two vendors have *different* LDAP schemas that are both derived from QPIM, then because they had QPIM as a common starting point, the two vendors' products will interoperate. I don't think this is right. The two vendors need to use the same LDAP schema in order to get interoperability. This is why the Policy Framework WG produces **LS drafts to go with our **IM drafts, so that there's one common LDAP mapping for each of our information models. We would rewrite to say 'THE' LDAP schema. 12. Page 13, second paragraph: There's a BIG ISSUE lurking here, but it's at least as much PCIMe's as it is QPIM's. This paragraph is talking about interoperability, while the question that's been raised for PCIMe is compliance. But they're really the same question. The issue is that in a PDP / PEP environment, the PEP never sees the QPIM information model, or even the specific data model (e.g., an LDAP schema) derived from it. Instead, what it sees is a compiled / predigested version of the model, in the form of device-specific configuration commands created from the model by its PDP. Yet a lot of the compliance / interoperability we want to talk about concerns the behavior of the PEP - for example, the behavior of its Rule Engine. So the question we need to answer is "What does it mean to say that a PEP has correctly implemented a Policy model?" Another way of thinking about this is going top to bottom, I.e., The PDP is the one "knowing" both the policy standard and the specific device it is responsible of. It translates the PCIMe / QPIM policy to this device dependent on the device capabilities. 2 PEPs configured by the same PDP with the same PCIMe/QPIM policy may have different low level configuration. The PEP rule engine is also device specific. The PDP responsibility is to know both the PEP configuration capabilities but ALSO it's rule engine capabilities. Taking ACLs as an example, some PEPs may be limited by the number of ACLs that could be configured and processed. I don't expect the policy editor to know this, but the PDP responsible for this device should know these limitations and over come it. 13. Page 15, paragraph after the first ordered list: This places QPIM between steps 1 and 2, but if you read the text for the steps, if looks like the main role of QPIM is in step 3. This isn't quite a BIG ISSUE, but the question of where QPIM fits into the overall Policy picture is one that needs a very crisp answer. It should say: "QPIM, PCIM and PCIMe are intended to be the bridging mechanism between step #1 and step #3 in the methodology just described, by providing the standard building blocks . 14. Page 16: Typo in the class diagram: QoSPolicyShapeActionAction-->QoSPolicyShapeAction. Thanks 15. Page 18, elsewhere: You're still split about 50-50: is the name of the association QoSPolicyExceedAction, or QoSPolicyExcessAction? Thanks 16. Page 19, bottom: The page footer appears twice. Thanks 17. Page 20, second paragraph: "Using the direction variable defined in the policy core information model ...." Actually, this variable is specified in PCIMe, not PCIM. Thanks 18. Page 21, first paragraph: BIG ISSUE. This whole section is important, because it specifies the nature of the QPIM extensions to the rule-nesting design from PCIMe. But I don't think the core premise of the section is correct. (I'll admit that this could be for either of two reasons: either it *isn't* correct, or else there's some key element of the example that I don't understand.) The assertion that seems wrong to me is this: "Are these two representations identical? The minimal bandwidth guarantees provided by the flat representation are identical to those presented in the hierarchical form." Suppose you have a stream with a very high flow rate, consisting exclusively of UDP packets that are neither TFTP nor NFS. It looks to me like the hierarchical version of the rules guarantees 30% of the available bandwidth to this stream, while the flattened version guarantees it only 15%. Am I reading something wrong here? If so, the text needs to be clarified to keep me (and others!) from making this mistake. If not, then I'm not sure what to make of the whole section. Finally, I don't know how to interpret the conclusion, in the last paragraph on page 21. Is this now saying that the hierarchical version and the flat version *do* yield different results? We would add text to this example and describe how each type of traffic is handled. This example shows that hierarchical version of the rules and flat version are different policies but is missing a piece that explains other effects (not just min BW). 19. Page 22, last paragraph: Since there's an important difference between the case where rule hierarchy has contextual implications and the case where it does not, there needs to be a clear test for when each applies. The test given is "introduction of a minimal bandwidth action within a sub-rule." But for this to be meaningful, I need to have a test for what counts as "a minimal bandwidth action." And if we have such a test, do you really mean to say that the *only* cases in QPIM for which rule nesting implies context are those that pass that specific test We would add text and an example. 20. Page 23, second paragraph from the bottom: "Though obviously necessary, QoS conditions can be formed by setting appropriate attributes of existing policy condition class instances." As was the case with item 8, this simply doesn't describe what you actually did in QPIM. The properties involved are in the policy variables and policy values, not in the policy conditions. For DiffServ, these variables and values were defined in PCIMe. For RSVP, they are, for the most part, defined in QPIM itself. Editorial: This should read as "Though obviously necessary, QoS conditions can be formed by associating the appropriate values and variables class instances, as defined in PCIMe" 21. Page 23, last paragraph: in this paragraph DiffServ is incorrectly expanded to Differential Services, rather than Differentiated Services. Thanks. 22. Page 26, second paragraph: "DSCP and CoS marking are modeled as sub-classes of the simplePolicyAction class." No, they're not. The only subclass of SimplePolicyAction that QPIM defines is QoSPolicyRSVPSimpleAction. You are right and it explained in section 3.3.2 (Controlling Markers). We will fix this. 23. Page 26, second paragraph: "Bandwidth allocation, scheduling and congestion control actions are modeled as sub-classes of the QoS PHB action." I find bandwidth allocation and congestion control, but not scheduling. We would replace "...actions are modeled as sub-classes..." to "...actions are modeled using sub-classes..." 24. Page 26, section 3.3.1: BIG ISSUE. Next to the indented example near the bottom of page 26 that starts "If (HTTP) ...," I wrote "What about ExecutionStrategy?" This was going to be a request that QPIM specify for cases like this which of the three PCIMe ExecutionStrategy values to use: Do Until Success, Do All, or Do Until Failure. (Presumably the answer in this case would be Do All.) I realized, though, that there's a much bigger problem here. These actions, in their QPIM form, aren't performed at all. Instead, they're compiled by a PDP, and the resulting device-specific configuration commands are sent down to the PEP. As a result, if ExecutionStrategy means anything at all here, it means something different from what it means in a device-level model like IPsec, where the individual actions really are performed. you raise here 2 issues: 1. PCIMe execution strategy used in the example should be explicitly defined. It was not done since this issue was still debated in the last 3 weeks, in the context of PCIMe. We would provide an explicit definition here. 2. The more important issue is the second point. PCIMe defines the execution strategy for the device independent (high level) policy and the PDPs are responsible for maintaining this logic in its low level translation. The execution strategy means exactly what it said in the high level policy. The PDPs must maintain the logical structure like it must maintain the condition and actions details. This is one of the capabilities required from a PDP. This is true for PCIM PCIMe and QPIM. Fixing #1 would clarify #2. It sounds like this is a case where PCIMe needs to sort through the problem and devise a solution, and then QPIM needs to reflect that solution. We'll be in touch:-) A general issue that may need additional text, in PCIMe. 25. Page 27, first four paragraphs: since it took me a while to understand it, it's worth pointing out, both here and back in the definitions section, the subtlety with the associated traffic profile. Even though policer actions and shaper actions are tied to a traffic profile via the same inherited association QoSPolicyTrfcProfInAdmissionAction, the semantics of the association are different in the two cases: the policer determines whether the profile is being met, while the shaper takes action to make sure that the profile is met. True. 26. Page 27, last paragraph: I've mentioned this to the QPIM authors before. The word "marker" is already taken, by the DiffServ WG, to refer to a datapath component that sets one header field to one value, unconditionally. QDDIM follows this usage. It's fine if you want to introduce a term to refer to the constellation of instances consisting of a meter followed by three associated marking actions, which mark with three different DSCPs. But you shouldn't use the term "marker" for this purpose. We will look into this and find another name for "markers" 27. Page 28, first paragraph: you need to explain exactly what the phrase "masked to the IPP subfield" means, in terms of the classes and associations defined in PCIMe. I know how to use the PCIMe elements to limit the range of a variable, but I don't know how to do the same thing for a value. meant "compared", usually done by masking, will be fixed. 28. Page 29, first paragraph: it's OK to say that the PolicyVariableInSimpleAction aggregations are omitted for readability, but you should say verbally where they go: to instances (or do they all go to the same instance?) of PolicyDSCPVariable. OK 29. Page 29, last sentence on the page: This reinforces item 24. What could success or failure possibly mean for one of these PHB actions? We will add text to clarify. 30. Page 31, third paragraph: these are the wrong names for the threshold max/min properties. OK 31. Page 31, second paragraph from the bottom. Because both types of nesting are allowed, I don't know whether "The default rule uses a 'match all' decision strategy and specifies the Best Effort rules" is correct, or a typo for "... and specifies the Best Effort actions." we will clarify 32. Page 34, first paragraph: gpsPolicyTRFCProf is the wrong class name. OK 33. Page 34, last paragraph of section 4.1: what's the relationship between a zero excess burst size and the three action associations? Must one of these associations be omitted? If so, which one? Will Clarify or remove the sentence altogether. 34. Page 34, first paragraph of section 4.2: "The admission decision can be based on matching individual RSVP requests against a traffic profile or by matching the aggregated sum of all FLOWSPECs (TSPECs) currently admitted." Is this determined by the qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction instance? We will add clarifying text. If so, you should say this explicitly. If not, you still need to answer the question. It does, we would elaborate. 35. Page 36, third paragraph: "All variable classes defined in this document extend the PolicyImplicitVariable class, defined in [PCIMe]." I suppose this is true, but wouldn't it be more informative to say that the variable classes in this document derive immediately from QoSPolicyRSVPVariable, which is itself a subclass of PolicyImplicitVariable? The important issue is that this is consistent with PCIMe, We would need to look into this and think of making the proposed change. 36. Page 38, last several paragraphs: "The property name is used to specify which of the properties in the object is being used as the condition." How does the Policy Administrator say *which* RSVP object to look at? Also, "A simple condition can be constructed...." You actually need to construct it. You say what the value looks like, but what about the variable? This answers a requirement to specify policy and network behavior dependent on users attributes or other high level charaaccteristics. For example the administrator would like to allocate resources to users of specific divisions in the organization. A user profile includes the division name as an attribute. It makes more sense to have policy defined once per division attribute than per each user's name / id. We would add text and give a usage example. 37. Page 38, same paragraph: gpsPolicyAttributeValue is the wrong class name. True, would be fixed. 38. Page 39, section 7.1 and subsections: the formal specifications of the cardinalities in section 7.1 are correct, but the explanatory text in sections 7.1.1 and 7.1.2 is incorrect. For example, the correct text for section 7.2 would say "The [1..1] cardinality means that an admission action is associated with exactly one traffic profile" (which makes a lot of sense:-). True, would be fixed. 39. Pages 40 & 41: similar to item 38, the explanatory text for the three Dependent cardinalities is incorrect. The text for the three Antecedent cardinalities is, however, correct in this case. True, would be fixed. 40. Page 42, section 8.2: This looks like an editing mistake - the RSVP text doesn't belong up here in the abstract superclass. It should not be an abstract class, typo. 41. Page 44, section 8.5.1: Something's wrong here. Regardless of how this flag is set, requests are supposed to be admitted. So how can a request ever be denied? Typo: "Not" was missing. 42. Page 45, section 8.6.1: When it says "... the maximum packet size in bytes of this class of packet," I find myself asking "*What* class of packet?" A sentence saying exactly which packets this property applies to would help. (If this were QDDIM, I'd answer "The packets that reach this point on the datapath." But since this isn't QDDIM, I really don't know how to answer the question.) It should say "the maximum packet size in bytes of packets in the designated flow." 43. Page 46, section 8.7.1: It would be good to repeat here the information from page 30, that larger values represent higher priorities. OK 44. Page 47, sections 8.7.5 and 8.7.6: It's probably relevant for other properties as well, but for the delay properties I'm looking for some statement about *which* hop the phrase "this hop" refers to. And is there some implication about the mapping of this part of the QPIM model to QDDIM's ingress and egress interfaces - for example, that these properties only make sense for an egress interface? As defined in "diff-serv". 45. Page 61: As it's presented the QoSPolicyRSVPSimpleAction doesn't sound to me like a subclass of SimplePolicyAction. PCIMe's SimplePolicyAction has the semantics "Set to ." I don't see how to reconcile this with the statement in section 8.32.1 that "This property is multi-valued, which means that both action types may be executed." If there's a possibility that you'll be doing two things, how can this be thought of as setting a variable to a value? It was supposed to be single value, i.e., if both actions are required (COPS replace action and COPS set action) then 2 QoSPolicyRSVPSimpleAction instances would be created. 46. Page 61: "Only variables that are subclasses of the QoSPolicyRSVPVariable are allowed to be associated with this action." You can express this formally, by subclassing the PCIMe aggregation PolicyVariableInSimplePolicyAction. OK 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 Wed Aug 8 11:41:26 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 ESMTP id LAA15314 for ; Wed, 8 Aug 2001 11:41:25 -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 LAA27486; Wed, 8 Aug 2001 11:36:07 -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 LAA34470; Wed, 8 Aug 2001 11:35:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA121660; Wed, 8 Aug 2001 09:03:35 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA177458; Wed, 8 Aug 2001 09:03:31 -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 JAA26846 for ; Wed, 8 Aug 2001 09:03:31 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA31500 for ; Wed, 8 Aug 2001 09:03:30 -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 f78D2vg27796 for ; Wed, 8 Aug 2001 06:02:57 -0700 (PDT) Received: from YSNIRW2K (ysnir-isdn-home.cisco.com [10.49.112.178]) by kaspit.cisco.com (Mirapoint) with SMTP id AKU19473; Wed, 8 Aug 2001 16:02:49 +0300 (GMT-3) From: "Yoram Snir" To: "'Policy List' \(E-mail\)" Cc: "Yoram Ramberg \(E-mail\)" , "Ron Cohen \(E-mail\)" , "John Strassner \(E-mail\)" Subject: RE: Review comments on QPIM-04 Date: Wed, 8 Aug 2001 16:02:03 +0200 Message-Id: <00bb01c12012$bdbfd350$0100007f@cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BC_01C12023.8148A350" X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Ms-Tnef-Correlator: 00000000DA6D3F22E06ED2119D4D00A0C9870E0764712602 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C12023.8148A350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, Thanks for the review, great work. Please see my comments with in the text. Yoram Snir -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Robert Moore Sent: Wed, August 01, 2001 9:15 PM To: policy@raleigh.ibm.com Subject: Review comments on QPIM-04 I've taken a fairly close read through most of draft-ietf-policy-qos-info-model-0411.txt, and I have quite a large number of comments. I'm not going to try to categorize these comments, other than flagging a few as "BIG ISSUES". Many are just editorial, but if nobody ever points them out, they'll never get fixed. I'll leave it up to the QPIM authors to decide which of these comments merit discussion in London. 1. Page 5, second paragraph: it sounds odd to call DiffServ a "QoS management paradigm" - why "management"? OK, we will drop management. 2. Page 5, last paragraph: I know about edge and core devices, but what is a "distribution" device in this context? aggregation devices. you could divide the network to edge and core or edge, aggregation and core both works ;-). 3. Page 5, last paragraph: I question the last sentence, but maybe I don't understand what "QPIM" means in this context. Part of specifying a QoS policy involves using PolicyRoles to tie rules to resources (in this case, to specific interfaces on specific devices). And this does involve topological information. QPIM does not add to PCIMe resources tagging, using roles. It only provides and example of usage. We will add text to clarify the issue. 4. Page 6, second paragraph: "QPIM enables a common set of conditioning mechanisms to be specified in a standard manner." This sounds like QDDIM to me, not QPIM. The last sentences of the paragraph ("Therefore, a means is required to specify functionality in a standard way that is independent of the capabilities of different vendors' devices. This is the role of QPIM.") make a slightly different point, which sounds better. It does raise, though, the issue of modeling capabilities, which is something the WG may need to face before long. Editorial, we would replace "mechanism" with "models" 5. Page 6, last paragraph: I don't know what point this paragraph is making, probably because I don't know what "This" it's referring to. this refers to the policy constructs, we will explicitly say so or remove altogether. 6. Page 7, last two paragraphs: The term "application-specific" appears twice. From the context, I was expecting "device-specific". Similarly, I was expecting "device" rather than "application". If the point really is about applications, then more needs to be said. Editorial, in the first paragraph it should say device specific and in the second application specific. Will be fixed. 7. Page 8, first paragraph: To limit terminology creep, "structured as a condition clause and an execution clause" should say "structured as a condition clause and an action clause." OK 8. Page 8, second paragraph: "Rather, it subclassed the SimplePolicyCondition and the SimplePolicyAction classes." Aside from the one case of QoSPolicyRSVPSimpleAction, this is not at all what QPIM does. Instead, it *uses* the two classes SimplePolicyCondition and SimplePolicyAction from PCIMe. You are right, it is the remains of the process of moving pieces from QPIM to PCIM an PCIMe. 9. Page 10, section 1.2.6: Just so you don't think I found problems with everything in this draft, this is a very good example, clearly presented. Thanks ;-) 10. Page 12, third paragraph: "a network element may have configuration options and combinations that are not expressible in QPIM." This is a BIG ISSUE, because is goes to the heart of the question of how QPIM and QDDIM are related. Reading this sentence, I immediately ask myself the question: "Then how does the Policy Administrator take advantage of the features of his network elements whose configuration is not expressible in QPIM?" It should say same high level policy could be translated to different, non standard low level device configurations. The next sentence "Further explanation of this property of QPIM can be found in section 1.2.10 below." points to the following text, I quote: "First, different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy. Second, different PDPs will also have different capabilities and functions, and may choose to translate the high-level QPIM policy differently depending on the functionality of the PDP as well as the capabilities of the PEPs that are being controlled by the PDP. " Is "He simply can't" an acceptable answer? Is "By stepping outside the Policy Framework altogether, and tweaking something via the device's CLI" any better? No, see section 1.2.10 11. Page 12, last paragraph: This paragraph seems to assert that if two vendors have *different* LDAP schemas that are both derived from QPIM, then because they had QPIM as a common starting point, the two vendors' products will interoperate. I don't think this is right. The two vendors need to use the same LDAP schema in order to get interoperability. This is why the Policy Framework WG produces **LS drafts to go with our **IM drafts, so that there's one common LDAP mapping for each of our information models. We would rewrite to say 'THE' LDAP schema. 12. Page 13, second paragraph: There's a BIG ISSUE lurking here, but it's at least as much PCIMe's as it is QPIM's. This paragraph is talking about interoperability, while the question that's been raised for PCIMe is compliance. But they're really the same question. The issue is that in a PDP / PEP environment, the PEP never sees the QPIM information model, or even the specific data model (e.g., an LDAP schema) derived from it. Instead, what it sees is a compiled / predigested version of the model, in the form of device-specific configuration commands created from the model by its PDP. Yet a lot of the compliance / interoperability we want to talk about concerns the behavior of the PEP - for example, the behavior of its Rule Engine. So the question we need to answer is "What does it mean to say that a PEP has correctly implemented a Policy model?" Another way of thinking about this is going top to bottom, I.e., The PDP is the one "knowing" both the policy standard and the specific device it is responsible of. It translates the PCIMe / QPIM policy to this device dependent on the device capabilities. 2 PEPs configured by the same PDP with the same PCIMe/QPIM policy may have different low level configuration. The PEP rule engine is also device specific. The PDP responsibility is to know both the PEP configuration capabilities but ALSO it's rule engine capabilities. Taking ACLs as an example, some PEPs may be limited by the number of ACLs that could be configured and processed. I don't expect the policy editor to know this, but the PDP responsible for this device should know these limitations and over come it. 13. Page 15, paragraph after the first ordered list: This places QPIM between steps 1 and 2, but if you read the text for the steps, if looks like the main role of QPIM is in step 3. This isn't quite a BIG ISSUE, but the question of where QPIM fits into the overall Policy picture is one that needs a very crisp answer. It should say: "QPIM, PCIM and PCIMe are intended to be the bridging mechanism between step #1 and step #3 in the methodology just described, by providing the standard building blocks . 14. Page 16: Typo in the class diagram: QoSPolicyShapeActionAction-->QoSPolicyShapeAction. Thanks 15. Page 18, elsewhere: You're still split about 50-50: is the name of the association QoSPolicyExceedAction, or QoSPolicyExcessAction? Thanks 16. Page 19, bottom: The page footer appears twice. Thanks 17. Page 20, second paragraph: "Using the direction variable defined in the policy core information model ...." Actually, this variable is specified in PCIMe, not PCIM. Thanks 18. Page 21, first paragraph: BIG ISSUE. This whole section is important, because it specifies the nature of the QPIM extensions to the rule-nesting design from PCIMe. But I don't think the core premise of the section is correct. (I'll admit that this could be for either of two reasons: either it *isn't* correct, or else there's some key element of the example that I don't understand.) The assertion that seems wrong to me is this: "Are these two representations identical? The minimal bandwidth guarantees provided by the flat representation are identical to those presented in the hierarchical form." Suppose you have a stream with a very high flow rate, consisting exclusively of UDP packets that are neither TFTP nor NFS. It looks to me like the hierarchical version of the rules guarantees 30% of the available bandwidth to this stream, while the flattened version guarantees it only 15%. Am I reading something wrong here? If so, the text needs to be clarified to keep me (and others!) from making this mistake. If not, then I'm not sure what to make of the whole section. Finally, I don't know how to interpret the conclusion, in the last paragraph on page 21. Is this now saying that the hierarchical version and the flat version *do* yield different results? We would add text to this example and describe how each type of traffic is handled. This example shows that hierarchical version of the rules and flat version are different policies but is missing a piece that explains other effects (not just min BW). 19. Page 22, last paragraph: Since there's an important difference between the case where rule hierarchy has contextual implications and the case where it does not, there needs to be a clear test for when each applies. The test given is "introduction of a minimal bandwidth action within a sub-rule." But for this to be meaningful, I need to have a test for what counts as "a minimal bandwidth action." And if we have such a test, do you really mean to say that the *only* cases in QPIM for which rule nesting implies context are those that pass that specific test We would add text and an example. 20. Page 23, second paragraph from the bottom: "Though obviously necessary, QoS conditions can be formed by setting appropriate attributes of existing policy condition class instances." As was the case with item 8, this simply doesn't describe what you actually did in QPIM. The properties involved are in the policy variables and policy values, not in the policy conditions. For DiffServ, these variables and values were defined in PCIMe. For RSVP, they are, for the most part, defined in QPIM itself. Editorial: This should read as "Though obviously necessary, QoS conditions can be formed by associating the appropriate values and variables class instances, as defined in PCIMe" 21. Page 23, last paragraph: in this paragraph DiffServ is incorrectly expanded to Differential Services, rather than Differentiated Services. Thanks. 22. Page 26, second paragraph: "DSCP and CoS marking are modeled as sub-classes of the simplePolicyAction class." No, they're not. The only subclass of SimplePolicyAction that QPIM defines is QoSPolicyRSVPSimpleAction. You are right and it explained in section 3.3.2 (Controlling Markers). We will fix this. 23. Page 26, second paragraph: "Bandwidth allocation, scheduling and congestion control actions are modeled as sub-classes of the QoS PHB action." I find bandwidth allocation and congestion control, but not scheduling. We would replace "...actions are modeled as sub-classes..." to "...actions are modeled using sub-classes..." 24. Page 26, section 3.3.1: BIG ISSUE. Next to the indented example near the bottom of page 26 that starts "If (HTTP) ...," I wrote "What about ExecutionStrategy?" This was going to be a request that QPIM specify for cases like this which of the three PCIMe ExecutionStrategy values to use: Do Until Success, Do All, or Do Until Failure. (Presumably the answer in this case would be Do All.) I realized, though, that there's a much bigger problem here. These actions, in their QPIM form, aren't performed at all. Instead, they're compiled by a PDP, and the resulting device-specific configuration commands are sent down to the PEP. As a result, if ExecutionStrategy means anything at all here, it means something different from what it means in a device-level model like IPsec, where the individual actions really are performed. you raise here 2 issues: 1. PCIMe execution strategy used in the example should be explicitly defined. It was not done since this issue was still debated in the last 3 weeks, in the context of PCIMe. We would provide an explicit definition here. 2. The more important issue is the second point. PCIMe defines the execution strategy for the device independent (high level) policy and the PDPs are responsible for maintaining this logic in its low level translation. The execution strategy means exactly what it said in the high level policy. The PDPs must maintain the logical structure like it must maintain the condition and actions details. This is one of the capabilities required from a PDP. This is true for PCIM PCIMe and QPIM. Fixing #1 would clarify #2. It sounds like this is a case where PCIMe needs to sort through the problem and devise a solution, and then QPIM needs to reflect that solution. We'll be in touch:-) A general issue that may need additional text, in PCIMe. 25. Page 27, first four paragraphs: since it took me a while to understand it, it's worth pointing out, both here and back in the definitions section, the subtlety with the associated traffic profile. Even though policer actions and shaper actions are tied to a traffic profile via the same inherited association QoSPolicyTrfcProfInAdmissionAction, the semantics of the association are different in the two cases: the policer determines whether the profile is being met, while the shaper takes action to make sure that the profile is met. True. 26. Page 27, last paragraph: I've mentioned this to the QPIM authors before. The word "marker" is already taken, by the DiffServ WG, to refer to a datapath component that sets one header field to one value, unconditionally. QDDIM follows this usage. It's fine if you want to introduce a term to refer to the constellation of instances consisting of a meter followed by three associated marking actions, which mark with three different DSCPs. But you shouldn't use the term "marker" for this purpose. We will look into this and find another name for "markers" 27. Page 28, first paragraph: you need to explain exactly what the phrase "masked to the IPP subfield" means, in terms of the classes and associations defined in PCIMe. I know how to use the PCIMe elements to limit the range of a variable, but I don't know how to do the same thing for a value. meant "compared", usually done by masking, will be fixed. 28. Page 29, first paragraph: it's OK to say that the PolicyVariableInSimpleAction aggregations are omitted for readability, but you should say verbally where they go: to instances (or do they all go to the same instance?) of PolicyDSCPVariable. OK 29. Page 29, last sentence on the page: This reinforces item 24. What could success or failure possibly mean for one of these PHB actions? We will add text to clarify. 30. Page 31, third paragraph: these are the wrong names for the threshold max/min properties. OK 31. Page 31, second paragraph from the bottom. Because both types of nesting are allowed, I don't know whether "The default rule uses a 'match all' decision strategy and specifies the Best Effort rules" is correct, or a typo for "... and specifies the Best Effort actions." we will clarify 32. Page 34, first paragraph: gpsPolicyTRFCProf is the wrong class name. OK 33. Page 34, last paragraph of section 4.1: what's the relationship between a zero excess burst size and the three action associations? Must one of these associations be omitted? If so, which one? Will Clarify or remove the sentence altogether. 34. Page 34, first paragraph of section 4.2: "The admission decision can be based on matching individual RSVP requests against a traffic profile or by matching the aggregated sum of all FLOWSPECs (TSPECs) currently admitted." Is this determined by the qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction instance? We will add clarifying text. If so, you should say this explicitly. If not, you still need to answer the question. It does, we would elaborate. 35. Page 36, third paragraph: "All variable classes defined in this document extend the PolicyImplicitVariable class, defined in [PCIMe]." I suppose this is true, but wouldn't it be more informative to say that the variable classes in this document derive immediately from QoSPolicyRSVPVariable, which is itself a subclass of PolicyImplicitVariable? The important issue is that this is consistent with PCIMe, We would need to look into this and think of making the proposed change. 36. Page 38, last several paragraphs: "The property name is used to specify which of the properties in the object is being used as the condition." How does the Policy Administrator say *which* RSVP object to look at? Also, "A simple condition can be constructed...." You actually need to construct it. You say what the value looks like, but what about the variable? This answers a requirement to specify policy and network behavior dependent on users attributes or other high level charaaccteristics. For example the administrator would like to allocate resources to users of specific divisions in the organization. A user profile includes the division name as an attribute. It makes more sense to have policy defined once per division attribute than per each user's name / id. We would add text and give a usage example. 37. Page 38, same paragraph: gpsPolicyAttributeValue is the wrong class name. True, would be fixed. 38. Page 39, section 7.1 and subsections: the formal specifications of the cardinalities in section 7.1 are correct, but the explanatory text in sections 7.1.1 and 7.1.2 is incorrect. For example, the correct text for section 7.2 would say "The [1..1] cardinality means that an admission action is associated with exactly one traffic profile" (which makes a lot of sense:-). True, would be fixed. 39. Pages 40 & 41: similar to item 38, the explanatory text for the three Dependent cardinalities is incorrect. The text for the three Antecedent cardinalities is, however, correct in this case. True, would be fixed. 40. Page 42, section 8.2: This looks like an editing mistake - the RSVP text doesn't belong up here in the abstract superclass. It should not be an abstract class, typo. 41. Page 44, section 8.5.1: Something's wrong here. Regardless of how this flag is set, requests are supposed to be admitted. So how can a request ever be denied? Typo: "Not" was missing. 42. Page 45, section 8.6.1: When it says "... the maximum packet size in bytes of this class of packet," I find myself asking "*What* class of packet?" A sentence saying exactly which packets this property applies to would help. (If this were QDDIM, I'd answer "The packets that reach this point on the datapath." But since this isn't QDDIM, I really don't know how to answer the question.) It should say "the maximum packet size in bytes of packets in the designated flow." 43. Page 46, section 8.7.1: It would be good to repeat here the information from page 30, that larger values represent higher priorities. OK 44. Page 47, sections 8.7.5 and 8.7.6: It's probably relevant for other properties as well, but for the delay properties I'm looking for some statement about *which* hop the phrase "this hop" refers to. And is there some implication about the mapping of this part of the QPIM model to QDDIM's ingress and egress interfaces - for example, that these properties only make sense for an egress interface? As defined in "diff-serv". 45. Page 61: As it's presented the QoSPolicyRSVPSimpleAction doesn't sound to me like a subclass of SimplePolicyAction. PCIMe's SimplePolicyAction has the semantics "Set to ." I don't see how to reconcile this with the statement in section 8.32.1 that "This property is multi-valued, which means that both action types may be executed." If there's a possibility that you'll be doing two things, how can this be thought of as setting a variable to a value? It was supposed to be single value, i.e., if both actions are required (COPS replace action and COPS set action) then 2 QoSPolicyRSVPSimpleAction instances would be created. 46. Page 61: "Only variables that are subclasses of the QoSPolicyRSVPVariable are allowed to be associated with this action." You can express this formally, by subclassing the PCIMe aggregation PolicyVariableInSimplePolicyAction. OK Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com ------=_NextPart_000_00BC_01C12023.8148A350 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhQOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAAIABAAAgAAAAMA/QAB A5AGANwwAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAbAAAAUmV2aWV3IGNvbW1lbnRzIG9uIFFQSU0tMDQAAAIBcQABAAAAIAAAAAHB HmEDMfILHhYO5E3BnULU/of38JMAOEEwIAA0JDIgAgEdDAEAAAAVAAAAU01UUDpZU05JUkBDSVND Ty5DT00AAAAACwABDgAAAABAAAYOADxZsRIgwQECAQoOAQAAABgAAAAAAAAA2m0/IuBu0hGdTQCg yYcOB8KAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAACFLAAAgSwAAD5jAABMWkZ1C+OgtwMACgBy Y3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0 MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQ8wsJAWQzNhZQC6YK4wqAUEJvYiwc 5VQT4G4OawQgAhAFwHRoZSC1GCB2CJB3HYAJwWEFQJJ3BbBrLhz0UGwfkI0UECAUEB7QbXkgBaC+ bQeAAjAEIAPwHrAgC4CXHqMOsiAVWQWwYW0GAK0DAHIc9CQKLSUiTwUQHmcLgAdABdAHkHNhZxZl JSMc9EYDYTogcIMG8A3geS1vd24EkA5AI4AgkCWQaC5pYmxtLiFhHPRbAMADEHRMbzonjyiZXU8D oELCZRPgbGYgTyxwCACmYgSQBUBNbwWwZRz0NwZgAjAnYFcJgB2AQXXIZ3VzBUAwMR2AAdABLwAg OToxNSBQPk0dpSoAJ3UoTy2UdWJ2agWQLhFSHwMhWAIgIIBRUElNLTA0JA+QCkkndiKRYWsJ8Mwg YR5gC3BybCFBF7D7IMEfgWQeoQNgLqAiIARgaS7Rb2Yc9GQjgAGALWsIkAAwLSolcTcQOUBuFQIQ LQRibDRhMTEunQzQdB2AAHA3gEkgE+DzNdAc9HF1IgAe0DZgC2DiciZQIG51BtASgThwKSFXLiA7 0CcjoG5vqQVAZ28LgGceoG8c9Lx0ciFAKfAhUB+gZT9Q/QUQeiKRHsAgwSFmHYA/IFcewB6SA5Fm C2BnJaFnDxz0NmEH0SCwICJCSQJHO9BTU1VFUyK9PqFNAHAhQArAHtBqLsIfCYAiAEDxB0AdgGJ1 dO8c9AaQPwEG4GQhQB8AEoH/KiALgCHBHrEjoAhgO3Eesfh5J2wDICqwSDImUEcV+GZpeAmAPqNJ 0SCRNdHxIgAgdXBAYh6yNCI2UL1HAGgFsEjBQIAFgWkBAPkc9HdoDeAiID3xQVwhIP8GcQVARlAE 8C7AAJAz8SJB+kwCIGQCICAVHPQ7MD6w8lAmQSA1HYAUEAWgO7FnCrEmQCOAcGgnYEwhc/cIYDuw M9FkN4FAgknQHPS7PrA+sEQGkAagBJB2NlH4IlFvBfADgSZBIZJTw0FGUGdtIiAtH8BoSnlV2CJX eCI/NJpPeksdgHce0APwSdE48G/3TGBXeFHbMlK5C2Au0VPZ/Tvgaz8QRCEG4EcARjE9Ub87oVXY BaEe0AEAHxBjB5D/RtNY0R+hBABW8lCRQDAo0PtHAFEBIlXYYcQiNGLhU4HvDrJae0MhGCBnH6BR AmHFzT6geQhgIVF1bDeARlDvHxABAB6jKrB0H9JAYmBW/2FkBbFgUjuBZvlqhwbgIhGjH9IEIDst KVHbM13f/17qPKAHkGdTHrJvYlXYFBDdZcFuYgBiNADAeSzgO9H9UaEnTDE7sASQLtA7omKS/1kZ NCJYoAeABiJlLVKzLQHJPfFzcE4BZnlDV1Yy7zZgVzIqJCIxdgbwNdAEIPsuwD9yUCozCAAgkE2j Y8B7LXVWMnJokHuEGCBUsXL5YgEgKGUnILFJYUCAd/T/DeBV2EiRBJA2gH2iM/F/Bvdhtm3APrBB O7FlU1GgB5Dvf4p6Iz+hKiFvJaBVkSIx/x5xAMBjwlHbTPOC0j8DN3D5VUNQQzRAHtJ9ZgGQQzNf HYB6lANge3E+oEk4UW79NsFwA2Bo8mLxO7EOwCOQ/wtQavEscC7AJkE+oC5AW6T/h1MOwkByPSF4 MR6jBAEKUOtR249aNFK2NlNPVFF1g/9GMCXAAmCLAiFTAiBxmnejf1OCIgBRAT9yB4AT0QMAc/5t TaNzQX8FCYB/ijZRdEPXCxFXYiqxLligIB4AYuHPVLUqQDYgNBBERE0RP7b/VjIHgB2APxI0Ij6h HgBxNJ9yJzPRTyNTyFXYKCKccf8YIB5xa3J15gQgGCA8oRgh+37IWQlmVNAysFEBB0AiAPt54pf6 d3MgQqJiwwuAAQB/eAB0AQIwVdidpUCgCrBi/wMQlQGddEZQASCfgVfxNdD7UZEUACdnl1XYmVNi 4R6z53thPeKcAyIpV2GaMZgB+ypAKKB0NsBkGafnSHNbYf9Ow1S1LOACQJjxPrFQcYLr/yOABAB+ ok1wN+FJY46EPeL3OqM/cqbaLFXYTrSZcweA92VRP4IewVdEoHMRSfGhJH+AcpZhn7JV2BewP4BR 20X/RlhbgmiDGCALUWTxWbCVpm9YoCHzWbA6snNkBbzPCv41kIlvb3OFX6Nik0hzVdi/ZVNT12LS q+GJA4qhYpLR/yFALOBAoC7Ac1dV2MCIn1H3BABYoCIAJ6CiqAEFED+D/1HbZVPHM3uUneJ5pFOB Y2H/GtBCEluGDsALUA3gIgA2wf8mMMwxQIAFsRggBGA10QdArynwSmFCcVHbNlK2N77l+2mhU8hz J2CccoBBKTVZc/dUMMvCZ0MtfwZYoNIRH5D/TZID8GIAPqEnIh6iYNplw/8dgDvgpFAEIMuhMqE/ cmMw92HT0sipeVMHcAMQCsA2wP/WD9cWWKAjgEJn0W9nQ0Ui/kmdtUiCN0JJ0HnhYvFgAv94mdIo QiEesQOgBGBFwbaS/5YnC3BLMLi/RpQiRUrwdDH/wlpUkbFxaKHMUmS1gQc7ov8iRZE10hl+94xx W8JzQUr09b0qN1K2OB2A5E3QwUCA/ypA2QCNgdExC4CEYlkJBQD1CeBwHYAiypQIcKEhREH/kzKU 5Y3CxII7otu6DsAFkP9js/EFWKDlee9u1PvwrzuRvzZQosPxBZkQWua9KjjrWfuRP0RgUtsz47FU kTJwjdH/BBCXGh6y2OGLsXr0CFD2Fvc7otTL/cpB94f8oT6QmSH+QQ3QaREOch6jD5DU6iCyx6sy V0B69VNWUP3EAPT/SWKqRIcT3ypJ0WKThnc+opfKgTdh+/MqxIFzKiJk/x/QYNkBdP2//sf/nwCq AnP/h8NR2yNgaFBFsiWBrJD78/+qdkkAG4GdiFwQYgGdg80R/T9ycKdgfaICc0zzh5X3MskPTwo5 UrYxMPpDZ1PrOzBdwDYnYEouwsyRaDL7c5S1gmt06DvgHnBU0cOj7yCQlhG780giebWEZSY48/+0 CQYGNmAcIj9BR+CLZp/w/zbw06GKc0FxZcHiTJxwRXC3bXS9L1I2MD6gFyQyBeP/mIGRqjZgaYY6 0FfEcxF06P88AmWSSvAusNshUQJcIOBD/2p1PaClEOA0pIN4meEiPyH/y6F9QQIgkuF2Qqtkqgj1 Sf9Eh0bRxFVi4T9Qe4Wqsaqw/3eF1Mtwhz3xTXBf0Ez0O7G/mmQQozrQQLHiRnVCUjdh/7WkmXJy Rzvg2PCbgEZQQLEn3oF+gGngbXnzYGxm//zsMjaSMZxxl+Ay8obDqqLzAJR06EFk7dFjUnTAaxHz iMCsAmR2RXCIwasT5AP/S9Dvwp2CJ1kGUiY8G6FNcN9PcyhqBlTx6iw/P7y7iiH/86mMMJuAP6ER AEuxhACM8P/J92iSc0E8kQjgNINNs6fm/5uigOGYNoRwX9BG1GS1KEu/CJGcciYgjXFyNpJARkHA /9tDy6JXgTJ2whRcEcdgo0H/qzVVgZfg6fIa433xF7oXcP/p4UqRmRGuE8lnn7AHkF/Az7Wj1dUy MJvQZTp05E3Ax+RSn/Cn2FBFUBuiB5H/J/On2HTkptszgqKWyvK0w38mIBMSp0A3cafJpRFo4nX/ hMFYhUu7HAJCIZ20Vl0rkv9loomxJrBH4Y40RjN05Mn07d1AU/pzVjtEVxajEMyR/1edWO905Fn5 M4K2Uq6wH0DfxJEwYkhGMIQQ8S1G1IZz/8n1dOSn196BpTR6snDlopz/naVjwfASyyCM4qqEWI+d h/9W86STK5KvULMDYG9jwd1A57y/GlWTECJI5nELospB//dAxRDTUfdSqUApMJLSM3Gyc8sgcj91 gtvZQswx/wkA0iBss/LAAiM66NRhRkH/JlIG6s2GZ6TP4AkQw1K1OR8TsJMw1MupBMcBQ0xJl3bS xCKvcj90Sk5v+kL/57NR2SNbGDAkSL8OmVPCaP+CIZYTBun8oTEBpJRuUc/xG6h1J+Qqp9cJ4ExE Qf5Qk7musBIBcbqb0MLgstD/EOBqMFnRFIbglNvYxEaqof/0MMYwM6EzQ5MYSfIxABPD/64j/OyI 2ajgw7FcwMrRZAT/UzHHYE+yN3GpecAGGcMF9/8Q45xFiNnb2LaWjzVGJIqi/4t1HLLMwIzhFQJ8 kdvYlJj/pxNicaoXroBzhTs9eye2EsOTtGZBKipMUx004ZP/MBC746XJQcChkQgyogP6Qf8wcsDx 20J/4gMBkJXb2JrD/xIQeZS3gSaQuvDC4DLBo6K/XGC3gRIQDqO8VM4LV7o4HncQ4GlSSPDMUidU SL5Fk5Cayc4LJKCEJjP6T/+Fo6VU8FAut7fJQcB9k6VCfy9B8sDG1MDxICHkcfAhbf/KwMLgFcPH AIdKEUUtAscA954Wwms9AGzDUgbp3vKdD/9agyyhORr86gbAxwGAsODR/8KwPHCNMszBFcMeginh y8Hf90DUIS4ZssGPcic0M95j/5o3MjaXtTxw/EAxiRGDiHLbdwFuoy9W4iaQbhOwT6D+bkCi4JNW 4pjaHuGCEhGU/wgTqM9noKfSkyH87OaXSkCTPQCpdCAo+DBnLmei/5q6IoV/VI0JcLAIqgfD/BL/ xqIt3L3yulFIwMPwIJHjMP8XQAjxSMAe4QIgTuYQwMg0/5x6U6XtwFAS1z0oPM/7EhD/M5C90d5B SKICd8rUYQFwsPfwMHPi29hZfhDwQe4QMRb/venD4Z0eO4h9YKrQPYEwU++3sbil5/ETEHIqg3JC J/HPUeBOMD76cUUgLae0H5bf4B3ZcjTpR8AQwEVykFxg//gwDaEwdDI33iGZdnfUwkv8IlcH0jqT EVE3MPdBq8XvcdTFXAfQvdJy7wBRwDehvwujQKLv8nqmqYNEfEEGgf9OEt5QbiUZ4XKCuLQGBjAQ XzXDT7AVAoyRfHBtNtEuP/gwZ6BMom6yEYWlsiJr/0nAVEJS8IyTEqN6xEoH/yX/yelLRBFULEFH MAjgLIMywP8IoEVRaOc6xb1zw/BqejBj/x0SS0RsVCbibPVLNnBZCKD+MlbkQWZg3W6yG8MAOBXS /i9qemgCV51KmEFrTITEEv5y5PJNcOVSHoNkcks11Vb/BaVuwfg3ncMRc0jw9DL0uK/EEkFscEuy skGhwE+y5OsGSv4MVH2EQYAgHqFZkv8feH3iVuRoAlDhO0A8QEii+WEFbnUqAJvhMsEQI3HT/0en /1kzghsxWyI0sZX3Q0H/UbH1CjdBPMMKRRzyspRudv/4OqfC+8pFhRkVILESZF31fTOCb8ZSKeH3 siErI1sz/YQmNWegttiiEZviU8JV8v+bpJmRO0CE8FVlO+KF1E6Af6FixyOAsX1gvIF5YnWwMe8z c4ShsrM/CXl58L/y9nR/VJIbNZpRJjJnoF6x2wBv/mt1sDtAPSA4fNeARAFzAe8908ckz5EmBCAg wZ42lkH/MZqrgrCJGagyOkEAY2E7iP/HI0GQQNFTMeXUHmLAIXqm/9DAUcA+oc+howmlwXHTmXL/ sGLGUUeBl2DVUHfFqetFW/2v4CKNtPpSZmP6VHIilJLf/MFIw0gC4CKXYGTlUXKgP8TAmyBQsM+w jZAlqiAj5yaELVO+pCMz0+Z+AqmQ93rAfICsEGqZ8OjhZkA3Qf9Q4M6xYQEWIVyh8WMpg0ol/7Kw ulBso/iwFkAqgR8vg+FqNIQmNq/heRgA0+ZjL4TR+/HcALcRbSPpUW/aU59EU+pQ1WBBUcNJ1Pgt LT5I/8FSdKqX4FCw6yqAg0s1hCY4Z6CpsaCA+7ASr+BZefC/wrsBV2HVUMdmAd8Uvqg1MC1RkK/g //N1bdCakW5Fh+EWQNwA1nz5SsdFeFsg0WBJ1MiDVItfh/BJ1IEbTN+D8DaEJjn/JvHyI6/jtsGE Yajg2xCb4X+nUc6QiWGI0H/BTA9NHTeZhCUyMK7Pr9EiVXog70K1GIDr8taLdrbg3AD4sv+poAUA xjCZoNP1GAXrwTtC96jnvqjK1C5mMXbQEBA0wf/AIo3y6HFiR+hx1VXRYNNbv/pTfPDu8fpDXI9N HThelv4xfPAixK9ZsKeeFp7ALDH/iumCdfDi0LC9MPXRxPGO9v/PMmhl+fOY2cqQNOJSxccjvyjx O5DSMqJDmjIGQi3GMP+7Abf6QWEFEAxAjWP6U84h/79Clg4VEjHK0UEdgB0xUsXHcHnrxc4hKEkn lGHOoP8dgbtc8LQUp6fDARETpIjSv8ABpLDOYCPpgCW1kSouM/+KgOvFyIRO0aUnEWK+qCrQfxhR 7JRSthDVi/SWBb6odec7oSLhHiEuKZfEUzE3APfH44wDz2FtnqHEkfGCZTn3vaPwwjmhQTsxHQSA xNFBfx0w7NAdtNNZ/NLVsN7gP3+X0x2APXDXgNkxHiEBAGT/CtEFILbh7NENAHqKQmISyH5m+bGN /TsSjv+Q0fuTb98dMY4lYyi6QJ2Bcpsgj+Kfvqio4mZgrVpRUlN1p2D/luIoEgND2uAjwMABPaAB A/s21bpAZ7dQk+AEQL6oC/H/ETGvAXfAdrMQwUdwQSDNYfvsMRPRVcPBttBEcEBgFDSPtMk7McYw gDRURlTiAOPu8KigTkZTziIEEipy/woxAbEqv5gr0f4GQvEhkb/xUVAzMCVSt2JAulBig/+RCPuW nCTTSbo4k+I7gdHZv6gItYLIAOwwvqghQCXOIf5BPaAW0ChSPOIRYnmiEAD/izSEYpAgeRAsgFNQ 00kop/82dDv0R3E3UGiiCiPPcPHAnQGxKB4hNUmEUnMhiXD/zbPXgPAT8MN7Ud7QKtDOIv8sgO7x xQNT2X1wPaBqIsIQ/zsxzuOkYrlBUrZvg3BmRLv9UVJGDpBm5BbWCmMcUBlB/0bi3KHRQRnj1rrc IJ/CVbJ/0/VHgW2p/RJa820g2flJ/4yUoyEEUOoBYJR+06XP0iPvoYn2ZZPj0gYq6QCDIMaAf2YA 0QADmAkRHHDkIFd7V//eMRxjsRDnISjy+5aG5h4i/0FmwEOxAKZAAUBGwFKkYADvA7DVsehxPVFk 7JAWoS3j+4bmOQF3FDXHb6b/HiLJy/87IgOYGAMM9rjUYIPa4DSg/3wgNgUXUUeADpDogO8EYuD3 A8B8MOiAKGoiQROQgXjQ7FcpRL8gNzlelibhw2z9RpBTDpDZw4R0EKDn2XE2/wOH/dE9xnoDEHC7 sjG7BkP/mDYDIv8zKOJm0exTj+Edx/+zTOPY98JAoA0BudaiM7SY/mHBmdXAX8Ao0UExf+Ixkf8Q sdBiW7GkwP6ikDPsgw6ANwSQ4RrbkCI7YUJQZHX/fDQT0dlwkI/ZYGFdAQIr8fGcAXViLQZCZmJ4 4htH77TTi7o9YTzwZhxwv2I2cn+0wpu17ImhahShl3AQUyL/8R/yJ2ZjtqoqIT3wm6S7gP/tguxz cbBAoCgGZvH2U4uL+zlxxsgqr2KDIejhLQMyhPvs49FwaOR9dpXm5A0B5kX/OxOWxKFMX7BHoYqE aGTRgP/sgsxvzXsmohCo3MtfAF6WfjNfL52BuAI8U1pEumgiZy3gHGCdcW9iG/AcYHP/oCE2cBZS X8C/UVSBFSIYgf+OvOjQ7UB/tLGQk1MdMFpQ/9kzmxBCUBYgU4E7AVpQQaH/ePCoiixxCtCfJWPH EcVHZd/akYkhJRGZ1lFSQYsR5hH/45icoi9BPaBOkatk5vKvmf/psr/Cz4e70ygS8lFm00fBv5ei MezuJRSSihIB43Zj0P+gAM2ROzNzHGPFYkbV5CN3f5/A2FBqBB+KY4sRxqOhRtVV8UTXYVM3AHa6 A3tw/2Gv1dUlNP0h1yJi6HhkvlnhVfFSU1ZQugNkEDsh/21B9PNAMZbgbaO58HcKYvfXdNMy4WYA ZtzLRRHRVfD9U4BsWpJoIjkUsPL6Aw+v/xC/EcYS31MoYKUUeirlKqT/JAYYTXGw5hErrpnrC7XE 4P8MSN8uRwN8kV+3umgodnDj/8JQfNSgIdpBCmH3Y0Gs15P/MuGa4CjBXFElgZ6BglLZ8X9T2UUZ l4JF5mqvTRALTDKNXpY2DM9gMkRTQ6MQ/QpiQ1SQi7lfwLhjoiJl0/8iAhvx8/EYQ9hRdGRv2eby 3mVUtFV0O0RmYk6zIC3j/ieiMrtQxPmJoq9i89IYRP+gUeAgUf+hTHTTK6SvEduQvxFhUjQtklaE UpTcy1kegv/pUWJgnXAKRK8x2kWXlHB29DMuXpAyfUFN0PAiZvDdFvJNTrHUwdywIAlCrOD75tDR YHh+8wtMXpBLf0yK/kKRFsipZvA4cOdTYvHUQP/q0Pbg2TMNIcIxbPCfMRgS/18kyKl8M+DhTz9Q Tx/HEXH4UEhC+4m/gFkBN/HxyP9lh8isZy/28diCu0NmR9zLzwlHjgE7YNnBIi50EGjv/2n/dBH8 ALwhdA91FcKBsUK3dc09rwwANGJsXkcxQHAIQklHh6BTU1VF/aOhTs4Es0xtYZdkzsbqsP/sUg5X oEEGemKjinWJICFA4+/huaEoSFSjAIlwdvG+LPwAv4CLMZeADvlX2gLnqkD5sApARXi9gBWQrkHG U9Ehl4BneT/8AdJjcxohumhnb7hz6yRzcXH/JWHHAtoRAkMHtB8gN6ESSv8B0qTCzmQC06l2qwDX oL1QvyxTumiFryrWvCHcEGVAcLpEtOBVliFoOZrwYzWy+57AkJFBHwCewChCkKW+4OeqEbuRxPko UMvivFCqUPsAks8icytRQIfo1DOiumi7HfGSRC6DULDEpMB66tD/ugI0oroCxvTgssiptkD9wv5i nWDEoOxgFJGqUbggsnLf7iQGAXclsznC9GnsYAJG/6wAohK/wiEhN6WFEphBumn/O8GxAVO4wjDO 8KzhN/QsQP5ELcHJReR5y/MW8s+ARhL+LQe3wjHRYK6AjzHyi6MB/7xQDSB0pAYA4jLQIP+Ss9P4 UEVQsHLg4aSuwtHw8PeOj/ZT4OJ5sbPIqaDzsmP/wtHcMa1TsXjXV7pot/O70/+vl/OTpeXVwO8A 5tB1A7po+YvDSVBjEf5g6SR+de7w//tA5rJ3JaSqHvNcMqBH3Mv//rOTkAYB6TNe0NkBJWEO5f8+ 0ixizrGFxYJBjzWQQSwD/4zy0rkzsh3x2kLYIUOCK6X9fTBJCkAaIiWyqXDqsBwB/+BEQtK7ghoT BDFgwc+A8bDXSIK+Vd8jM/0hZUpQr3H/43UFJfDhLFRgYzOjFJG20f/PIr/XPIQX5JyjC1vSQnTi /+lS4dfC1PVC7mFjFoghVHD/vGVY5r6EvP8ulqXkfqMhIP9+w9ugreA0wbPjg1AkxaQ1/6PSdKSU weHgJ+Ad4OUxLpL/+rDwEdqBOMRC0WWQ7uAIIPcicTFR1iF30iSM4A1wJ+D/O2D7s1Ujzv+tJgrR Q3OyRv8AcB9TjOPR6CS1ytTTk5tg//hR1SbEdNZCRbG9cfBxk8H/i7Svkt3fF6gKY3c1HZDVYf5s 7hEzM0LRweKMxejQP+D/m7BfgCFTiPKe8PdhDfOjw/9JTeO033HUxCxSvGUKYiBE5kZhABbyIzHH VTtRJAD9imEjS1DKCqGzB5H5saix/4vIQtGI0BqktgONnfdCj/P/OGAhQI0iNKMms5w1CmKl4v8p SojQOGA6IGXUpDUCJe/X/bEQZiRAV1B92geC82V9MX0JQCdgwR3xInL5sP3QOvQtKcoKQYgAqTBg EEWx/8wkB2OogDVyIgIJ4BHjRbGvBULFgyxaygs1PuY3LnH/nvDgoTegk8A/2LvAwhUbQPF92W9v a60xiMGMYX+R/5ASRAH/AVzUr3KaisdgIUD/biDNYxbyhWFw4VRgbiC2A/sKYm2gYwGgJf7JCBvx e8T/KPNqQkOAFADaoRsBfdw4Rv9EIg1wsOCmsRSRpxAkQH0x/kUh8CYLNKMkw5XhdydjUf8zgGPg DpiuKbYiIWBEMojB/wvdI9AkEMykf2DvKVkQRrFfG0E0Ijhlp5pZl1SgYGPHlLDkUKHwQWRtzCHP Uf9SlCjzUTkbYMvh3xBq9hTa/1wjsM+edozgx2CLVEBwJrf/leHjAWAQF4BZIQPZjQBGpf/xUxKT QtE3cHiCsEG10gIz/1EbD5TL0GAADyFXVfVAlQD/i+FqULYjmgSA6SB4sEFJTJvoIUp8Nv45P55J J7QAf60xkzHkEZcpwoOpxZ8jYf+FcDSQYCA3YTehnNUEYpcp3iJOomAQbQDt4mwz8pVBPyNxZgE4 EYzyQkahWFdH76Jh9UNGwhGiZEhw5NFuEf+jAuQRqUFXvO5Q1tHkEo0A//tQleGnEHUwEXPkEjoD nemP7PDhp7hyfTFRRESfQ/1lgXfOkkLR4JA/EaFKA6H/bULgMeRgumLBUDTS9UDNgf9wsGZwwlER wR6RANozGOFl/6IRYMAatORRWRAC8kYxp7r/1HFwEQUy5GCbQR5yOiWjZP+NM64pCzhOp52FjFVO oh8J/woRjSUbV5IwTVHjYXyQhXH/umEiWnMyoAKQQYzkHpEvaP/QJO2wgOmTwMug7lByL2Cy/2WQ AZHNganS7eJjUW1TyEA/BcGV4fvAAcHU4i91cyL1ygs3YmY4/sZjibpi+wN/fbpdRdo8HaONQJai L3Fz72AAVnyM8rWAUGpCNuNtAP+tQ8WEHpFq/+riasPiQxpoz+LiwLP8XqGzIGvBkNcg/w3g1yCQ FNNEvIScYakxj/L/tJoXgFiE17GBoUMjj6DrIP+VEa9hcQJtMMHRoBChWGEa/6lwExfCckaB1OJl Mo/BuZv7rULI4CKjAqjhW4Cr0OCQ/7cBwGLkEqORWWJ4gbXRUAK/99GnENjAuYxUsHsGOVTf4wAw A5IgT0vwI/rQ9d3b01Pcw1ZlZaHwU8uBCbDvF/SuKZvQsRBnXtWo4oCQ3woQFKLU4jBS5PR5nell 8v+6Yr9FcYES0ALQBpC4grX3/3GpiBAdgT1yQWWC8NTxaAS/o6GvAYgQWc9oc0FGP4NQf8aS3MNJ 0nNGuZVxIMoLOf9vGcTDqSKpMMJRJALxQv5h/7vVjkKG87EQzmC5MXxCFJH55lAyNPdCslLNEHkj kcT7oVjU8WaTlNyhF6GVIq1CR9AT5BjyelBIQg62P39PD68B+1H78/Ui6vW5mzPyMP41MzGiYp7w zUEqGPeLAxD0pIp35jBGgVJCPDGf0DVEkr9Bv4Hg0HgvHrH/JYugQeVCgQ+Ps7xCkEbM9l//prHk HLIFsQFwbWBJQv/Y0C1A7lEFswnQ0VBck85x/6WTqOK4cUQSOAlmNWEEH6b+It0ywJEtQKWAuEC/ cKkA074BEFogJ+DQdEdxuHH+J8CBGpAXsr1oBlEYqaZk986Fm6DgoUUbcPByoQJTQPvt0s0QcrEQ I9A4CWkznHH79UBSky6pUA80pR/sCKY1/Q7FLlNbxTBP5Or1jzvKwY2QNDRvrwAwZ3BzFmX8UkZJ 8AxhE6nOlJNEXbP3UjOW34+zM68pKbzkQgil+iCGwDGEudrCcPFkY2Kwe3WkkNBw98Ec8EkA4iEg /noC0Farh+Jl4f8CAFC6wL/TB0jUDsRE74xUYLBN4JJfippea3fZdje/YUm3IW/vRybkEYysUAJD 6wV248sw/yrRzLSDlfngAXD+cB/S/O/fj9GGwa9Ptp+3ojKEuaAz//tQF4WjCB0wijD30QaQ7lDf +zAVeqJj1aJRgWnyUD3g8fnhUlNWWvDlkp0R7fH/dZBBQvMg9dkR/dTxbJPPVX8K43VVK3pbEOZQ QyJQEUZITE9XFlBFQ3xhVP/W43+Q2OCnYTTQ2pAQaRdxf3aCrHDsgTqVHmdERe8pcfpwF2dT4aAP sJYmbKBfwX+KIUWIFZ+AINByF21++CD/jL+Nxer11DP8EeufwuV4vf8sM1dSDnAKEDmDwuFR0TgJ 33izQtBQEVZF8+FzrVAgBP/Q4/cS5Co8AGZBpXBHIS5yP+YCuWEFsKPCjyz+JjM285CvADAiQVAR ZVZdH186/9n0RbDWADTC/BE0wLzji1n9f/NJdAHnEoCGXaT8QF9ItTtoW/yTXdmDWwFwTrL/LCSy kifhZdMD2kuVZDHCEf/F0HYhhdOiYc/wAlNxjxyj/2VWXafyrjtoAsH80mQQW7D/G1BF4VghmgPf O4CGOAlHRP/5gtEgYrBDMlsRs2Sx2vT//2WDjKvMMnPxpmE9IheRN+D/soRyc/mEQnU0wkiD+CNc AP9Pwuyj6VZQT7ziX8BQcFyx/yRh1DaWMvkh4wFyYGTBjyz9KPYzVMGDJXmh0EEqBx1x/6AylZ9s oFJDOtPpdKnUWDIfw3Ox6RBmlnQcdm9ian+ngSDYFrK+Cj/mOQTZgkjfZ2HsAnKZO2jcEm5CsaPB 64ph5kIqBNMq0GQaNWNL/w5CReC/YfBAwxLwMLxhdAL/HHjNlUHc+eF0UG4BqVHZkf5ZVhFGsWvk Vk8lh3DBOaH/JqLmQlhXN7MOI8Fpd4BZkP9l1FhT7RFmAf5qCK1RA+ny/9Ex0LOQ4GLTFvqo0IAC XiP/NkC6QIpgUHDCEHJg0AB8kv5lGUCpoDTCzXGhUS9SdoC/xTBl8ZyiinGf45DQZ5ng/6EgxfCt sXJgsFBGsCXxxTD1nSFjShFGimFX0SOT1HP/HzvslCvS6ZND8ZvAQHA/Uf/eEE6QfEJhpC9RtxKp 5NLgt8/izVIZqHJ1kB9genWjv4bQI1AzotL3X8COsHXaQP+lhDxmUjQcEd3CNBaG0OvR/w/xpXH8 A8ZhYeL9IDJhiVL/MTNfRs1wg9EZQUAINAdyQn+KMEUCihAX4TOicPFSQy/fGpBuHA0njfdRMmf8 0qiQ/7+gVHI3Zcefj9FUNhLyfrP7sD+AEUE0FoCAaaGx/7MPf0vfCWD58+yUba+Ps28GM/dvkbdG TQAxqYRbILdFFJH/knv8c/BgO9Z1pVy0zZGQ8P9fwNZgJCH/g6RpVmp2IadG/2Xj/mLm0oogH7L9 ao5C3ZHvV4ZWwlblYNIyBSN/UKdUf5r5NynvAl1HSeSKUlZYMrf6feYzoDNbmDC30F1auf+J5ArE vgm6gcyHrAQakt34fwxUN2F0UNhKv+LSjabwKH8E1EI0qJAOML/BBplC4zp8LSlIW1N/VI+CZdEw NPgwICa3sLfgI2LTQJ2Af3ujhnIS8pJ7XnlkyL0IRP8y5vEJWtxh6oVCRlF4Sf16/b1iQcaBhiAz I3qetgCU0P+tUBOhBClkVvKmm8CLMHFfz3Jv5Cp00JhFNDJWOFWQ/8tgfFEKsSrjOVSKILsJJBLv nVHcMeEwOYEt/lPQc44z/+wC+2LCEA4wnVAGqPjwNTD/lnD8MtRkV3DSgRpx+OGWcP/xo+sO5dXn 0cIC3cKNVvZl36iyKUBSX4VgmDY0yWGGSPvuYHUxU5rQn9HPgUeRUUT7jIKa+VLU8VrgpsGcs4Ax /Q7EZrYgz6HRMLdAXcHQxv++CUKy+PTpg5Ai2Rbk4JTA/5ejzaLR2dDFu5ATocICMyHfGYDCoAi7 qMHwEU404KbwPndA8dwzUXCErK8WNDX3hioScHUxV/5w4OETYeZQ79EwqUNYKw/weAHA1gGuUP5j QlC8Vd2R07A0c8AyC4J7Bj+mFCygQPjA8kGEAG3LpEAFk3MQEyIqo6DeUPcgoKfvpgU/2ZEjUcZ2 5kH/z4JshQTEqG7Z1d0HFGD1cac65OyU/nBscGKZKMLhx9nz6gFGUFFERPhAtgD8SSdJkenkzCOv tf192AD7RxKwNG8OgTNiP9PeUBRg9d5QaNmCQvpaoNFE0fllv/tis/a2sicy8yD7Ymvn0P53BqiX s+m/HNPXsI6PZsj//mKln6atr7YZxT+RNVB3wd/awZhAgEDZgYS7M4WW7vHfhkhW0XVA69GDx2cO QCes/9gA3NAqEYyD/mL8V81xAoP77aDusjDvAmla4zHusOog/yqD0TDJQTpxMCI1Qj6TMpFTW0Pk G09LhLs0hZY3t1Y3QQDHAjVKM8cCNsdS+0eQFQti9hFosNgANZEKEv9lIjTkGRlA8exg4rAEKV3y /3iG2kATMDDxGSi0YMFADjL/iRJY8VvJlNHo4d5R82MsxP8gRo+AjGAY03kQgmEGqMCR7wqx3RGg QMlAZi9CDqApQf9+YPKBHcNCspTRUDn1Y8qk/yzID/D5AIkSp2btoW/8/mL8UVD4QPvx2KH9ArPz R5F/iRE6cQ8EluDm8lA5rWFy/mZsoB2xidBlImOJKhT5Mf8ZGGz6AlFCMkLVZSJGkeeEa+h4CKtB 8gsiAgBuAC29M7F2pHDE7JRwEpQ2dTF/71EFYEeRzcUN0lg6AttT/SODQVZ0itY6kQ8y/SDg+v+H xAXqlLAjg071YGMpQQyz/9Oa+S9rMCoAHcRWUA/wMDBbNtGq0FMx0AaoPC1mPvcwUv6xUAE+JmKp kLvkVlD/RlC9JJzaC7E8ADezs3IMct/889unYBgGqFWQM6HwVvBf6iMUwbBaCrHBIGxWgC39KoNk gKlu9WjnXeA04WrW/5GBQmIpwSTKSgB8AEYxm9B/ABJaY8lAR5FK0BDRQFBi126QaJJpPHk6oCfX EJ4z/7eBmHAx4YHyUXCABCRzggP/JMrqIDqgNWBv8kDimMGJA/9K0C1mOaMqdC3rx3ITEpqMz6DS I7Eqg5jwaS6CgBgBf6dwCcNq1UEBQrEvpYQAKPxDT/VAyTLYwETRauVKQv8ac5jBatW+0C0SazBh sPSPv/WXwiCJcUTB1tGD1mO2wc8mAoS7o1Dx+CJP7CItZv8JVZo0+ITrW1pkHYtP4BQF910iOeLW 8GTkiZsUa52CA/tq5AACWTqgEQJ22+bzl/T/WQPsMF3RaLD4Zg/TWDr6c31KwGfm4T2QBIwdtCZ2 Sf5u+48+IM/PYtGW1IAA8+TOQtRwTDo04SBN2gDJQH3u9WTVIX6heVHD8kozVK18AGi8UNnwZ2zl QbEi3+IFMXBGQE5RVoNNSDCXIdugYEKxREVVjuVC5ZCcEHZmEBBdIkdRUJqA8+QrADEtOTE5LTI1 5DQtk5AzNvPkyUDlsJVCoUBK8C5GEG0ugVAKbUw6fUDQAAAAHgBCEAEAAAABAAAAAAAAAAMACVkB AAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAAnagEAHgAlgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAMAJoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA CwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCACCAGAAAAAADAAAAAAAAARgAAAAAR hQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBBgAggBgAAAAAAwAAAAAAA AEYAAAAANoUAAAEAAAABAAAAAAAAAB4AQoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAA AAAAAAAeAEOACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwDVgAggBgAAAAAA wAAAAAAAAEYAAAAABoUAAAAAAAACAfgPAQAAABAAAADabT8i4G7SEZ1NAKDJhw4HAgH6DwEAAAAQ AAAA2m0/IuBu0hGdTQCgyYcOBwIB+w8BAAAAdAAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3Bz dC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAARDpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1x5c25p clxNeSBEb2N1bWVudHNcZW1haWxcb3V0bG9vay5wc3QAAwD+DwUAAAADAA00/TcAAAIBfwABAAAA MQAAADAwMDAwMDAwREE2RDNGMjJFMDZFRDIxMTlENEQwMEEwQzk4NzBFMDc2NDcxMjYwMgAAAAAD AAYQO/v2iwMABxDBQgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEJPQixUSEFOS1NGT1JU SEVSRVZJRVcsR1JFQVRXT1JLUExFQVNFU0VFTVlDT01NRU5UU1dJVEhJTlRIRVRFWFRZT1JBTVNO SVItLS0tLU9SSUdJTkFMTUVTU0FHRS0tLS0tRlIAAAAA0go= ------=_NextPart_000_00BC_01C12023.8148A350-- From majordomo@raleigh.ibm.com Fri Aug 10 08:33:57 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 ESMTP id IAA04340 for ; Fri, 10 Aug 2001 08:33:56 -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 IAA21546; Fri, 10 Aug 2001 08:29:46 -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 IAA41262; Fri, 10 Aug 2001 08:29:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA95696; Fri, 10 Aug 2001 07:38:01 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA314050; Fri, 10 Aug 2001 07:37:57 -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 HAA32856 for ; Fri, 10 Aug 2001 07:37:58 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA22512 for ; Fri, 10 Aug 2001 06:51:11 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Aug 2001 06:50:11 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: FW: Summary of Policy Meeting Sessions in London Date: Fri, 10 Aug 2001 06:50:10 -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 Here is the summary of the two working groups sessions held this week in London. This is what I forwarded to Bert for the summary due our AD at the end of the IETF. I will send draft minutes next week. Cheers, Ed > -----Original Message----- > From: Ed Ellesson > Sent: Thursday, August 09, 2001 12:18 PM > To: 'Joel M. Halpern'; 'Wijnen, Bert (Bert)' > Subject: Summary of Policy Meeting Sessions in London > > 1. PolTerm: Multi-wg lc issues resolved, draft updated. Will submit to > IESG > > 2. PCIMe: > Issues requiring changes to current draft: > Class Name: change IPHeaderFilter, to read > IPHeadersFilter > How to specify "don't care" for a filter: Bob Moore > to review and submit appropriate text > Criticality of conditions and actions: Add warning. > Text to be supplied by Joel working with Bob. No additions to the model. > Compliance language: Add text: "musts" and "mays" > come in at the level of the submodel and not at level of PCIMe model. > Issues resolved with no changes to current draft: > Encoding of filter properties: IpVersion, > Addresses, Ports > "Do until failure " ExecutionStrategy > Complete list of fields to filter on > Policy explict variables > Compounding Policy Conditions > Evaluation and Execution Order > > 3. QDDIM: > Modeling of Droppers: Walter/Bob to write text > Preamble Marking: New text to broaden the scope (John S./Walter) > No changes: Modeling of queues/scheduler, and the four examples > > 4. PCLS: Status of IESG last call reviewer comments: > DMTF Normative References: Lee will provide updated policy from > DMTF in couple of weeks. John will provide to reviewers to determine if > norm ref is now ok. > X.500 considerations: John will update, incl. various fixes, moving > content of structure rules and removing the rules. > IESG LDAP reviewers: John will update, incl. various fixes to > improve readability, content rule treatment, clarifications, moving text > around, fixing typos, formatting, etc. > Another review cycle by LDAP/X.500 reviewers required > > 5. QPIM: > General agreement on the content, altho more review required > Offline discussion on the abstraction concept > One more version, and then to last call (6wks?) > > 6. Next IETF: > One session in Salt Lake, then queisce wg. > Schemas need to be closed before following ietf. > > > From majordomo@raleigh.ibm.com Fri Aug 17 16:09:55 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14462 for ; Fri, 17 Aug 2001 16:09:55 -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 QAA33568; Fri, 17 Aug 2001 16:05:29 -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 QAA24752; Fri, 17 Aug 2001 16:05:18 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA70088; Fri, 17 Aug 2001 15:10:55 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB79284; Fri, 17 Aug 2001 15:10:48 -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 PAA35070 for ; Fri, 17 Aug 2001 15:10:47 -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 f7HJAkO141982 for ; Fri, 17 Aug 2001 15:10:46 -0400 Importance: Normal Subject: pre-London QDDIM now available on Internet-Drafts To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Fri, 17 Aug 2001 15:23:07 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/17/2001 03:10:46 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Just so nobody gets confused ... after the blackout, I sent in the pre-London version of QDDIM to the Internet-Drafts repository. It's now available there as http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-05.txt The date they show for the document is August 15, which must represent when they actually added it to their page. But this is the same July 20 draft that I made available on the AIW site, and that we discussed in London. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com From policy-admin@ietf.org Wed Aug 29 18:47:44 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 ESMTP id SAA12852 for ; Wed, 29 Aug 2001 18:47:44 -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 SAA27385; Wed, 29 Aug 2001 18:30:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27336 for ; Wed, 29 Aug 2001 18:30:33 -0400 (EDT) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12354 for ; Wed, 29 Aug 2001 18:29:12 -0400 (EDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Aug 2001 18:29:43 -0400 Message-ID: From: Ed Ellesson To: "'policy@ietf.org'" Date: Wed, 29 Aug 2001 18:29:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] New Mail List Server for Policy Framework WG Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Dear Policy Framework WG Mail List Subscribers, We have had alot of problems with the old mail list server for this working group, so we have moved the policy mailing list to a server operated by the IETF. You should shortly receive, if you have not already, a notice of subscription to the new mailing list. Please direct all future mail intended for the policy framework working group's mailing list distribution, to the new address: policy@ietf.org As usual, you can direct administrative requests in the usual format, to policy-request@ietf.org The email mentioned above will include instructions on how to unsubscribe, and how to manage your access to the list. Sorry for the inconvenience. This new list server should give us alot better service. Thanks, Ed Ellesson Co-chair, Policy Framework WG PS: I sent a note similar to this one, to the old list (policy@raleigh.ibm.com) before I subscribed y'all to this new server, but I did not see it show up yet, so it may be that the old server finally decided not to forward email anymore. Please use the new one. If you received this note you are subscribed to the new one. _______________________________________________ Policy mailing list Policy@ietf.org http://www1.ietf.org/mailman/listinfo/policy From policy-admin@ietf.org Thu Aug 30 09:19:11 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 ESMTP id JAA15645 for ; Thu, 30 Aug 2001 09:19:11 -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 HAA24669; Thu, 30 Aug 2001 07:46:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24639 for ; Thu, 30 Aug 2001 07:46:53 -0400 (EDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10883 for ; Thu, 30 Aug 2001 07:45:30 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id HAA38384 for ; Thu, 30 Aug 2001 07:46:20 -0400 Received: from lmr (dyn9-37-49-10.raleigh.ibm.com [9.37.49.10]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with SMTP id HAA28524 for ; Thu, 30 Aug 2001 07:46:19 -0400 Message-ID: <001901c13149$61731470$0a312509@lmr> From: "Lee Rafalow" To: Date: Thu, 30 Aug 2001 07:46:16 -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 Content-Transfer-Encoding: 7bit Subject: [Policy] Fw: PCIMe Last Call comments Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Lee Rafalow" To: Sent: Tuesday, August 28, 2001 2:26 PM Subject: PCIMe Last Call comments > In doing a final review of the PCIMe classes, we've found a couple of small > problems that need to be addressed. > > The PolicyRoleCollectionInSystem association class is derived from > PolicyInSystem. Since RoleCollection is not derived from Policy, this is > incorrect. The superclass for PolicyRoleCollectionInSystem should be > changed to be derived from Dependency. > > In changing PolicyRepository to ReusablePolicyContainer, we also had agreed > to remove PolicyRepositoryInPolicyRepository in favor of a more general > aggregation of AdminDomain instances with a ContainedDomain aggregation. We > apparently have an intermediate result documented in PCIMe. So, > PolicyContainerInPolicyContainer should be replaced by ContainedDomain. > > These are both small changes and, in my opinion, should not interfere with > last call. > > 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 > Personal email: lrafalow@mindspring.com > _______________________________________________ Policy mailing list Policy@ietf.org http://www1.ietf.org/mailman/listinfo/policy From policy-admin@ietf.org Fri Aug 31 12:26:26 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 ESMTP id MAA09538 for ; Fri, 31 Aug 2001 12:26:26 -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 LAA15817; Fri, 31 Aug 2001 11:58:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15788 for ; Fri, 31 Aug 2001 11:58:03 -0400 (EDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08472 for ; Fri, 31 Aug 2001 11:56:36 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id LAA34688 for ; Fri, 31 Aug 2001 11:57:06 -0400 Received: from lmr (dyn9-37-49-10.raleigh.ibm.com [9.37.49.10]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with SMTP id LAA25080 for ; Fri, 31 Aug 2001 11:57:27 -0400 Message-ID: <000901c13235$a0cefde0$0a312509@lmr> From: "Lee Rafalow" To: Date: Fri, 31 Aug 2001 11:57:24 -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 Content-Transfer-Encoding: 7bit Subject: [Policy] PCIMe Last Call comments Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit I can no longer find the PolicyRoleCollectionInSystem derivation error I thought I saw. So, as Emily Litella might have said...never mind. The other correction still needs to be made. 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 Personal email: lrafalow@mindspring.com _______________________________________________ Policy mailing list Policy@ietf.org http://www1.ietf.org/mailman/listinfo/policy