From majordomo@raleigh.ibm.com Wed Nov 1 04:24:03 2000 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 EAA25278 for ; Wed, 1 Nov 2000 04:24:03 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA31628; Wed, 1 Nov 2000 03:54:36 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id DAA20600; Wed, 1 Nov 2000 03:54:34 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37766; Wed, 1 Nov 2000 02:42:25 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25198; Wed, 1 Nov 2000 02:42:02 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA19344 for ; Wed, 1 Nov 2000 02:42:03 -0500 Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id CAA09112 for ; Wed, 1 Nov 2000 02:42:01 -0500 Received: by border.alcanet.com.au id <115222>; Wed, 1 Nov 2000 19:40:48 +1100 Date: Wed, 01 Nov 2000 18:38:46 +1100 From: Navin Keswani Subject: Requirements Analysis for PCIM To: policy@raleigh.ibm.com Message-Id: <00Nov1.194048est.115222@border.alcanet.com.au> Mime-Version: 1.0 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Navin Keswani Content-Transfer-Encoding: 7bit Hi, I was wondering whether there are any documents out there on any requirements analysis/ use-case analysis/ functional specification that may have gone into the development of the Policy Core Information Model. Thanks, Navin Keswani Network Applications Division Alcatel Australia Tel: +61.2.9690.5416 Fax: +61.2.9690.5247 E-mail: navin.keswani@alcatel.com.au From majordomo@raleigh.ibm.com Wed Nov 1 16:54:55 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10212 for ; Wed, 1 Nov 2000 16:54:54 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA26766; Wed, 1 Nov 2000 16:44:08 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA23288; Wed, 1 Nov 2000 16:43:58 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55922; Wed, 1 Nov 2000 16:11:15 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46186; Wed, 1 Nov 2000 16:11:11 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA25416 for ; Wed, 1 Nov 2000 16:11:12 -0500 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA22378 for ; Wed, 1 Nov 2000 16:11:08 -0500 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA01019 for ; Wed, 1 Nov 2000 13:10:37 -0800 (PST) Message-Id: <4.1.20001101160621.00c1b550@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Nov 2000 16:09:47 -0500 To: "Policy Framework WG" From: John Schnizlein Subject: Re: Nov. 1 Telephone Conference of the AAAarch RG In-Reply-To: <3A007B60.4F1AE3F8@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 03:21 PM 11/01/2000 -0500, on AAAarch Research Group : >... > 6. Policy > > Guus Sliepen asked whether policies needed to be transmitted in > AAA messages. John Vollbrecht replied that they should. What is the nature of the coordination between Policy Framework and the AAAarch Research Group? From majordomo@raleigh.ibm.com Thu Nov 2 12:23:45 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24846 for ; Thu, 2 Nov 2000 12:23:44 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA25824; Thu, 2 Nov 2000 12:10:32 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA20270; Thu, 2 Nov 2000 12:09:35 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32582; Thu, 2 Nov 2000 11:37:24 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57144; Thu, 2 Nov 2000 11:37:20 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32414 for ; Thu, 2 Nov 2000 11:37:26 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA28464 for ; Thu, 2 Nov 2000 11:37:19 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eA2GbOT66435; Thu, 2 Nov 2000 17:37:24 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA21019; Thu, 2 Nov 2000 17:37:15 +0100 Message-Id: <3A01999F.DF3947A6@ccrle.nec.de> Date: Thu, 02 Nov 2000 17:43:11 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Mahadevan Iyer , Policy Mailing List Subject: Re: PQIM draft issues References: <20001030062936.7048.qmail@web1906.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Mahadevan Iyer wrote: > > > > Also - in the last IETF (Pittsburgh) two new drafts > > were presented to model > > TE policy. Should you consider merging the efforts > > there? Should you absorb > > TE policy into ipvpn policy? Note I'm not proposing, > > only asking. You're > > the experts and I'd like to here your opinions. > > I have tried to get in touch with one of them and > explained why, but there hasn't been a whole lot of > response. Mahadevan, As one of the co-authers of one of the MPLS drafts, I can tell you that MPLS VPNs are very hot also form a policy-based management point of view. However, I have not really understand, what your model tries to do. Nor what the new actions, conditions are, you want to introduce, which are not available in QPIM, MLPS, etc. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Nov 3 00:15:20 2000 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 AAA29844 for ; Fri, 3 Nov 2000 00:15:20 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA28924; Fri, 3 Nov 2000 00:04:39 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA37886; Fri, 3 Nov 2000 00:04:34 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26116; Thu, 2 Nov 2000 23:39:23 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49876; Thu, 2 Nov 2000 23:39:17 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA30854 for ; Thu, 2 Nov 2000 23:39:21 -0500 Received: from web1902.mail.yahoo.com (web1902.mail.yahoo.com [128.11.23.51]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id XAA23364 for ; Thu, 2 Nov 2000 23:39:19 -0500 Received: (qmail 5829 invoked by uid 60001); 3 Nov 2000 04:39:18 -0000 Message-Id: <20001103043918.5828.qmail@web1902.mail.yahoo.com> Received: from [198.206.187.100] by web1902.mail.yahoo.com; Thu, 02 Nov 2000 20:39:18 PST Date: Thu, 2 Nov 2000 20:39:18 -0800 (PST) From: Mahadevan Iyer Subject: Re: PQIM draft issues To: Marcus Brunner , Policy Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer > As one of the co-authers of one of the MPLS drafts, > I can tell you that > MPLS VPNs are very hot also form a policy-based > management point of > view. However, I have not really understand, what > your model tries to > do. Nor what the new actions, conditions are, you > want to introduce, > which are not available in QPIM, MLPS, etc. > These are two good questions and I hope what follows answers the questions "What does your model try to do ?" The model tries to integrate the configuration of IP service functions such as firewall, NAT, bandwdith management, VPN(security + connectivity). We are increasingly seeing all these functions being handled simultaenously in a single box. As a vendor selling this kind of a multi function box, we see the service providers benefitting from a common policy information model which support all these functions in a single containment tree. The current trend seems to be to define one model for QoS, another for IPSEC, a third one for MPLS and so on. The fact that they derive from [PCIM] is good but not good enough. The model tries to combine the common aspects(in the policy condition clause) and allow the definition of an extensible set of actions whether it be QoS or IPSEC or MPLS or other IP actions. "What the new actions, conditions are, you want to introduce, which are not available in QPIM, MLPS, etc." I would rather let the WG responsible for the action such as the IPSEC WG (for IPSEC), RAP/DiffServ WG (for QoS), MPLS WG(MPLS) define the actions. I have spelt out my rationale for this in my earlier mail. I am sure you would appreciate the MPLS WG commenting on the actions that you propose rather than being shunted to the policy framework group where your MPLS action model has had little or no discussion on the mailing list. To answer you question in light of my previous comment I don't want us to be defining the actions, but would want to continue to augment the conditions to support the existing and new actions and provide place holders for the actions to be added in future. Once again I would like to see the other WG drive the actions. They are defining these actions in their MIBs and PIBs and need to define them in the policy information model as well. Gratuitous comment ... I was present for the policy sessions in the MPLS group at Pittsburgh and I can see that as long as we don't come out with a clear statement on exactly where we add value to MPLS, they will continue to push this work out of their WG. We need to clearly articulate the value of policy based configuration as opposed to MIB based configuration and explain how they fit in. This needs to be tied in to deployment advantages that vendors/service providers/operators can relate to. I would like to discuss this some more, but will wait to see if people share this point of view. Thanks __________________________________________________ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ From majordomo@raleigh.ibm.com Fri Nov 3 07:00:08 2000 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 HAA19462 for ; Fri, 3 Nov 2000 07:00:08 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA27500; Fri, 3 Nov 2000 06:48:59 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA27450; Fri, 3 Nov 2000 06:48:57 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60222; Fri, 3 Nov 2000 06:22:07 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59190; Fri, 3 Nov 2000 06:22:03 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA04220 for ; Fri, 3 Nov 2000 06:22:08 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA27396 for ; Fri, 3 Nov 2000 06:22:05 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eA3BMBT75760; Fri, 3 Nov 2000 12:22:11 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA27965; Fri, 3 Nov 2000 12:22:01 +0100 Message-Id: <3A02A13E.C07E9DE4@ccrle.nec.de> Date: Fri, 03 Nov 2000 12:27:58 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Mahadevan Iyer Cc: Policy Mailing List Subject: Re: PQIM draft issues References: <20001103043918.5828.qmail@web1902.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Sorry for the last mail, pressed the wrong key. Mahadevan Iyer wrote: > > > As one of the co-authers of one of the MPLS drafts, > > I can tell you that > > MPLS VPNs are very hot also form a policy-based > > management point of > > view. However, I have not really understand, what > > your model tries to > > do. Nor what the new actions, conditions are, you > > want to introduce, > > which are not available in QPIM, MLPS, etc. > > > > These are two good questions and I hope what follows > answers the questions > > "What does your model try to do ?" > > The model tries to integrate the configuration of IP > service functions such as firewall, NAT, bandwdith > management, VPN(security + connectivity). We are > increasingly seeing all these functions being handled > simultaenously in a single box. With single box you refer to a router or a policy server? > As a vendor selling this kind of a multi function box, > we see the service providers benefitting from a common > policy information model which support all these > functions in a single containment tree. Sure, you want to have the policy information model as a single framework to be used for each of the single functions. > The current trend seems to be to define one model for > QoS, another for IPSEC, a third one for MPLS and so > on. The fact that they derive from [PCIM] is good but > not good enough. You mean the shortcommings of PCIM or what? > The model tries to combine the common aspects(in the > policy condition clause) and allow the definition of > an extensible set of actions whether it be QoS or > IPSEC or MPLS or other IP actions. I think the QoS authors already pointed out, that different classes, they need to specify, could be used in various application of the PCIM. > "What the new actions, conditions are, you want to > introduce, which are not available in QPIM, MLPS, > etc." > > I would rather let the WG responsible for the action > such as the IPSEC WG (for IPSEC), RAP/DiffServ WG (for > QoS), MPLS WG(MPLS) define the actions. I have spelt > out my rationale for this in my earlier mail. I am > sure you would appreciate the MPLS WG commenting on > the actions that you propose rather than being shunted > to the policy framework group where your MPLS action > model has had little or no discussion on the mailing > list. The only thing the MPLS group is interrested is if our model complies with the MIB specifications they have. > To answer you question in light of my previous comment > I don't want us to be defining the actions, but would > want to continue to augment the conditions to support > the existing and new actions and provide place holders > for the actions to be added in future. Once again I > would like to see the other WG drive the actions. They > are defining these actions in their MIBs and PIBs and > need to define them in the policy information model as > well. > Some comments on the VPN draft: Why do you specify so many Lists? IPVPNPolicyDomain, IPVPNAdminstrationPolicyList... A policy group can have a name and it is easy to group rules for different areas in different groups. They don't even have new properties. I am against the inflation of classes. I do not understand the concept of tags. What are they used for? Is this something like an inderection intrduced? Why do you need so many? Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Nov 3 09:50:04 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01468 for ; Fri, 3 Nov 2000 09:50:03 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA06780; Fri, 3 Nov 2000 09:27:40 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29310; Fri, 3 Nov 2000 09:26:03 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50644; Fri, 3 Nov 2000 08:59:30 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61388; Fri, 3 Nov 2000 08:59:27 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA35062 for ; Fri, 3 Nov 2000 08:59:22 -0500 From: Ed_Ellesson@tivoli.com Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17]) by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id HAA04532; Fri, 3 Nov 2000 07:58:50 -0600 (CST) Importance: Normal Subject: Policy Slots, Call for Agenda Items To: policy@raleigh.ibm.com Cc: "Joel M. Halpern" Date: Fri, 3 Nov 2000 08:54:53 -0500 Message-Id: X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at 11/03/2000 07:58:11 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com 1. Policy Meeting schedule: During the week we are in San Diego, Policy Framework is scheduled for Monday afternoon, 1-3pm, and Wednesday morning, 9-1130am. Joel and I asked for avoidance of conflicts with the working groups with which we are collaborating, but it's getting harder and harder to avoid these, as policy becomes more important to more working groups. Fortunately, the secretariat was able to avoid most of the potential conflicts. Unfortunately, our first assigned Monday afternoon slot conflicts with the first diffserv session. (The good news is that we do not conflict with the second diffserv session.) Also, unfortunately, we ended up conflicting with ldapext, which we were also trying to avoid. 2. Call for Agenda Items: Please send your suggestions for agenda items to Joel and I. We will pull together an agenda from the suggestions. If, as a result of the above noted schedule, you desire an agenda item to be scheduled for a particular time slot, let us know that as well. Thanks! Ed and Joel From majordomo@raleigh.ibm.com Mon Nov 6 06:25:58 2000 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 GAA10670 for ; Mon, 6 Nov 2000 06:25:58 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA18138; Mon, 6 Nov 2000 06:17:03 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA06672; Mon, 6 Nov 2000 06:15:22 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57292; Mon, 6 Nov 2000 00:53:13 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46020; Mon, 6 Nov 2000 00:53:09 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA36844 for ; Mon, 6 Nov 2000 00:53:13 -0500 Received: from web1904.mail.yahoo.com (web1904.mail.yahoo.com [128.11.23.53]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id AAA30100 for ; Mon, 6 Nov 2000 00:53:06 -0500 Received: (qmail 27325 invoked by uid 60001); 6 Nov 2000 05:53:06 -0000 Message-Id: <20001106055306.27324.qmail@web1904.mail.yahoo.com> Received: from [198.206.187.100] by web1904.mail.yahoo.com; Sun, 05 Nov 2000 21:53:06 PST Date: Sun, 5 Nov 2000 21:53:06 -0800 (PST) From: Mahadevan Iyer Subject: Re: PQIM draft issues To: brunner@ccrle.nec.de Cc: Policy Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer --- Marcus Brunner wrote: > > The model tries to integrate the configuration of > IP > > service functions such as firewall, NAT, bandwdith > > management, VPN(security + connectivity). We are > > increasingly seeing all these functions being > handled > > simultaenously in a single box. > > With single box you refer to a router or a policy > server? Single box = multi function router > > on. The fact that they derive from [PCIM] is good > but > > not good enough. > > You mean the shortcommings of PCIM or what? I mean that the PCIM does what it is supposed to do and does it well i.e. provide the basic platform to define policies Policy applications related to IP services could use a common information model (built on this platform) which integrates the common aspects of IP functions. > > > The model tries to combine the common aspects(in > the > > policy condition clause) and allow the definition > of > > an extensible set of actions whether it be QoS or > > IPSEC or MPLS or other IP actions. > > I think the QoS authors already pointed out, that > different classes, > they need to specify, could be used in various > application of the PCIM. This was mentioned in a previous mail and my reply remains the same. It is laudable that the QoS authors mention this, but clearly the main purpose of the draft is to define the QoS specific conditions and actions. Discussing the pros and cons of these classes w.r.t. to the IPVPN information model is a follow up discussion. I am not sure we are there yet. It is important to remember here that as per the last communication I have received the IPVPN draft is not considered to be in line with the WG charter. I would be glad to discuss this off line with you, but at the momemt I do not want to get distracted from the main point I am trying to make i.e. "Lets create the common policy information model(integrating the policy conditions across IP functions, single containment tree etc) and leave the action definitions to the WGs" > > The only thing the MPLS group is interrested is if > our model complies > with the MIB specifications they have. So once the MIB is in place, what additional value does the MPLS policy information model provide ? > Some comments on the VPN draft: > > Why do you specify so many Lists? IPVPNPolicyDomain, > IPVPNAdminstrationPolicyList... > A policy group can have a name and it is easy to > group rules for > different areas in different groups. They don't even > have new > properties. I am against the inflation of classes. Inflation is bad, but each of the lists has a purpose. If you can suggest a means to collapse the lists and differentiate between the different purposes I would be glad to discuss it. Once again going back to my previous comment on the focus of this thread I would like to get the main question answered before we get into the merits of portions of the draft. > > I do not understand the concept of tags. What are > they used for? Is this > something like an inderection intrduced? Why do you > need so many? A tag, is a label assigned to a resource such as(network, users, policy enforcers, application filters) so that they can be referenced in a policy condition. A network tag could be statically associated with a resource using an IP address or dynamically associated when the network is plugged into a switch port and authenticates itself. It would be useful to hear from vendors such as Orchestream if they are tapped into this mailing list. I assume they have a lot of experience in this area and can shed some light on whether this (objective of the IPVPN draft) goes beyond "sure it would be nice" to "yes this is key". __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From majordomo@raleigh.ibm.com Mon Nov 6 07:18:22 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28129 for ; Mon, 6 Nov 2000 07:18:22 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA29008; Mon, 6 Nov 2000 07:09:54 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA26746; Mon, 6 Nov 2000 07:08:17 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27376; Mon, 6 Nov 2000 01:04:04 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32104; Mon, 6 Nov 2000 01:03:35 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA30868 for ; Mon, 6 Nov 2000 01:03:38 -0500 Received: from web1905.mail.yahoo.com (web1905.mail.yahoo.com [128.11.23.54]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA18936 for ; Mon, 6 Nov 2000 01:03:36 -0500 Received: (qmail 21160 invoked by uid 60001); 6 Nov 2000 06:03:37 -0000 Message-Id: <20001106060337.21159.qmail@web1905.mail.yahoo.com> Received: from [198.206.187.100] by web1905.mail.yahoo.com; Sun, 05 Nov 2000 22:03:37 PST Date: Sun, 5 Nov 2000 22:03:37 -0800 (PST) From: Mahadevan Iyer Subject: Re: Policy Slots, Call for Agenda Items To: Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com Cc: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer > 2. Call for Agenda Items: > > Please send your suggestions for agenda items to > Joel and I. Hello Ed, I would like to see some discussion on the objectives of the WG, in light of the thread titled "Re: PQIM draft issues" going on in the mailing list. However if there has been no substantial change in how the WG organizers see it(objectives) I don't want to use up a session essentially repeating what I had to say last time. Thanks __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From majordomo@raleigh.ibm.com Wed Nov 8 18:48:23 2000 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 SAA09010 for ; Wed, 8 Nov 2000 18:48:22 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA34596; Wed, 8 Nov 2000 18:39:49 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA35704; Wed, 8 Nov 2000 18:39:45 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26540; Wed, 8 Nov 2000 17:17:21 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53918; Wed, 8 Nov 2000 17:17:18 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAB25460 for ; Wed, 8 Nov 2000 17:17:24 -0500 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA27422 for ; Wed, 8 Nov 2000 17:17:20 -0500 Received: from research.telcordia.com (myko-pc [192.4.12.83]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eA8MGpa14275; Wed, 8 Nov 2000 17:16:52 -0500 (EST) Message-Id: <3A09D0AC.C3B80BA2@research.telcordia.com> Date: Wed, 08 Nov 2000 17:16:12 -0500 From: George Mykoniatis X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 Cc: policy@raleigh.ibm.com Subject: Re: Policy Framework Working Group Meeting Minutes, Pittsburgh IETF References: <86256942.0062B1ED.00@tivmta4.tivoli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: George Mykoniatis Content-Transfer-Encoding: 7bit Hi, What is the relationship of the QOS Device Info Model to the QOSPIM and PIBs? Was that discussed in the mailing list after the Pittsburg meeting, as agreed, and if yes what was the result? George. From the minutes: > > 5. There are questions about the QOS Device Info Model draft: (need discussion > on the mailing list) > > -best way to do filter characterization > -how to position relative to pib, mib and diffserv conceptual model > -relationship to service elements, capabilities, and to qos policy draft and > other documents > > need discussion on the list > From majordomo@raleigh.ibm.com Thu Nov 9 13:24:17 2000 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 NAA13545 for ; Thu, 9 Nov 2000 13:24:17 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA34204; Thu, 9 Nov 2000 13:09:26 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA33548; Thu, 9 Nov 2000 13:09:23 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA96172; Thu, 9 Nov 2000 12:38:28 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA97184; Thu, 9 Nov 2000 12:38:24 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA29010 for ; Thu, 9 Nov 2000 12:38:29 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA26668 for ; Thu, 9 Nov 2000 12:38:25 -0500 Received: from ysnirnt70 (ysnir-isdn-home.cisco.com [10.49.112.178]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id TAA26944; Thu, 9 Nov 2000 19:37:29 +0200 (IST) From: "Yoram Snir" To: , Cc: "'Joel M. Halpern'" Subject: RE: Policy Slots, Call for Agenda Items Date: Thu, 9 Nov 2000 19:35:13 +0200 Message-Id: <001801c04a73$6ae634a0$b270310a@ysnirnt70> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Ed please reserve a slot in order to present the new version of QPIM. Thanks. Yoram Snir > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of > Ed_Ellesson@tivoli.com > Sent: Friday, November 03, 2000 3:55 PM > To: policy@raleigh.ibm.com > Cc: Joel M. Halpern > Subject: Policy Slots, Call for Agenda Items > > > 1. Policy Meeting schedule: > > During the week we are in San Diego, Policy Framework is scheduled for > Monday afternoon, 1-3pm, and Wednesday morning, 9-1130am. Joel and I > asked for avoidance of conflicts with the working groups > with which we are > collaborating, but it's getting harder and harder to avoid > these, as policy > becomes more important to more working groups. Fortunately, the > secretariat was able to avoid most of the potential conflicts. > Unfortunately, our first assigned Monday afternoon slot > conflicts with the > first diffserv session. (The good news is that we do not > conflict with the > second diffserv session.) Also, unfortunately, we ended up > conflicting > with ldapext, which we were also trying to avoid. > > 2. Call for Agenda Items: > > Please send your suggestions for agenda items to Joel and I. > We will pull > together an agenda from the suggestions. If, as a result of > the above > noted schedule, you desire an agenda item to be scheduled for > a particular > time slot, let us know that as well. > > Thanks! > > > Ed and Joel > > From majordomo@raleigh.ibm.com Thu Nov 9 17:02:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24476 for ; Thu, 9 Nov 2000 17:02:35 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA17896; Thu, 9 Nov 2000 16:52:14 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA31828; Thu, 9 Nov 2000 16:52:01 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA96138; Thu, 9 Nov 2000 16:21:27 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59774; Thu, 9 Nov 2000 16:21:24 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA36052 for ; Thu, 9 Nov 2000 16:21:30 -0500 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA24126 for ; Thu, 9 Nov 2000 16:11:35 -0500 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA04861 for ; Thu, 9 Nov 2000 16:11:30 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA04839 for ; Thu, 9 Nov 2000 16:11:29 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 22:11:19 +0100 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0A070C92@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Policy Mailing List , Yoram Snir Cc: "Joel M. Halpern" , Ed Ellesson Subject: RE: Policy Slots, Call for Agenda Items Date: Thu, 9 Nov 2000 22:11:16 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Comments inline > ---------- > From: Yoram Snir[SMTP:ysnir@cisco.com] > Reply To: Yoram Snir > Sent: Thursday, November 09, 2000 6:35 PM > To: Ed_Ellesson@tivoli.com; policy@raleigh.ibm.com > Cc: 'Joel M. Halpern' > Subject: RE: Policy Slots, Call for Agenda Items > > Ed > please reserve a slot in order to present the new version of QPIM. > Thanks. > Sorry, the IETF is not a conference where we "present" things. People should have read the drafts. The authors can present a list of open issues/concerns and lead a discussion to try and come to resolutions. I am sure you understand... but though I would make the point. Bert > Yoram Snir > > > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of > > Ed_Ellesson@tivoli.com > > Sent: Friday, November 03, 2000 3:55 PM > > To: policy@raleigh.ibm.com > > Cc: Joel M. Halpern > > Subject: Policy Slots, Call for Agenda Items > > > > > > 1. Policy Meeting schedule: > > > > During the week we are in San Diego, Policy Framework is scheduled for > > Monday afternoon, 1-3pm, and Wednesday morning, 9-1130am. Joel and I > > asked for avoidance of conflicts with the working groups > > with which we are > > collaborating, but it's getting harder and harder to avoid > > these, as policy > > becomes more important to more working groups. Fortunately, the > > secretariat was able to avoid most of the potential conflicts. > > Unfortunately, our first assigned Monday afternoon slot > > conflicts with the > > first diffserv session. (The good news is that we do not > > conflict with the > > second diffserv session.) Also, unfortunately, we ended up > > conflicting > > with ldapext, which we were also trying to avoid. > > > > 2. Call for Agenda Items: > > > > Please send your suggestions for agenda items to Joel and I. > > We will pull > > together an agenda from the suggestions. If, as a result of > > the above > > noted schedule, you desire an agenda item to be scheduled for > > a particular > > time slot, let us know that as well. > > > > Thanks! > > > > > > Ed and Joel > > > > > From majordomo@raleigh.ibm.com Fri Nov 10 02:55:15 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11491 for ; Fri, 10 Nov 2000 02:55:15 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA27906; Fri, 10 Nov 2000 02:29:16 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id CAA21900; Fri, 10 Nov 2000 02:27:25 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA84908; Fri, 10 Nov 2000 01:03:02 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59552; Fri, 10 Nov 2000 01:02:58 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA27990 for ; Fri, 10 Nov 2000 01:02:59 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA19244 for ; Fri, 10 Nov 2000 01:02:57 -0500 Received: from ysnirnt70 (ysnir-isdn-home.cisco.com [10.49.112.178]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id IAA10090; Fri, 10 Nov 2000 08:02:22 +0200 (IST) From: "Yoram Snir" To: "'Wijnen, Bert \(Bert\)'" , "'Policy Mailing List'" Cc: "'Joel M. Halpern'" , "'Ed Ellesson'" Subject: RE: Policy Slots, Call for Agenda Items Date: Fri, 10 Nov 2000 08:00:05 +0200 Message-Id: <006601c04adb$79674c40$b270310a@ysnirnt70> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0A070C92@nl0006exch002u.nl.lucent.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Bert The QPIM is in it's 4th iteration and I only meant to present the changes / open issues. Regrettably, it would be a great surprise to see that most of the people attending the WG session have actually read the drafts discussed. Yoram > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, November 09, 2000 11:11 PM > To: Policy Mailing List; Yoram Snir > Cc: Joel M. Halpern; Ed Ellesson > Subject: RE: Policy Slots, Call for Agenda Items > > > Comments inline > > > ---------- > > From: Yoram Snir[SMTP:ysnir@cisco.com] > > Reply To: Yoram Snir > > Sent: Thursday, November 09, 2000 6:35 PM > > To: Ed_Ellesson@tivoli.com; policy@raleigh.ibm.com > > Cc: 'Joel M. Halpern' > > Subject: RE: Policy Slots, Call for Agenda Items > > > > Ed > > please reserve a slot in order to present the new version of QPIM. > > Thanks. > > > Sorry, the IETF is not a conference where we "present" things. > People should have read the drafts. The authors can present > a list of open issues/concerns and lead a discussion to try and > come to resolutions. > > I am sure you understand... but though I would make the point. > > Bert > > > Yoram Snir > > > > > > > -----Original Message----- > > > From: policy-owner@raleigh.ibm.com > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of > > > Ed_Ellesson@tivoli.com > > > Sent: Friday, November 03, 2000 3:55 PM > > > To: policy@raleigh.ibm.com > > > Cc: Joel M. Halpern > > > Subject: Policy Slots, Call for Agenda Items > > > > > > > > > 1. Policy Meeting schedule: > > > > > > During the week we are in San Diego, Policy Framework is > scheduled for > > > Monday afternoon, 1-3pm, and Wednesday morning, 9-1130am. > Joel and I > > > asked for avoidance of conflicts with the working groups > > > with which we are > > > collaborating, but it's getting harder and harder to avoid > > > these, as policy > > > becomes more important to more working groups. Fortunately, the > > > secretariat was able to avoid most of the potential conflicts. > > > Unfortunately, our first assigned Monday afternoon slot > > > conflicts with the > > > first diffserv session. (The good news is that we do not > > > conflict with the > > > second diffserv session.) Also, unfortunately, we ended up > > > conflicting > > > with ldapext, which we were also trying to avoid. > > > > > > 2. Call for Agenda Items: > > > > > > Please send your suggestions for agenda items to Joel and I. > > > We will pull > > > together an agenda from the suggestions. If, as a result of > > > the above > > > noted schedule, you desire an agenda item to be scheduled for > > > a particular > > > time slot, let us know that as well. > > > > > > Thanks! > > > > > > > > > Ed and Joel > > > > > > > > > From majordomo@raleigh.ibm.com Mon Nov 13 00:22:34 2000 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 AAA29733 for ; Mon, 13 Nov 2000 00:22:33 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA22062; Mon, 13 Nov 2000 00:09:59 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA29030; Mon, 13 Nov 2000 00:09:55 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35294; Sun, 12 Nov 2000 23:40:23 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA84950; Sun, 12 Nov 2000 23:40:19 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA34674 for ; Sun, 12 Nov 2000 23:40:21 -0500 Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA34830 for ; Sun, 12 Nov 2000 23:40:18 -0500 Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA06899; Sun, 12 Nov 2000 20:32:21 -0800 (PST) From: "Andrea Westerinen" To: "Mahadevan Iyer" , Cc: "Policy Mailing List" Subject: RE: PQIM draft issues Date: Sun, 12 Nov 2000 20:36:29 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20001106055306.27324.qmail@web1904.mail.yahoo.com> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Just a quick comment - Policy is but one part of an information model. You need the concept of Policy PLUS the rest of the model. Policy acts on the nouns, using the verbs, of the rest of the information model. My recommendation would be to start with the nouns and verbs, decide what you want to model and affect - and then start on the Policy (condition/action pairs). Policy is about automated operation and automated management. You need to have a model that supports operation and management, before you can automate it. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mahadevan Iyer Sent: Sunday, November 05, 2000 9:53 PM To: brunner@ccrle.nec.de Cc: Policy Mailing List Subject: Re: PQIM draft issues --- Marcus Brunner wrote: > > The model tries to integrate the configuration of > IP > > service functions such as firewall, NAT, bandwdith > > management, VPN(security + connectivity). We are > > increasingly seeing all these functions being > handled > > simultaenously in a single box. > > With single box you refer to a router or a policy > server? Single box = multi function router > > on. The fact that they derive from [PCIM] is good > but > > not good enough. > > You mean the shortcommings of PCIM or what? I mean that the PCIM does what it is supposed to do and does it well i.e. provide the basic platform to define policies Policy applications related to IP services could use a common information model (built on this platform) which integrates the common aspects of IP functions. > > > The model tries to combine the common aspects(in > the > > policy condition clause) and allow the definition > of > > an extensible set of actions whether it be QoS or > > IPSEC or MPLS or other IP actions. > > I think the QoS authors already pointed out, that > different classes, > they need to specify, could be used in various > application of the PCIM. This was mentioned in a previous mail and my reply remains the same. It is laudable that the QoS authors mention this, but clearly the main purpose of the draft is to define the QoS specific conditions and actions. Discussing the pros and cons of these classes w.r.t. to the IPVPN information model is a follow up discussion. I am not sure we are there yet. It is important to remember here that as per the last communication I have received the IPVPN draft is not considered to be in line with the WG charter. I would be glad to discuss this off line with you, but at the momemt I do not want to get distracted from the main point I am trying to make i.e. "Lets create the common policy information model(integrating the policy conditions across IP functions, single containment tree etc) and leave the action definitions to the WGs" > > The only thing the MPLS group is interrested is if > our model complies > with the MIB specifications they have. So once the MIB is in place, what additional value does the MPLS policy information model provide ? > Some comments on the VPN draft: > > Why do you specify so many Lists? IPVPNPolicyDomain, > IPVPNAdminstrationPolicyList... > A policy group can have a name and it is easy to > group rules for > different areas in different groups. They don't even > have new > properties. I am against the inflation of classes. Inflation is bad, but each of the lists has a purpose. If you can suggest a means to collapse the lists and differentiate between the different purposes I would be glad to discuss it. Once again going back to my previous comment on the focus of this thread I would like to get the main question answered before we get into the merits of portions of the draft. > > I do not understand the concept of tags. What are > they used for? Is this > something like an inderection intrduced? Why do you > need so many? A tag, is a label assigned to a resource such as(network, users, policy enforcers, application filters) so that they can be referenced in a policy condition. A network tag could be statically associated with a resource using an IP address or dynamically associated when the network is plugged into a switch port and authenticates itself. It would be useful to hear from vendors such as Orchestream if they are tapped into this mailing list. I assume they have a lot of experience in this area and can shed some light on whether this (objective of the IPVPN draft) goes beyond "sure it would be nice" to "yes this is key". __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ From majordomo@raleigh.ibm.com Mon Nov 13 00:49:40 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06344 for ; Mon, 13 Nov 2000 00:49:40 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA12006; Mon, 13 Nov 2000 00:38:54 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA06494; Mon, 13 Nov 2000 00:38:57 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA75090; Mon, 13 Nov 2000 00:13:18 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34634; Mon, 13 Nov 2000 00:13:14 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA32530 for ; Mon, 13 Nov 2000 00:13:18 -0500 Received: from web1902.mail.yahoo.com (web1902.mail.yahoo.com [128.11.23.51]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id AAA06544 for ; Mon, 13 Nov 2000 00:13:13 -0500 Received: (qmail 9420 invoked by uid 60001); 13 Nov 2000 05:13:17 -0000 Message-Id: <20001113051317.9419.qmail@web1902.mail.yahoo.com> Received: from [198.206.187.100] by web1902.mail.yahoo.com; Sun, 12 Nov 2000 21:13:17 PST Date: Sun, 12 Nov 2000 21:13:17 -0800 (PST) From: Mahadevan Iyer Subject: RE: PQIM draft issues To: Andrea Westerinen , brunner@ccrle.nec.de Cc: Policy Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer > My recommendation would be to start with the nouns > and verbs, decide what > you want to model and affect - and then start on the > Policy > (condition/action pairs). The nouns are a relatively static set The verbs are an infinitely extensible set My recommendation is that lets focus on integrating the nouns(condition). The value we bring is that new verbs can be plugged in and instantly benefit from the noun set. Note, having the same base classes or even the same sub classes(in each of the information models) is not sufficient, we need to have a single containment tree. So the solution will have to allow for new verbs to be seamlessly "plugged in" into the containment tree. If you wait for the nouns and the verbs to be finalized and keep building separate information models, you will end up with stove pipe model models for the verbs. I am sure that there will be some attempt to integrate the stove pipes but the longer we wait, the more specialized each model becomes, the harder it gets. Andrea, Just to avoid any confusion ... I quote from your draft --------------------------------------------- "While this iteration of this draft concentrates on defining an information model that can represent DiffServ QoS services, the ultimate goal is to be able to apply policies that control these services in network devices. " --------------------------------------------- I am in full agreement of the efforts to flush things out QoS and I think this QoS work will serve as a much needed example of how far policies can go. All I am saying that the WG could also look at work such as the IPVPN draft and keep both tracks moving. We could start work on looking at common information models for all possible IP services. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From majordomo@raleigh.ibm.com Mon Nov 13 01:21:15 2000 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 BAA19779 for ; Mon, 13 Nov 2000 01:21:14 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA42558; Mon, 13 Nov 2000 01:11:16 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA35478; Mon, 13 Nov 2000 01:11:16 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61550; Mon, 13 Nov 2000 00:40:00 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50278; Mon, 13 Nov 2000 00:39:57 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id AAA27734 for ; Mon, 13 Nov 2000 00:40:01 -0500 Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA14460 for ; Mon, 13 Nov 2000 00:39:54 -0500 Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA09548; Sun, 12 Nov 2000 21:26:44 -0800 (PST) From: "Andrea Westerinen" To: "Mahadevan Iyer" , Cc: "Policy Mailing List" Subject: RE: PQIM draft issues Date: Sun, 12 Nov 2000 21:30:52 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20001113051317.9419.qmail@web1902.mail.yahoo.com> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Comments inline. Andrea -----Original Message----- From: Mahadevan Iyer [mailto:iyermahadevan@yahoo.com] Sent: Sunday, November 12, 2000 9:13 PM To: Andrea Westerinen; brunner@ccrle.nec.de Cc: Policy Mailing List Subject: RE: PQIM draft issues > My recommendation would be to start with the nouns > and verbs, decide what > you want to model and affect - and then start on the > Policy > (condition/action pairs). The nouns are a relatively static set The verbs are an infinitely extensible set Are the verbs infinitely extensible or are their implementations extensible? If the verbs are extensible, then how do you benefit from conditions/actions? Yes, I agree that you can add more actions, but you can also add subclasses with additional verbs. Objects have basic operations. My recommendation is that lets focus on integrating the nouns(condition). The value we bring is that new verbs can be plugged in and instantly benefit from the noun set. My only feedback on this comes from experience. If you define your nouns in isolation from how you want to use them, then you often-times end up with the wrong design of the nouns. If you design them from the context of widely ranging verbs (with some forethought given to what those verbs can be), then you are more likely to have a better noun set. Note, having the same base classes or even the same sub classes(in each of the information models) is not sufficient, we need to have a single containment tree. So the solution will have to allow for new verbs to be seamlessly "plugged in" into the containment tree. I do not believe that all implementations will want a single containment tree. So, to design to this point may cause problems. If you wait for the nouns and the verbs to be finalized and keep building separate information models, you will end up with stove pipe model models for the verbs. I am sure that there will be some attempt to integrate the stove pipes but the longer we wait, the more specialized each model becomes, the harder it gets. I did not say wait for the nouns and verbs, but think first about the nouns and your "infinitely extensible" set of verbs before jumping into automating them. Also, I did not say that the info models are separately built. They are built as one overlapping, inter-related model - reusing the class hierarchy as much as possible. I would argue instead that building isolated condition/action sets is much more likely to lead to stove piped policy. Andrea, Just to avoid any confusion ... I quote from your draft --------------------------------------------- "While this iteration of this draft concentrates on defining an information model that can represent DiffServ QoS services, the ultimate goal is to be able to apply policies that control these services in network devices. " --------------------------------------------- I am in full agreement of the efforts to flush things out QoS and I think this QoS work will serve as a much needed example of how far policies can go. All I am saying that the WG could also look at work such as the IPVPN draft and keep both tracks moving. We could start work on looking at common information models for all possible IP services. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From majordomo@raleigh.ibm.com Mon Nov 13 01:39:14 2000 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 BAA01664 for ; Mon, 13 Nov 2000 01:39:14 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA42424; Mon, 13 Nov 2000 01:29:41 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id BAA27876; Mon, 13 Nov 2000 01:29:40 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA83742; Mon, 13 Nov 2000 01:01:47 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA83930; Mon, 13 Nov 2000 01:01:41 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA25836 for ; Mon, 13 Nov 2000 01:01:45 -0500 Received: from web1902.mail.yahoo.com (web1902.mail.yahoo.com [128.11.23.51]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA17804 for ; Mon, 13 Nov 2000 01:01:38 -0500 Received: (qmail 14085 invoked by uid 60001); 13 Nov 2000 06:01:44 -0000 Message-Id: <20001113060144.14084.qmail@web1902.mail.yahoo.com> Received: from [198.206.187.100] by web1902.mail.yahoo.com; Sun, 12 Nov 2000 22:01:44 PST Date: Sun, 12 Nov 2000 22:01:44 -0800 (PST) From: Mahadevan Iyer Subject: RE: PQIM draft issues To: Andrea Westerinen , brunner@ccrle.nec.de Cc: Policy Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer > My only feedback on this comes from > experience. If you define your > nouns in isolation from how you want to use them, > then you often-times end > up with the wrong design of the nouns. If you > design them from the context > of widely ranging verbs (with some forethought given > to what those verbs can > be), then you are more likely to have a better noun > set. I agree that it is difficult. I think that the nouns will also evolve in response to new verbs. I also believe that there is significant understanding of the key IP services(mentioned in the IPVPN draft) to come up with a common noun set. > I do not believe that all implementations will > want a single > containment tree. So, to design to this point may > cause problems. I can tell you from practical experience of having to deploy a multi function box, we would very much like to see a single containment tree for common IP functions. It will certainly cause problems if not done right. If done right I believe it will add significant value. I understand that what we choose, what integrate and what we leave out is something that is open to discussion. > > If you wait for the nouns and the verbs to be > finalized and keep building separate information > models, you will end up with stove pipe model models > for the verbs. I am sure that there will be some > attempt to integrate the stove pipes but the longer > we > wait, the more specialized each model becomes, the > harder it gets. > > I did not say wait for the nouns and verbs, > but think first about the > nouns and your "infinitely extensible" set of verbs > before jumping into > automating them. I don't want to jump into anything :-) I would welcome further thinking and discussions on the details of this problem. Also, I did not say that the info > models are separately > built. They are built as one overlapping, > inter-related model - reusing the > class hierarchy as much as possible. I would argue > instead that building > isolated condition/action sets is much more likely > to lead to stove piped > policy. I think we can agree to disagree :-) __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ From majordomo@raleigh.ibm.com Mon Nov 13 06:31:00 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00634 for ; Mon, 13 Nov 2000 06:30:59 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA30814; Mon, 13 Nov 2000 06:19:55 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA28810; Mon, 13 Nov 2000 06:19:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41710; Mon, 13 Nov 2000 05:44:57 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38628; Mon, 13 Nov 2000 05:44:54 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA30792 for ; Mon, 13 Nov 2000 05:44:54 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA25650 for ; Mon, 13 Nov 2000 05:44:52 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eADAjEE21265; Mon, 13 Nov 2000 11:45:14 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA09065; Mon, 13 Nov 2000 11:44:45 +0100 Message-Id: <3A0FC79A.A11AF918@ccrle.nec.de> Date: Mon, 13 Nov 2000 11:51:06 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Andrea Westerinen Cc: Mahadevan Iyer , Policy Mailing List Subject: Re: PQIM draft issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Andrea, I totally agree on that. The problem lies in what "nouns and verbs" are per-defined (in the drafts). IMO, there should be a set of area-independent classes to operate on specific models. Marcus Andrea Westerinen wrote: > > Just a quick comment - Policy is but one part of an information model. You > need the concept of Policy PLUS the rest of the model. Policy acts on the > nouns, using the verbs, of the rest of the information model. > > My recommendation would be to start with the nouns and verbs, decide what > you want to model and affect - and then start on the Policy > (condition/action pairs). Policy is about automated operation and automated > management. You need to have a model that supports operation and > management, before you can automate it. > > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mahadevan Iyer > Sent: Sunday, November 05, 2000 9:53 PM > To: brunner@ccrle.nec.de > Cc: Policy Mailing List > Subject: Re: PQIM draft issues > > --- Marcus Brunner wrote: > > > The model tries to integrate the configuration of > > IP > > > service functions such as firewall, NAT, bandwdith > > > management, VPN(security + connectivity). We are > > > increasingly seeing all these functions being > > handled > > > simultaenously in a single box. > > > > With single box you refer to a router or a policy > > server? > > Single box = multi function router > > > > on. The fact that they derive from [PCIM] is good > > but > > > not good enough. > > > > You mean the shortcommings of PCIM or what? > > I mean that the PCIM does what it is supposed to do > and > does it well i.e. provide the basic platform to define > policies > > Policy applications related to IP services could use > a common information model (built on this platform) > which integrates the common aspects of IP functions. > > > > > > The model tries to combine the common aspects(in > > the > > > policy condition clause) and allow the definition > > of > > > an extensible set of actions whether it be QoS or > > > IPSEC or MPLS or other IP actions. > > > > I think the QoS authors already pointed out, that > > different classes, > > they need to specify, could be used in various > > application of the PCIM. > > This was mentioned in a previous mail and my reply > remains the same. > It is laudable that the QoS authors mention this, but > clearly the main purpose of the draft is to define the > QoS specific conditions and actions. > > Discussing the pros and cons of these classes w.r.t. > to the IPVPN information model is a follow up > discussion. I am not sure we are there yet. It is > important to remember here that as per the last > communication I have received the IPVPN draft is not > considered to be in line with the WG charter. > > I would be glad to discuss this off line with you, but > at the momemt I do not want to get distracted from the > main point I am trying to make i.e. "Lets create the > common policy information model(integrating the policy > conditions across IP functions, single containment > tree etc) and leave the action definitions to the WGs" > > > > > The only thing the MPLS group is interrested is if > > our model complies > > with the MIB specifications they have. > > So once the MIB is in place, what additional value > does the MPLS policy information model provide ? > > > Some comments on the VPN draft: > > > > Why do you specify so many Lists? IPVPNPolicyDomain, > > IPVPNAdminstrationPolicyList... > > A policy group can have a name and it is easy to > > group rules for > > different areas in different groups. They don't even > > have new > > properties. I am against the inflation of classes. > > Inflation is bad, but each of the lists has a purpose. > If you can suggest a means to collapse the lists and > differentiate between the different purposes I would > be glad to discuss it. Once again going back to my > previous comment on the focus of this thread I would > like to get the main question answered before we get > into the merits of portions of the draft. > > > > > I do not understand the concept of tags. What are > > they used for? Is this > > something like an inderection intrduced? Why do you > > need so many? > > A tag, is a label assigned to a resource such > as(network, users, policy enforcers, application > filters) so that they can be referenced in a policy > condition. A network tag could be statically > associated with a resource using an IP address or > dynamically associated when the network is plugged > into a switch port and authenticates itself. > > It would be useful to hear from vendors such as > Orchestream if they are tapped into this mailing list. > I assume they have a lot of experience in this area > and can shed some light on whether this (objective of > the IPVPN draft) goes beyond "sure it would be nice" > to "yes this is key". > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one Place. > http://shopping.yahoo.com/ -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Mon Nov 13 06:47:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09650 for ; Mon, 13 Nov 2000 06:47:24 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA25118; Mon, 13 Nov 2000 06:37:56 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA27088; Mon, 13 Nov 2000 06:37:53 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30396; Mon, 13 Nov 2000 06:07:58 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38628; Mon, 13 Nov 2000 05:44:54 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA30792 for ; Mon, 13 Nov 2000 05:44:54 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA25650 for ; Mon, 13 Nov 2000 05:44:52 -0500 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eADAjEE21265; Mon, 13 Nov 2000 11:45:14 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA09065; Mon, 13 Nov 2000 11:44:45 +0100 Message-Id: <3A0FC79A.A11AF918@ccrle.nec.de> Date: Mon, 13 Nov 2000 11:51:06 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Andrea Westerinen Cc: Mahadevan Iyer , Policy Mailing List Subject: Re: PQIM draft issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Andrea, I totally agree on that. The problem lies in what "nouns and verbs" are per-defined (in the drafts). IMO, there should be a set of area-independent classes to operate on specific models. Marcus Andrea Westerinen wrote: > > Just a quick comment - Policy is but one part of an information model. You > need the concept of Policy PLUS the rest of the model. Policy acts on the > nouns, using the verbs, of the rest of the information model. > > My recommendation would be to start with the nouns and verbs, decide what > you want to model and affect - and then start on the Policy > (condition/action pairs). Policy is about automated operation and automated > management. You need to have a model that supports operation and > management, before you can automate it. > > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mahadevan Iyer > Sent: Sunday, November 05, 2000 9:53 PM > To: brunner@ccrle.nec.de > Cc: Policy Mailing List > Subject: Re: PQIM draft issues > > --- Marcus Brunner wrote: > > > The model tries to integrate the configuration of > > IP > > > service functions such as firewall, NAT, bandwdith > > > management, VPN(security + connectivity). We are > > > increasingly seeing all these functions being > > handled > > > simultaenously in a single box. > > > > With single box you refer to a router or a policy > > server? > > Single box = multi function router > > > > on. The fact that they derive from [PCIM] is good > > but > > > not good enough. > > > > You mean the shortcommings of PCIM or what? > > I mean that the PCIM does what it is supposed to do > and > does it well i.e. provide the basic platform to define > policies > > Policy applications related to IP services could use > a common information model (built on this platform) > which integrates the common aspects of IP functions. > > > > > > The model tries to combine the common aspects(in > > the > > > policy condition clause) and allow the definition > > of > > > an extensible set of actions whether it be QoS or > > > IPSEC or MPLS or other IP actions. > > > > I think the QoS authors already pointed out, that > > different classes, > > they need to specify, could be used in various > > application of the PCIM. > > This was mentioned in a previous mail and my reply > remains the same. > It is laudable that the QoS authors mention this, but > clearly the main purpose of the draft is to define the > QoS specific conditions and actions. > > Discussing the pros and cons of these classes w.r.t. > to the IPVPN information model is a follow up > discussion. I am not sure we are there yet. It is > important to remember here that as per the last > communication I have received the IPVPN draft is not > considered to be in line with the WG charter. > > I would be glad to discuss this off line with you, but > at the momemt I do not want to get distracted from the > main point I am trying to make i.e. "Lets create the > common policy information model(integrating the policy > conditions across IP functions, single containment > tree etc) and leave the action definitions to the WGs" > > > > > The only thing the MPLS group is interrested is if > > our model complies > > with the MIB specifications they have. > > So once the MIB is in place, what additional value > does the MPLS policy information model provide ? > > > Some comments on the VPN draft: > > > > Why do you specify so many Lists? IPVPNPolicyDomain, > > IPVPNAdminstrationPolicyList... > > A policy group can have a name and it is easy to > > group rules for > > different areas in different groups. They don't even > > have new > > properties. I am against the inflation of classes. > > Inflation is bad, but each of the lists has a purpose. > If you can suggest a means to collapse the lists and > differentiate between the different purposes I would > be glad to discuss it. Once again going back to my > previous comment on the focus of this thread I would > like to get the main question answered before we get > into the merits of portions of the draft. > > > > > I do not understand the concept of tags. What are > > they used for? Is this > > something like an inderection intrduced? Why do you > > need so many? > > A tag, is a label assigned to a resource such > as(network, users, policy enforcers, application > filters) so that they can be referenced in a policy > condition. A network tag could be statically > associated with a resource using an IP address or > dynamically associated when the network is plugged > into a switch port and authenticates itself. > > It would be useful to hear from vendors such as > Orchestream if they are tapped into this mailing list. > I assume they have a lot of experience in this area > and can shed some light on whether this (objective of > the IPVPN draft) goes beyond "sure it would be nice" > to "yes this is key". > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one Place. > http://shopping.yahoo.com/ -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Mon Nov 13 12:35:34 2000 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 MAA11913 for ; Mon, 13 Nov 2000 12:35:34 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA10442; Mon, 13 Nov 2000 12:24:59 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA28880; Mon, 13 Nov 2000 12:24:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41570; Mon, 13 Nov 2000 11:50:10 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35418; Mon, 13 Nov 2000 11:50:06 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27622 for ; Mon, 13 Nov 2000 11:50:08 -0500 Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29800 for ; Mon, 13 Nov 2000 11:50:06 -0500 Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA18241; Mon, 13 Nov 2000 08:46:22 -0800 (PST) From: "Andrea Westerinen" To: "Marcus Brunner" Cc: "Mahadevan Iyer" , "Policy Mailing List" Subject: RE: PQIM draft issues Date: Mon, 13 Nov 2000 08:50:28 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3A0FC79A.A11AF918@ccrle.nec.de> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit YES! Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Marcus Brunner Sent: Monday, November 13, 2000 2:51 AM To: Andrea Westerinen Cc: Mahadevan Iyer; Policy Mailing List Subject: Re: PQIM draft issues Andrea, I totally agree on that. The problem lies in what "nouns and verbs" are per-defined (in the drafts). IMO, there should be a set of area-independent classes to operate on specific models. Marcus Andrea Westerinen wrote: > > Just a quick comment - Policy is but one part of an information model. You > need the concept of Policy PLUS the rest of the model. Policy acts on the > nouns, using the verbs, of the rest of the information model. > > My recommendation would be to start with the nouns and verbs, decide what > you want to model and affect - and then start on the Policy > (condition/action pairs). Policy is about automated operation and automated > management. You need to have a model that supports operation and > management, before you can automate it. > > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mahadevan Iyer > Sent: Sunday, November 05, 2000 9:53 PM > To: brunner@ccrle.nec.de > Cc: Policy Mailing List > Subject: Re: PQIM draft issues > > --- Marcus Brunner wrote: > > > The model tries to integrate the configuration of > > IP > > > service functions such as firewall, NAT, bandwdith > > > management, VPN(security + connectivity). We are > > > increasingly seeing all these functions being > > handled > > > simultaenously in a single box. > > > > With single box you refer to a router or a policy > > server? > > Single box = multi function router > > > > on. The fact that they derive from [PCIM] is good > > but > > > not good enough. > > > > You mean the shortcommings of PCIM or what? > > I mean that the PCIM does what it is supposed to do > and > does it well i.e. provide the basic platform to define > policies > > Policy applications related to IP services could use > a common information model (built on this platform) > which integrates the common aspects of IP functions. > > > > > > The model tries to combine the common aspects(in > > the > > > policy condition clause) and allow the definition > > of > > > an extensible set of actions whether it be QoS or > > > IPSEC or MPLS or other IP actions. > > > > I think the QoS authors already pointed out, that > > different classes, > > they need to specify, could be used in various > > application of the PCIM. > > This was mentioned in a previous mail and my reply > remains the same. > It is laudable that the QoS authors mention this, but > clearly the main purpose of the draft is to define the > QoS specific conditions and actions. > > Discussing the pros and cons of these classes w.r.t. > to the IPVPN information model is a follow up > discussion. I am not sure we are there yet. It is > important to remember here that as per the last > communication I have received the IPVPN draft is not > considered to be in line with the WG charter. > > I would be glad to discuss this off line with you, but > at the momemt I do not want to get distracted from the > main point I am trying to make i.e. "Lets create the > common policy information model(integrating the policy > conditions across IP functions, single containment > tree etc) and leave the action definitions to the WGs" > > > > > The only thing the MPLS group is interrested is if > > our model complies > > with the MIB specifications they have. > > So once the MIB is in place, what additional value > does the MPLS policy information model provide ? > > > Some comments on the VPN draft: > > > > Why do you specify so many Lists? IPVPNPolicyDomain, > > IPVPNAdminstrationPolicyList... > > A policy group can have a name and it is easy to > > group rules for > > different areas in different groups. They don't even > > have new > > properties. I am against the inflation of classes. > > Inflation is bad, but each of the lists has a purpose. > If you can suggest a means to collapse the lists and > differentiate between the different purposes I would > be glad to discuss it. Once again going back to my > previous comment on the focus of this thread I would > like to get the main question answered before we get > into the merits of portions of the draft. > > > > > I do not understand the concept of tags. What are > > they used for? Is this > > something like an inderection intrduced? Why do you > > need so many? > > A tag, is a label assigned to a resource such > as(network, users, policy enforcers, application > filters) so that they can be referenced in a policy > condition. A network tag could be statically > associated with a resource using an IP address or > dynamically associated when the network is plugged > into a switch port and authenticates itself. > > It would be useful to hear from vendors such as > Orchestream if they are tapped into this mailing list. > I assume they have a lot of experience in this area > and can shed some light on whether this (objective of > the IPVPN draft) goes beyond "sure it would be nice" > to "yes this is key". > > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one Place. > http://shopping.yahoo.com/ -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Nov 17 17:19:25 2000 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 RAA12622 for ; Fri, 17 Nov 2000 17:19:24 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA24116; Fri, 17 Nov 2000 17:07:44 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA25574; Fri, 17 Nov 2000 17:07:34 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35530; Fri, 17 Nov 2000 15:48:46 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35508; Fri, 17 Nov 2000 15:48:37 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA34916 for ; Fri, 17 Nov 2000 15:48:41 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25922 for ; Fri, 17 Nov 2000 15:48:33 -0500 Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eAHKn9E09264 for ; Fri, 17 Nov 2000 21:49:09 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id VAA12702 for ; Fri, 17 Nov 2000 21:48:43 +0100 Message-Id: <3A14F20C.1D5C4BA0@ccrle.nec.de> Date: Fri, 17 Nov 2000 09:53:32 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Policy Mailing List Subject: draft on PCIM extensions submitted Content-Type: multipart/mixed; boundary="------------9DCFE0DF89F07998E4EE711B" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner This is a multi-part message in MIME format. --------------9DCFE0DF89F07998E4EE711B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We have just submitted a draft titled "Policy Framework Core Info Model Extensions". It basically contains a list of open issues together with some preliminary proposals for solutions. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 --------------9DCFE0DF89F07998E4EE711B Content-Type: text/plain; charset=us-ascii; name="draft-brunner-policy-core-ext-00.txt" Content-Disposition: inline; filename="draft-brunner-policy-core-ext-00.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT M. Brunner J. Quittek Expires in six months NEC Corporation November 17, 2000 Policy Framework Core Info Model Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo should help starting the discussion on extensions of the Policy Framework Core Information Model (PCIM). It does not replace nor change concepts used in PCIM, but tries to add concepts, which could help different application areas to define policies more easily by reusing some of the concepts proposed in this draft. The draft basically tries to generalize concepts introduced by other drafts such as the Policy Framework QoS Information Model [PQIM]. The focus lies in means for specifying general conditions and actions. Additionally, group ordering, events, and variables are introduced. 1. Introduction PCIM as proposed today is a well defined as a high-level information model for policies. However, many concepts are useful for the simple case, whereas more complicated policies poses problems using the Brunner draft-brunner-policy-core-ext-00 [Page 1] Internet Draft Policy Framework Core IM Extensions November 2000 classes available. The other problem lies in a set of application areas using the basic model and adapt and enhance it to area specific needs. It turns out that many concepts are developed again and again, e.g., filters, variables, simple conditions etc. The goal of this draft is to extend PCIM with general constructs, which may be used in other areas. Basically, they center around generic definition of conditions and actions with the knowlege of the structure of the modeling language. They are heavily influenced by constructs used in [PQIM], [PMPLS], and [PIPSEC]. The draft in its current state is far from being complete. e.g., the definition of class do not contain any formal property definition yet. However, the proposed concepts and the list of open issues should help discussing useful extensions to the core information model. Other authors are very welcome to contribute to make the policy framework core information model useful in various areas. 2. PolicyGroup Ordering In PCIM, the policyRule has a property Priority, which allows a manager to give a rule priority over others. However, it is not specified what the scope of the priority is, in the system or in the group. We propose a class OrderedPolicyGroup, which has a property priority as well. This allows for prioritizing groups over other groups. Furthermore, groups within the OrderPolicyGroup are ordered via the rule's or group's priority property. Additionally, the scope of the priority is only within that group, not globally as it could be read in PCIM. Groups in OrderPolicyGroups not being of type OrderPolicyGroup or a derivative of it, have the least priority. Note, that the functionality could be placed in the aggregation PolicyGroupinPolicyGroup as well. (What is preferred?) NAME OrderedPolicyGroup DERIVED FROM PolicyGroup (defined in [PCIM]) ABSTRACT False PROPERTIES Priority [int] 3. Conditions 3.1. BasicPolicyCondition This class refines the basic structure of the policyCondition class Brunner draft-brunner-policy-core-ext-00 [Page 2] Internet Draft Policy Framework Core IM Extensions November 2000 defined in [PCIM] by using the triplet , and . The SimplePolicyCondition of PQIM is similar in structure, and a special case of this one, where the right variable has a constant value. The operator is relational and the binding is given by the types of both sides. Whether the operator is statically of dynamically bound (variable type or value type) is for further study. If one of the variables evaluate to undefined, the condition evaluates to false. What kind of RelOperators do we want? For example, the RelOperator property values may be - equal, notequal, lessthan, greaterthan, lessthanequal, greaterthanequal, for totally ordered values - startswith, endswith, equals, contains, for strings - contains, in, equals, includes, intersects, for sets NAME BasicPolicyCondition DERIVED FROM PolicyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES firstVariable [ref PolicyVariable], RelOperator [String], secondVariable [ref PolicyVariable] 3.2. Class PolicyObjectTypeSelector Basically, PCIM uses the policyRole property in the PolicyRule class in order to select a set of objects the rule should apply to. The selection may be refined by conditions. This kind of condition is special in the sense, that it compares the set of objects available in the context (basically specified by the role) whether they are of the type specified in this condition. So the rule containing this selector in the condition list operates only on objects of the specific type. This is very convenient, because it allows a policy designer to specify the actions with the knowledge, that only objects of a specific type will pass the condition. NAME PolicyObjectTypeSelector DERIVED FROM policyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES SelectorClassName 3.3. Class PolicyAssociatedObjectSelector Brunner draft-brunner-policy-core-ext-00 [Page 3] Internet Draft Policy Framework Core IM Extensions November 2000 The PolicyAssociatedObjectSelector provides means to select objects only if they are associated with objects of a certain type and the AssocObjectPolicyCondition evaluates to true. Note that the class has a association to PolicyConditions (PolicyConditionInAssocObjectSelector). With that it is possible to specify again a PolicyAssociationObjectSelector as the condition. This allows to recursivly hop throught associated object. Furthermore, note that the condition within this selector has a different context, compared to the condition itself. Conceptually, the PolicyAssociatedObjectSelector takes a set of objects and checks for all of them, whether they are in an association of type AssociationClassName where the object in this association is of type AssocObjectClassName and the policy condition evaluates to true. NAME PolicyAssociatedObjectSelector DERIVED FROM policyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES AssociationClassName, AssocObjectClassName, 3.4. Association PolicyConditionInAssocObjectSelector This association ties together the PolicyAssociatedObjectSelector with a PolicyCondition. NAME PolicyConditionInAssocObjectSelector ABSTRACT False PROPERTIES selector [ref PolicyObjectTypeSelector[0..1]], condition [ref PolicyCondition[0..1]] 4. Variables Variables may be global or local. We propose to use only local variables, which means a variable is always used in the context of an object. 4.1. Class PolicyAttributeVariable The PolicyAttributeVariable has an attribute name and a class name as properties. The class name specifies in what scope the attribute name is valid. The class name is only used in cases, where attribute names are not globally unique. Conceptually, if the variable is used in a condition, it evaluates to the value of the attribute named by AttributeName. Note, that this variable may be undefined. This means the basic condition it is contained in evaluates to false. Brunner draft-brunner-policy-core-ext-00 [Page 4] Internet Draft Policy Framework Core IM Extensions November 2000 NAME PolicyAttributeVariable DERIVED FROM Policy (defined in [PCIM]) ABSTRACT False PROPERTIES AttrClassName, AttributeName 5. Actions 5.1. Class PolicyAttributeSetAction The AttributeSetAction is used to set or change a value of an attribute. The action has again a class name and an attribute name as property. The class name specifies what type of objects to set, and the attribute name specifies what attribute to change. Note again, in case of globally unique attribute names, the class name is not used in the action. The semantic behind the AttributeSetAction is, that setting the attribute of an object results in the configuration of the real object, represented by that object. If the attribute is not compatible with the type of the value, the action is not performed. NAME PolicyAttributeSetAction DERIVED FROM PolicyAction (defined in [PCIM]) ABSTRACT False PROPERTIES AttrSetClassName, AttributeSetName, value 6. Events 6.1. PolicyEvent An event is a mean for triggering a rule to be evaluated. The source of the event may be in- or outside of the policy engine. Therefore, an event has in its basic version no source identification associated. However, classes derived from the base class may add the source, if needed. The PolicyEvent has a time and date when it happened. It has a name. The event name is used to differ the events. It could be usefule to add a context string, which make different policy models more independet and less error prone, because of global name spaces. The semantic behind the event is open, but see the next section for conditions on events. However, typically the name will also define the semantic of the event. Brunner draft-brunner-policy-core-ext-00 [Page 5] Internet Draft Policy Framework Core IM Extensions November 2000 NAME PolicyEvent DERIVED FROM Policy (defined in [PCIM]) ABSTRACT False PROPERTIES event_time, event_date, event_name 6.2. PolicyEventCondition The event condition evaluates to true if an event happened with the name specified in cond_event_name. In general, there is no time constrain defined, until when the rule containing the event condition needs to be evaluated. But depending on the execution environment of the policy rules, this may immediately trigger the evaluation of the policy rule containing the event condition. After evaluating all rules in the system, containing the event condition in its condition tree, the event does not exist anymore, and the condition is evaluating to false for all further evaluations until the event is created once more. Note that, with this definition of the semantic, we do not run into problems of nested conditions and rules, which contain associations to the same event condition. However, more advanced semantics are possible, but may produce difficult to implement semantic. NAME PolicyEventCondition DERIVED FROM PolicyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES cond_event_name 6.3. PolicyEventCreateAction The PolicyEventCreateAction creates an event with a certain name. This may be useful in cases, where you have multi-level policy systems running in the same execution environment. NAME PolicyEventCreateAction DERIVED FROM PolicyAction (defined in [PCIM]) ABSTRACT False PROPERTIES create_event_name 7. Security Considerations The security considerations for this document are the same as those of the [PCIM] and are not further addressed in this version of the draft. Brunner draft-brunner-policy-core-ext-00 [Page 6] Internet Draft Policy Framework Core IM Extensions November 2000 8. Open Issues 8.1. Multi-Object Selectors There are many cases where you want to select two or more objects, in order to associate the two objects, or all objects in a set to each other. 8.2. Creation of Objects It could be very beneficial for policies to create objects just with the type information, and set the attributes afterwards. However, what is the semantic of the creation of an object? 8.3. Creation of Associations Section 8.1, already mention the problem of multi-object selection. One goal could be the creation of a new association, between these objects. This action would not be difficult to specify, but it is not useful without the multi-object selection. 8.4. Modification of Associations Until now, we have no means other than area specific actions, which allow a policy designer to implement the modification of an association, or its properties. 8.5. Expressions How can we set or change attributes and parameters of action by an expression (e.g., set bandwidth to 50% of the existing one) 8.6. IP specific filters Filters are used many times, why not specifing it in the PCIM extension. 9. References [PCIM] B. Moore, E. Ellesson, J. Strassner, "Policy Core Information Model -- Version 1 Specification", Internet Draft, , May, 2000 [PQIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy Framework QoS Information Model", Internet draft, , April 2000 [PMPLS] K. Isoyama, M. Brunner, M. Yoshida, J. Quittek, R. Chadha, Brunner draft-brunner-policy-core-ext-00 [Page 7] Internet Draft Policy Framework Core IM Extensions November 2000 A. Poylisher, G. Mykoniatis, A. Kind,F. Reichmeyer, "Policy Framework MPLS Information Model for QoS and TE" , December 2000. [PIPSEC] J. Jason, "IPsec Configuration Policy Model", Internet draft , July 2000. 10. Authors' Addresses Marcus Brunner, Juergen Quittek NEC Europe Ltd. C&C Research Laboratories Adenauerplatz 6 D-69115 Heidelberg, Germany Phone: +49 (0)6221 905110 Fax: +49 (0)6221 9051155 Email: [brunner|quittek]@ccrle.nec.de Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brunner draft-brunner-policy-core-ext-00 [Page 8] --------------9DCFE0DF89F07998E4EE711B-- From majordomo@raleigh.ibm.com Sun Nov 19 22:11:18 2000 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 WAA15614 for ; Sun, 19 Nov 2000 22:11:17 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA21534; Sun, 19 Nov 2000 22:02:45 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA26580; Sun, 19 Nov 2000 22:02:36 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45082; Sun, 19 Nov 2000 21:05:44 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48638; Sun, 19 Nov 2000 21:05:40 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA21462 for ; Sun, 19 Nov 2000 21:05:43 -0500 Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA13186 for ; Sun, 19 Nov 2000 21:05:41 -0500 Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA09501; Sun, 19 Nov 2000 18:05:14 -0800 (PST) From: "Andrea Westerinen" To: "Jon Saperia" , , "snmpconf" Subject: RE: Comments on the draft-ietf-policy-terminology-00.txt document Date: Sun, 19 Nov 2000 18:09:01 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Jon, I realized that I never replied to this list of comments. As the polterm editors are about to rev the draft for the next meeting, it would be good to close on some of these issues. Replies are inline. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Jon Saperia Sent: Monday, August 28, 2000 7:24 AM To: policy@raleigh.ibm.com; snmpconf Subject: Comments on the draft-ietf-policy-terminology-00.txt document Here are some comments on the recent draft. Sorry for the cross posting. I know that some on the SNMPCONF WG list are not on the policy list. On Page 3: > - "M" identifies various mechanisms to create or convey policy- > related information in a network. For example, COPS and an > "Information Model" are two mechanisms for communicating and > describing policy-related data. Perhaps we need another term. Mechanism has come to be used in the context of a technology used to realize a particular policy in a policy domain. An example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy domain. This use of "mechanism" really seems more of a convention than a definition. However, for clarity, an alternative might be "(T) Technique". In addition, there are several places in the document (see also page 7) that would benefit from a clearer expansion of the terms that are currently in use in terms of levels of abstraction. At present 4 levels of abstraction have been defined and are now in common use in the SNMPCONF documents. They are: 1. Domain Specific. 2. Mechanism Specific 3. Implementation Specific 4. Instance Specific Although these abstractions may work within the context of SNMPConf, they do not translate to the extended scope of general policy - moving from SLAs down to specific device abstractions. In previous versions of the terminology and policy framework documents, the number of levels of abstraction was debated at length. The decision was that you could not say that there were only 3, 4 or 6 levels - since a particular implementation may require more or less. (SNMPConf does indeed assume a specific context and implementation.) Your terms certainly fit within the definition of "abstraction", and could be referenced as examples. Here is some new text: $ policy abstraction (P) Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Translation between different levels of "abstraction" may require information, other than policy, such as network and host parameter configuration and capabilities. Various documents and implementations may specify explicit levels of abstraction [for example, DiffPolicy]. However, these do not necessarily correspond to distinct processing entities or the complete set of levels in all environments. (See also "configuration" and "policy translation.") <\arw> Rather than quote the entirety of these terms, here are the reference IDs: draft-ietf-snmpconf-diffpolicy-02.txt draft-ietf-snmpconf-bcp-02.txt Additional background information is found in: draft-saperia-policysnmp-00.txt I believe that community will be well served by a common set of terms as they relate to these levels of abstraction. On Page 4 > Common Open Policy System (COPS) I have no issue with the inclusion of this specific mechanism and components of its architecture such as PDPs and PEPs. To the extent that we choose to define such technologies in this document, we should also define the SNMP-based ones as well and it based documents - those references are pretty well known. With regard to SNMPCONF specific items this document should also include items such as: Policy MIB Module Mechanism and Implementation Specific MIB Modules Policy Management Application (see above references) What new terms are you defining? I agree that we should add another "(T)technique" that says that policy can be defined via MIBs and reference the SNMPConf work. Here is the new text... $ Policy Management Information Base (MIB) (T) Collections of policy-related managed objects, defined as a module and accessed via an SNMP framework. [PolicyMIB] This definition is consistent with the PIB one. Other than this new technique (T), I do not know of any other new terms that should be defined. As regards, a "policy management application" - this does not appear to be a "term" in any of the SNMPConf documents, but is discussed in draft-saperia-policysnmp-00.txt. In the latter, it is tied strictly to SNMP and RFC2571. This does not seem to be a general/generic term or even require definition since there does not seem to be any ambiguity related to it. IMHO, I believe that ultimately all "management applications" will deal with policy in one form or another, whether they are SNMP-based or not. Also on Page 4 > configuration I found this paragraph a bit confusing. The telco industry uses configuration to refer to parameters that 'are set at the factory' and are not generally changeable by the customer. Provisioning refers to those parameters that are customer changeable. I think there is a useful concept in the paragraph which points to user or provisioning system(s) setting of object values versus those that are dynamic or run time. The best example I can give is in the routing are where a set of BGP or OSPF configuration values are set by the user, but the routing information is continuously changing while the system is running. The position articulated by John Schnizlein seems very relevant here: > The Internet industry seems to use "configuration" to mean > changable parameters, as in the Dynamic Host Configuration Protocol > [RFC 2131]. The BOF announced with Policy Terminology was called > Configuration Management (excerpt below). The WG you co-chair is > called Configuration Management with SNMP (snmpconf). > > My impression is that there is a rough consensus that we would be > better served using this word as in the Internet context rather than > in the "telco industry" you cite. However, this is not meant to slight the telco industry. So, we can add an alternate definition and clarify that it is not the "Internet industry"s usage. We have done this in other parts of the document. On Page 5. > Directory Enabled Networks (DEN) My issue is not the inclusion or definition. I would like for us to have generic terms that are not dependent on the DMTF as well. For example what shall we call the general data model that is not LDAP specific? There can only be an "information model" that is not protocol/repository-specific - which we describe in PCIM. There cannot be a "data model" one. By definition, "data models" are repository/protocol specific. The reason that DEN is mentioned is that it was designed to use a directory as a policy repository. It is directly tied to policy. Since this is an IETF document, I think we should not only reference the work that the document is based on, but the technology over which we have change control and will use, perhaps in addition to other technologies. Agreed. However, there is also no reason to slight other relevant work since our customers hear these terms and could be confused. On pages 7, 9, 11 and 12: Terms such as policy condition, policy action, policy rule, role and role combination. I assume this document will be revised to reflect discussions that came out of the IETF meeting to resolve term conflicts that Andrea and Steve Waldbusser and others have had. I have not seen documentation of these discussions and look forward to those clarifications. We did resolve the definitions of Role and Role Combination. No other terminology issues were raised. Here are the new definitions for roles ... $ role An administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules, to determine the applicability of the rule to a particular managed element. [SNMPCONF, PCIM, PIB] $ role combination (P) An unordered set of roles that characterize managed elements and indicate the applicability of policy rules. A policy system uses the set of roles reported by the managed element to determine the correct policy rules to be sent for enforcement. That determination may examine all applicable policy rules identified by the role combination, its sub- combinations and the individual roles in the combination [PCIM], or may require that rules explicitly match the role combination specified for the managed element [PIB]. The final set of rules for enforcement are defined by the policy system, as appropriate for the specified role combination of the managed element. Page 9 > Policy Information Base (PIB) Same comment as before. No issue with definition, we just need to add the SNMP counterparts. Policy MIB is added as documented above. Page 10 > policy server I do have an issue with this definition. It states: > (P) A marketing term whose definition is imprecise. Originally, > [R2753] referenced a "policy server." As the RFC evolved, this > term became more precise and known as the Policy Decision Point > (PDP). Today, the term is used in marketing and other > literature to refer specifically to a PDP, or for any entity > that uses/services policy. In the SNMPCONF work we have been using policy application for some time since PDP and PEP have a very specific and sometimes different set of behaviors than SNMP. The goal of the definition was not to establish "policy server" as a real term, but to say that it is an "imprecise"/"marketing" term. The whole goal of "policy server" was to give the history of the term, which has caused confusion in the past. Since SNMPConf's documents do not reference this term, there is no ambiguity. Also, you are justified in not using the term, since it is "imprecise." BTW, I am very reluctant to add "policy application" as a formal term - since it is just a "policy" adjective in front of a general term. Even SNMPConf's I-Ds do not formally define it. Also on Page 10. > PolicyRepository I feel this should be a generic term since many people will store the information cited in systems and formats not common to PCIM or CIM. We actually have the generic and specific terms defined in the document. Here is the generic ... $ policy repository (P) "Policy repository" can be defined from three perspectives: - A specific data store that holds policy rules, their conditions and actions, and related policy data. A directory would be an example of such a store. - A logical container representing the administrative scope and naming of policy rules, their conditions and actions, and related policy data. A QoS policy domain would be an example of such a container. [QoSModel] - In [PCIM], a more restrictive definition than the prior one exists. PolicyRepository is a model abstraction representing an administratively defined, logical container for reusable policy conditions and policy actions. These comments aside. The document is a good start and will be quite helpful. Thanks. /jon From majordomo@raleigh.ibm.com Mon Nov 20 18:03:07 2000 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 SAA05083 for ; Mon, 20 Nov 2000 18:03:06 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA06422; Mon, 20 Nov 2000 17:48:14 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA28982; Mon, 20 Nov 2000 17:48:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22226; Mon, 20 Nov 2000 15:14:45 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22216; Mon, 20 Nov 2000 15:14:42 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA03496 for ; Mon, 20 Nov 2000 15:14:44 -0500 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA20660 for ; Mon, 20 Nov 2000 15:14:41 -0500 Received: from mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id PAA09634; Mon, 20 Nov 2000 15:14:50 -0500 (EST) Message-Id: <3A198634.9CA069D3@mediaone.net> Date: Mon, 20 Nov 2000 15:14:44 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Andrea Westerinen Cc: policy@raleigh.ibm.com, snmpconf , Jon Saperia Subject: Re: Comments on the draft-ietf-policy-terminology-00.txt document References: Content-Type: multipart/mixed; boundary="------------6C9AAF11CDA2066283416305" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia This is a multi-part message in MIME format. --------------6C9AAF11CDA2066283416305 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrea Westerinen wrote: --------------6C9AAF11CDA2066283416305 Content-Type: text/plain; charset=us-ascii; name="drafttoarw" Content-Disposition: inline; filename="drafttoarw" Content-Transfer-Encoding: 7bit > Jon, I realized that I never replied to this list of comments. As the > polterm editors are about to rev the draft for the next meeting, it would be > good to close on some of these issues. Thanks for the reply. In the interest of brevity. I have cut out some of the extraneous material. > On Page 3: > > > - "M" identifies various mechanisms to create or convey policy- > > related information in a network. For example, COPS and an > > "Information Model" are two mechanisms for communicating and > > describing policy-related data. > > Perhaps we need another term. Mechanism has come to be used in the context > of a technology used to realize a particular policy in a policy domain. An > example would be RED or WRED in DiffServ of BGP Policy in the Routing Policy > domain. > > > This use of "mechanism" really seems more of a convention than a definition. > However, for clarity, an alternative might be "(T) Technique". > I am happy with technique. It does sound like COPS or SNMP are both being used as transport and data definition tools. I understand in an absolute sense that the protocol(s) for transport and the languages for data definition, are not really the concern of policy. To the extent that they are used to transport and define that information, it might be helpful to identify terms that reference the functions of policy transport and data definition. > > In addition, there are several places in the document (see also page 7) that > would benefit from a clearer expansion of the terms that are currently in > use in terms of levels of abstraction. At present 4 levels of abstraction > have been defined and are now in common use in the SNMPCONF documents. They > are: > 1. Domain Specific. > 2. Mechanism Specific > 3. Implementation Specific > 4. Instance Specific > > > Although these abstractions may work within the context of SNMPConf, they do > not translate to the extended scope of general policy - moving from SLAs > down to specific device abstractions. In previous versions of the > terminology and policy framework documents, the number of levels of > abstraction was debated at length. The decision was that you could not say > that there were only 3, 4 or 6 levels - since a particular implementation > may require more or less. (SNMPConf does indeed assume a specific context > and implementation.) Your terms certainly fit within the definition of > "abstraction", and could be referenced as examples. Here is some new text: > $ policy abstraction > (P) Policy can be represented at different levels, ranging from > business goals to device-specific configuration parameters. > Translation between different levels of "abstraction" may require > information, other than policy, such as network and host > parameter configuration and capabilities. Various documents and > implementations may specify explicit levels of abstraction > [for example, DiffPolicy]. However, these do not necessarily > correspond to distinct processing entities or the complete set > of levels in all environments. (See also "configuration" and > "policy translation.") > <\arw> > This is a good start. You should reference the current documents on the web site. The terms are in the documents cited below. > Rather than quote the entirety of these terms, here are the reference IDs: > draft-ietf-snmpconf-diffpolicy-02.txt > draft-ietf-snmpconf-bcp-02.txt > Additional background information is found in: > draft-saperia-policysnmp-00.txt > > I believe that community will be well served by a common set of terms as > they relate to these levels of abstraction. > > On Page 4 > > > Common Open Policy System (COPS) > > I have no issue with the inclusion of this specific mechanism and components > of its architecture such as PDPs and PEPs. To the extent that we choose to > define such technologies in this document, we should also define the > SNMP-based ones as well and it based documents - those references are pretty > well known. With regard to SNMPCONF specific items this document should > also include items such as: > > Policy MIB Module > Mechanism and Implementation Specific MIB Modules > Policy Management Application > > (see above references) > > > What new terms are you defining? I agree that we should add another > "(T)technique" that says that policy can be defined via MIBs and reference > the SNMPConf work. Here is the new text... When you reference COPS as in the case above and PDPs and PEPs, they are protocol specific concepts. A policy management application and/or agent would be the comparable items in a Policy-enabled SNMP environment. > $ Policy Management Information Base (MIB) > (T) Collections of policy-related managed objects, defined as > a module and accessed via an SNMP framework. [PolicyMIB] > This definition is consistent with the PIB one. Other than this new > technique (T), I do not know of any other new terms that should be defined. > Not sure the SNMPCONF talks much about Policy Management Information Base unless you mean the Policy Module that controls the behavior of the managed system. We have Implementation, Mechanism, and Instance specific MIB Modules. All of which could contain 'policy' data. > As regards, a "policy management application" - this does not appear to be a > "term" in any of the SNMPConf documents, but is discussed in > draft-saperia-policysnmp-00.txt. In the latter, it is tied strictly to SNMP > and RFC2571. This does not seem to be a general/generic term or even > require definition since there does not seem to be any ambiguity related to > it. IMHO, I believe that ultimately all "management applications" will deal > with policy in one form or another, whether they are SNMP-based or not. > > If a policy Management Application is tied to SNMP, a PDP and PEP and COPs are all also specific technology terms and should not be referenced. Either we equally reference both or we should purge technology specifics. I do not feel strongly one way or the other. > Also on Page 4 > > > configuration > > I found this paragraph a bit confusing. The telco industry uses > configuration to refer to parameters that 'are set at the factory' and are > not generally changeable by the customer. Provisioning refers to those > parameters that are customer changeable. > > I think there is a useful concept in the paragraph which points to user or > provisioning system(s) setting of object values versus those that are > dynamic or run time. The best example I can give is in the routing are where > a set of BGP or OSPF configuration values are set by the user, but the > routing information is continuously changing while the system is running. > > > The position articulated by John Schnizlein seems very relevant here: > > The Internet industry seems to use "configuration" to mean > > changable parameters, as in the Dynamic Host Configuration Protocol > > [RFC 2131]. The BOF announced with Policy Terminology was called > > Configuration Management (excerpt below). The WG you co-chair is > > called Configuration Management with SNMP (snmpconf). > > > > My impression is that there is a rough consensus that we would be > > better served using this word as in the Internet context rather than > > in the "telco industry" you cite. > However, this is not meant to slight the telco industry. So, we can add an > alternate definition and clarify that it is not the "Internet industry"s > usage. We have done this in other parts of the document. > > Fine. > On Page 5. > > > Directory Enabled Networks (DEN) > > My issue is not the inclusion or definition. I would like for us to have > generic terms that are not dependent on the DMTF as well. For example what > shall we call the general data model that is not LDAP specific? > > > There can only be an "information model" that is not > protocol/repository-specific - which we describe in PCIM. There cannot be a > "data model" one. By definition, "data models" are repository/protocol > specific. The reason that DEN is mentioned is that it was designed to use a > directory as a policy repository. It is directly tied to policy. > > I would feel much more comfortable with the effort if we could include an example that used a database model as well. > Since this is an IETF document, I think we should not only reference the > work that the document is based on, but the technology over which we have > change control > and will use, perhaps in addition to other technologies. > > > Agreed. However, there is also no reason to slight other relevant work > since our customers hear these terms and could be confused. > > good then we can include some words about databases as well. > On pages 7, 9, 11 and 12: > > Terms such as policy condition, policy action, policy rule, role and role > combination. I assume this document will be revised to reflect discussions > that came out of the IETF meeting to resolve term conflicts that Andrea and > Steve Waldbusser and others have had. I have not seen documentation of these > discussions and look forward to those clarifications. > > > We did resolve the definitions of Role and Role Combination. No other > terminology issues were raised. Here are the new definitions for roles ... > $ role > An administratively specified characteristic of a managed > element (for example, an interface). It is a selector for > policy rules, to determine the applicability of the rule > to a particular managed element. [SNMPCONF, PCIM, PIB] > $ role combination > (P) An unordered set of roles that characterize managed > elements and indicate the applicability of policy rules. > A policy system uses the set of roles reported by the managed > element to determine the correct policy rules to be sent for > enforcement. That determination may examine all applicable > policy rules identified by the role combination, its sub- > combinations and the individual roles in the combination > [PCIM], or may require that rules explicitly match the role > combination specified for the managed element [PIB]. The > final set of rules for enforcement are defined by the > policy system, as appropriate for the specified role > combination of the managed element. > > > Page 9 > > > Policy Information Base (PIB) > > Same comment as before. No issue with definition, we just need to add the > SNMP counterparts. > > > Policy MIB is added as documented above. > Please see my comments above. > > Page 10 > > > policy server > > I do have an issue with this definition. It states: > > > (P) A marketing term whose definition is imprecise. Originally, > > [R2753] referenced a "policy server." As the RFC evolved, this > > term became more precise and known as the Policy Decision Point > > (PDP). Today, the term is used in marketing and other > > literature to refer specifically to a PDP, or for any entity > > that uses/services policy. > > In the SNMPCONF work we have been using policy application for some time > since PDP and PEP have a very specific and sometimes different set of > behaviors than SNMP. > > > The goal of the definition was not to establish "policy server" as a real > term, but to say that it is an "imprecise"/"marketing" term. The whole goal > of "policy server" was to give the history of the term, which has caused > confusion in the past. Since SNMPConf's documents do not reference this > term, there is no ambiguity. Also, you are justified in not using the term, > since it is "imprecise." BTW, I am very reluctant to add "policy > application" as a formal term - since it is just a "policy" adjective in > front of a general term. Even SNMPConf's I-Ds do not formally define it. > > > Also on Page 10. > > > PolicyRepository > > I feel this should be a generic term since many people will store the > information cited in systems and formats not common to PCIM or CIM. > > > We actually have the generic and specific terms defined in the document. > Here is the generic ... > $ policy repository > (P) "Policy repository" can be defined from three perspectives: > - A specific data store that holds policy rules, their > conditions and actions, and related policy data. A directory > would be an example of such a store. > - A logical container representing the administrative scope and > naming of policy rules, their conditions and actions, and > related policy data. A QoS policy domain would be an example > of such a container. [QoSModel] > - In [PCIM], a more restrictive definition than the prior one > exists. PolicyRepository is a model abstraction representing an > administratively defined, logical container for reusable policy > conditions and policy actions. > > I have not issue with these except to the extent that people think they are only realized in LDAP implementations. LDAP can be used to store policy data as well as relational and other technologies. Thanks /jon --------------6C9AAF11CDA2066283416305-- From majordomo@raleigh.ibm.com Mon Nov 20 18:12:39 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06336 for ; Mon, 20 Nov 2000 18:12:39 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA33500; Mon, 20 Nov 2000 18:03:41 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA24950; Mon, 20 Nov 2000 17:57:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42850; Mon, 20 Nov 2000 17:10:03 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35162; Mon, 20 Nov 2000 17:09:57 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA26140 for ; Mon, 20 Nov 2000 17:10:00 -0500 Received: from cisco.com (ups.cisco.com [171.69.18.21]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA22818 for ; Mon, 20 Nov 2000 17:09:57 -0500 Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA15935; Mon, 20 Nov 2000 14:09:07 -0800 (PST) From: Keith McCloghrie Message-Id: <200011202209.OAA15935@cisco.com> Subject: Re: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document To: snmpconf@snmp.com Date: Mon, 20 Nov 2000 14:09:06 -0800 (PST) Cc: andreaw@cisco.com (Andrea Westerinen), policy@raleigh.ibm.com, saperia@jdscons.com (Jon Saperia) In-Reply-To: <3A198634.9CA069D3@mediaone.net> from "Jon Saperia" at Nov 20, 2000 03:14:44 PM X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Keith McCloghrie Content-Transfer-Encoding: 7bit > When you reference COPS as in the case above and PDPs and PEPs, they are > protocol specific concepts. A policy management application and/or agent > would be the comparable items in a Policy-enabled SNMP environment. Jon, I think you have it round the wrong way. The PDP and PEP terminology was coined by the RAP WG for the purpose of describing "A Framework for Policy-based Admission Control" (RFC 2753), which is specified independently of the COPS-protocol. Keith. From majordomo@raleigh.ibm.com Mon Nov 20 19:15:55 2000 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 TAA14580 for ; Mon, 20 Nov 2000 19:15:54 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA27942; Mon, 20 Nov 2000 19:06:23 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA27812; Mon, 20 Nov 2000 19:06:01 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39104; Mon, 20 Nov 2000 16:53:28 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41656; Mon, 20 Nov 2000 16:53:24 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA32398 for ; Mon, 20 Nov 2000 16:53:24 -0500 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA27126 for ; Mon, 20 Nov 2000 16:53:21 -0500 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA28236; Mon, 20 Nov 2000 13:52:28 -0800 (PST) Message-Id: <4.1.20001120163101.00b5d100@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 20 Nov 2000 16:50:33 -0500 To: Jon Saperia From: John Schnizlein Subject: Re: snmpconf Re: Comments on the draft-ietf-policy-terminology-00.txt document Cc: policy@raleigh.ibm.com, snmpconf In-Reply-To: <3A198634.9CA069D3@mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein It was in our attempt to include both terms from both the COPS and the SNMP-CONF efforts that we included Policy MIB along with PEP and PDP. Please send replacement (corrected) text for this definition. In general, the Policy Terms draft has been around long enough that the preferred form of comments is replacement (or edited) text rather than general questions. This preference also applies to the comments regarding other database technologies. We would gladly include any policy terms that reference databases other than directories or MIBs. It is worth noting that this terminology draft is not intended to imply any particular architecture for policy management. John At 03:14 PM 11/20/2000 -0500, Jon Saperia wrote: >Andrea Westerinen wrote: >>.. >When you reference COPS as in the case above and PDPs and PEPs, they are >protocol specific concepts. A policy management application and/or agent >would be the comparable items in a Policy-enabled SNMP environment. > >> $ Policy Management Information Base (MIB) >> (T) Collections of policy-related managed objects, defined as >> a module and accessed via an SNMP framework. [PolicyMIB] >> This definition is consistent with the PIB one. Other than this new >> technique (T), I do not know of any other new terms that should be defined. >> >Not sure the SNMPCONF talks much about Policy Management Information >Base unless you mean the Policy Module that controls the behavior of the >managed system. We have Implementation, Mechanism, and Instance specific >MIB Modules. All of which could contain 'policy' data. > >If a policy Management Application is tied to SNMP, a PDP and PEP and >COPs are all also specific technology terms and should not be >referenced. Either we equally reference both or we should purge >technology specifics. I do not feel strongly one way or the other. > >> >> > Directory Enabled Networks (DEN) >> >> My issue is not the inclusion or definition. I would like for us to have >> generic terms that are not dependent on the DMTF as well. For example >> what shall we call the general data model that is not LDAP specific? >> >> >> There can only be an "information model" that is not >> protocol/repository-specific - which we describe in PCIM. There >> cannot be a "data model" one. By definition, "data models" are >> repository/protocol specific. The reason that DEN is mentioned is >> that it was designed to use a directory as a policy repository. >> It is directly tied to policy. >> >> >I would feel much more comfortable with the effort if we could include >an example that used a database model as well. > >> Since this is an IETF document, I think we should not only reference >> the work that the document is based on, but the technology over >> which we have change control and will use, perhaps in addition >> to other technologies. >> >> >> Agreed. However, there is also no reason to slight other relevant >> work since our customers hear these terms and could be confused. >> >> >good then we can include some words about databases as well. ... >> >> > Policy Information Base (PIB) >> >> Same comment as before. No issue with definition, we just need to add the >> SNMP counterparts. >> >> >> Policy MIB is added as documented above. >> > >Please see my comments above. ... >> >I have not issue with these except to the extent that people think they >are only realized in LDAP implementations. LDAP can be used to store >policy data as well as relational and other technologies. From majordomo@raleigh.ibm.com Tue Nov 21 05:47:37 2000 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 FAA28616 for ; Tue, 21 Nov 2000 05:47:37 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA28832; Tue, 21 Nov 2000 05:34:43 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA32952; Tue, 21 Nov 2000 05:33:39 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07462; Tue, 21 Nov 2000 05:01:47 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31006; Tue, 21 Nov 2000 05:01:43 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA32166 for ; Tue, 21 Nov 2000 05:01:44 -0500 Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA31292 for ; Tue, 21 Nov 2000 05:01:42 -0500 Received: from mediaone.net (h0001027441c5.ne.mediaone.net [24.128.61.165]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id FAA13236; Tue, 21 Nov 2000 05:01:52 -0500 (EST) Message-Id: <3A1A4809.86B1085@mediaone.net> Date: Tue, 21 Nov 2000 05:01:45 -0500 From: Jon Saperia Organization: JDS Consulting, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Andrea Westerinen Cc: policy@raleigh.ibm.com, snmpconf Subject: Re: Comments on the draft-ietf-policy-terminology-00.txt document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Thanks for all the comments. I look forward to the next draft. /jon From majordomo@raleigh.ibm.com Tue Nov 21 17:34:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17593 for ; Tue, 21 Nov 2000 17:34:05 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA23026; Tue, 21 Nov 2000 17:24:37 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA32666; Tue, 21 Nov 2000 17:24:28 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42914; Tue, 21 Nov 2000 16:57:14 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42904; Tue, 21 Nov 2000 16:57:10 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA35248 for ; Tue, 21 Nov 2000 16:57:15 -0500 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA22998 for ; Tue, 21 Nov 2000 16:57:11 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03303 for ; Tue, 21 Nov 2000 14:57:24 -0700 (MST) Received: from inox.eng.sun.com (inox.Eng.Sun.COM [129.146.85.106]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA19244 for ; Tue, 21 Nov 2000 13:57:19 -0800 (PST) Received: from sun.com (localhost [127.0.0.1]) by inox.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15562 for ; Tue, 21 Nov 2000 13:57:01 -0800 (PST) Message-Id: <3A1AEFAD.41055193@sun.com> Date: Tue, 21 Nov 2000 13:57:01 -0800 From: Jean Christophe Martin X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: policy@raleigh.ibm.com Subject: QoS/IPSEC alignement questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jean Christophe Martin Content-Transfer-Encoding: 7bit I'm trying to understand how the QoS drafts are relating to the IPSEC drafts , and so far, I have little succes. For example : The IPSEC Policy Model is defining : PolicyCondition | SACondition <----FilterofSACondition--->FilterList That should map, for the QoS, into : PolicyCondition | QoSCondition <---FilterofQosCondition-->FilterList The FilterList is a list of FilterEntryBase that can either be QoS specific Filter Entries or plain FilterEntry as defined in CIM network model. However, in draft-ietf-policy-qos-info-model-01.txt, the Condition is using a complete different model. Is there any plan to update the documents : Policy Framework QoS Information Model and QoS Policy Schema to use a model like the IPSEC model that seems closer to the DMTF model ? Thanks JC. From majordomo@raleigh.ibm.com Wed Nov 22 11:54:51 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25677 for ; Wed, 22 Nov 2000 11:54:51 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA17782; Wed, 22 Nov 2000 11:46:22 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA32670; Wed, 22 Nov 2000 11:46:21 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53332; Wed, 22 Nov 2000 11:13:51 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34892; Wed, 22 Nov 2000 11:13:47 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA25234 for ; Wed, 22 Nov 2000 11:13:51 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA17746 for ; Wed, 22 Nov 2000 11:13:46 -0500 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id SAA22490; Wed, 22 Nov 2000 18:13:26 +0200 (IST) Message-Id: <4.3.2.7.2.20001122181156.0340ebe0@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Nov 2000 18:13:33 -0600 To: Jean Christophe Martin , policy@raleigh.ibm.com From: Yoram Ramberg Subject: Re: QoS/IPSEC alignement questions In-Reply-To: <3A1AEFAD.41055193@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg FYI: A new version (-02) of the QoS Policy Information Model is about to be posted (pre-deadline). Not sure about the IPSec drafts. Stay tuned... *Yoram At 01:57 PM 11/21/00 -0800, Jean Christophe Martin wrote: >I'm trying to understand how the QoS drafts are relating to the >IPSEC drafts , and so far, I have little succes. For example : > > >The IPSEC Policy Model is defining : > > PolicyCondition > | > SACondition <----FilterofSACondition--->FilterList > > > >That should map, for the QoS, into : > > PolicyCondition > | > QoSCondition <---FilterofQosCondition-->FilterList > > >The FilterList is a list of FilterEntryBase that can either be >QoS specific Filter Entries or plain FilterEntry as defined in >CIM network model. > >However, in draft-ietf-policy-qos-info-model-01.txt, the Condition >is using a complete different model. > >Is there any plan to update the documents : Policy Framework QoS >Information Model and QoS Policy Schema to use a model like the >IPSEC model that seems closer to the DMTF model ? > >Thanks > >JC. From majordomo@raleigh.ibm.com Thu Nov 23 09:46:08 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08123 for ; Thu, 23 Nov 2000 09:46:08 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA33682; Thu, 23 Nov 2000 09:30:52 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29060; Thu, 23 Nov 2000 09:30:40 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23822; Thu, 23 Nov 2000 09:01:48 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24050; Thu, 23 Nov 2000 09:01:41 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA18496 for ; Thu, 23 Nov 2000 09:01:43 -0500 Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA32738 for ; Thu, 23 Nov 2000 09:01:38 -0500 Received: from localhost (eng70755@localhost) by leonis.nus.edu.sg (8.10.0/8.10.0) with SMTP id eANE1iL04867 for ; Thu, 23 Nov 2000 22:01:45 +0800 (SST) Date: Thu, 23 Nov 2000 22:01:44 +0800 From: Zhang Dawei To: policy@raleigh.ibm.com Subject: schema files Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Zhang Dawei Hi, I was wondering whether there are any downloadable policy core schema files or QoS policy schema files, which are able to be used by OpenLDAP. Thanks, Zhang Dawei From majordomo@raleigh.ibm.com Fri Nov 24 12:56:16 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12049 for ; Fri, 24 Nov 2000 12:56:16 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA32418; Fri, 24 Nov 2000 12:41:14 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA28170; Fri, 24 Nov 2000 12:23:52 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39188; Fri, 24 Nov 2000 11:46:53 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47616; Fri, 24 Nov 2000 11:46:48 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA13104 for ; Fri, 24 Nov 2000 11:46:53 -0500 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA28832 for ; Fri, 24 Nov 2000 11:46:50 -0500 Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eAOGlfE20334 for ; Fri, 24 Nov 2000 17:47:41 +0100 (CET) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA08823 for ; Fri, 24 Nov 2000 17:47:04 +0100 Message-Id: <3A1E9CB5.F5FAD78C@ccrle.nec.de> Date: Fri, 24 Nov 2000 17:52:05 +0100 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Policy Mailing List Subject: new Version of MPLS draft submitted Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit We would like to announce a new version of the MPLS policy draft. "Policy Framework MPLS Information Model for QoS and TE" It is a combination of "Policy Framework QoS Information Model for MPLS" and "Policy Information Model for MPLS Traffic Engineering" Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From majordomo@raleigh.ibm.com Fri Nov 24 13:13:21 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17029 for ; Fri, 24 Nov 2000 13:13:21 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA27492; Fri, 24 Nov 2000 13:02:44 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA37316; Fri, 24 Nov 2000 12:23:52 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40532; Fri, 24 Nov 2000 11:46:04 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54348; Fri, 24 Nov 2000 11:46:01 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA37054 for ; Fri, 24 Nov 2000 11:46:01 -0500 Received: from groucho.doc.ic.ac.uk (IDENT:root@groucho.doc.ic.ac.uk [146.169.14.3]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA06256 for ; Fri, 24 Nov 2000 11:45:54 -0500 Received: from dse-pc-mss.doc.ic.ac.uk (dse-pc-mss.doc.ic.ac.uk [146.169.14.135]) by groucho.doc.ic.ac.uk (8.9.3/8.9.3) with ESMTP id QAA09580; Fri, 24 Nov 2000 16:23:35 GMT Message-Id: <4.3.2.7.2.20001124161232.00bd6400@dse-mail.doc.ic.ac.uk> X-Sender: mss@dse-mail.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Nov 2000 16:22:21 +0000 To: mss@doc.ic.ac.uk From: Morris Sloman Subject: Call for Participation: Policy 2001 Workshop Jan 29-31 2001 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Morris Sloman We apologise if you get duplicate copies of this Policy 2001: Workshop on Policies for Distributed Systems and Networks 29-31 January 2001 Hosted by: HP Laboratories, Bristol, UK Technical Co-sponsored by IEEE ComSoc See: http://www-dse.doc.ic.ac.uk/events/policy-2001/ for programme and registration forms Policy based systems are the subject of a wide range of activities in universities, standardisation bodies and within industry. They have a wide spectrum of applications ranging from quality of service management within networks to security and enterprise modelling. This workshop will provide a forum for discussion and collaboration between researchers, developers and users of policy based systems. It will bring together the various communities working on policy and follows on from the successful informal Policy Workshop held in November 1999 (see http://www-dse.doc.ic.ac.uk/events/policy-99/). Within the Internet community there is considerable interest in Policy Based Networking. A number of companies have announced tools to support the specification and deployment of policies. Much of this work is focused on policies for quality of service management within networks and the Internet Engineering and Distributed Management Task Forces (IETF/DMTF) is actively working on standards related to this area (see http://www-dse.doc.ic.ac.uk/research/policies for links). The Security community has focused on the specification and analysis of access control policy which has evolved into the work on Role-Based Access Control (RBAC). There has been work over a number of years in the academic community on specification and analysis of policies for Distributed Systems mostly concentrating on authorisation policies. Although there are strong similarities in the concepts and techniques used by the different communities there is no commonly accepted terminology or notation for specifying policy. Several research groups are looking at high-level aspects of policy related to Enterprise Modelling. An ISO Open Distributed Processing working group is defining Policy and Role concepts within the Enterprise Viewpoint. Enterprise goals or Service Level Agreements can be considered as high-level abstract policies which must be progressively refined into implementable policies. The work on the specification and analysis of Business Rules is also relevant. The common concept of policy, within all of the above communities, is that polices define a set of rules governing choices in the behaviour of the system. The motivation is to be able to modify policy in order to change system behaviour without having to re-implement the system, or restructure the requirements specification. __________________________________________________ Professor Morris Sloman Imperial College of Science Technology and Medicine Department of Computing 180 Queen's Gate London SW7 2BZ, U.K. Phone: +44 20 7594 8279 Fax: +44 20 7581 8024 Email: m.sloman@doc.ic.ac.uk WWW: http://www-dse.doc.ic.ac.uk/~mss Policy 2001: Workshop on Policies for Distributed Systems and Networks, HP Laboratories, Bristol, 29-31 Jan. 2001 http://www-dse.doc.ic.ac.uk/Events/policy-2001/ From majordomo@raleigh.ibm.com Sun Nov 26 18:01:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18108 for ; Sun, 26 Nov 2000 18:01:36 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA07512; Sun, 26 Nov 2000 17:52:35 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA25740; Sun, 26 Nov 2000 17:52:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60958; Sun, 26 Nov 2000 17:25:39 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23816; Sun, 26 Nov 2000 17:25:35 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA25814 for ; Sun, 26 Nov 2000 17:25:41 -0500 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA24920 for ; Sun, 26 Nov 2000 17:25:37 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA00149 for ; Sun, 26 Nov 2000 17:25:56 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA00124 for ; Sun, 26 Nov 2000 17:25:56 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Nov 2000 23:25:50 +0100 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0A3A25CE@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Policy Mailing List Subject: RE: Protocol Action: Policy Core Information Model - Version 1 S pecification to Proposed Standard Date: Sun, 26 Nov 2000 23:25:44 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Good to see we finally have an approved PS. Thanks to the WG at large, and specifically to the Authors/Editors. Now up to the next milestone. Bert > ---------- > From: The IESG[SMTP:iesg-secretary@ietf.org] > Sent: Friday, November 24, 2000 11:11 PM > Cc: RFC Editor; Internet Architecture Board; policy@RALEIGH.IBM.COM > Subject: Protocol Action: Policy Core Information Model - Version 1 > Specification to Proposed Standard > > > > The IESG has approved the Internet-Draft 'Policy Core Information > Model - Version 1 Specification' > as a Proposed Standard. > This document is the product of the Policy Framework Working Group. > The IESG contact persons are Bert Wijnen and Randy Bush. > > > Technical Summary > > This document presents the object-oriented information model for > representing policy information developed jointly in the IETF Policy > Framework WG and as extensions to the Common Information Model (CIM) > activity in the Distributed Management Task Force (DMTF). This model > defines two hierarchies of object classes: structural classes > representing policy information and control of policies, and > association > classes that indicate how instances of the structural classes are > related > to each other. Subsequent documents will define mappings of this > information model to various concrete implementations, for example, to > a > directory that uses LDAPv3 as its access protocol. The components of > the > CIM schema are available via the following URL: > http://www.dmtf.org/spec/cims.html [1]. > > > Working Group Summary > > This document took quite some time and quite some discussion in the > Policy Framework WG. However, at the end, rough consensus was reached > on this specification. The security section got composed with the help > of > security advisors from the Securty Area. > > Protocol Quality > > This document has been reviewed for the IESG by Harald Alvestrand and > Bert Wijnen. > From majordomo@raleigh.ibm.com Mon Nov 27 11:38:02 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05846 for ; Mon, 27 Nov 2000 11:38:02 -0500 (EST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA16340; Mon, 27 Nov 2000 11:27:20 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA07474; Mon, 27 Nov 2000 11:27:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31884; Mon, 27 Nov 2000 10:47:29 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38788; Mon, 27 Nov 2000 10:47:25 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA30208 for ; Mon, 27 Nov 2000 10:47:26 -0500 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22014 for ; Mon, 27 Nov 2000 10:47:23 -0500 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eARFlBa01316; Mon, 27 Nov 2000 10:47:11 -0500 (EST) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id KAA00481; Mon, 27 Nov 2000 10:47:11 -0500 (EST) Message-Id: <200011271547.KAA00481@monday.research.telcordia.com> Date: Mon, 27 Nov 2000 10:47:11 -0500 (EST) From: Ritu Chadha Subject: new Version of MPLS draft submitted To: policy@raleigh.ibm.com Cc: mpls@uu.net, chadha@mailee.research.telcordia.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: qXgnriX+kboVtFcC3kwM0w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha The draft below is currently available via anonymous ftp from ftp.research.telcordia.com at /pub/world/chadha/draft-chadha-policy-mpls-te-01.txt Ritu ------------- Begin Forwarded Message ------------- Date: Fri, 24 Nov 2000 17:52:05 +0100 From: Marcus Brunner X-Accept-Language: en,de Mime-Version: 1.0 To: Policy Mailing List Subject: new Version of MPLS draft submitted Content-Transfer-Encoding: 7bit We would like to announce a new version of the MPLS policy draft. "Policy Framework MPLS Information Model for QoS and TE" It is a combination of "Policy Framework QoS Information Model for MPLS" and "Policy Information Model for MPLS Traffic Engineering" Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 ------------- End Forwarded Message ------------- ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Mon Nov 27 13:16:21 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11921 for ; Mon, 27 Nov 2000 13:16:21 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA21806; Mon, 27 Nov 2000 13:05:27 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA28376; Mon, 27 Nov 2000 13:05:24 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32140; Mon, 27 Nov 2000 12:40:11 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32100; Mon, 27 Nov 2000 12:40:05 -0500 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 MAA30122 for ; Mon, 27 Nov 2000 12:40:07 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id MAA35980 for ; Mon, 27 Nov 2000 12:40:05 -0500 Importance: Normal Subject: PCLS, QDDIM updates available To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 27 Nov 2000 12:44:06 -0500 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 11/27/2000 12:40:23 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" While they're working their way up the Internet-Drafts queue, the two documents I updated last week are available at the usual alternate site: PCLS: ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/ draft-ietf-policy-core-schema-08.txt QDDIM: ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/ draft-ietf-policy-qos-device-info-model-02.txt Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Wed Nov 29 11:05:26 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20048 for ; Wed, 29 Nov 2000 11:05:25 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22146; Wed, 29 Nov 2000 10:56:24 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA31862; Wed, 29 Nov 2000 10:56:16 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26174; Wed, 29 Nov 2000 10:19:01 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43574; Wed, 29 Nov 2000 10:18:58 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA21270 for ; Wed, 29 Nov 2000 10:19:03 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA28034 for ; Wed, 29 Nov 2000 10:18:53 -0500 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id RAA04133 for ; Wed, 29 Nov 2000 17:18:44 +0200 (IST) Message-Id: <4.3.2.7.2.20001129171501.00cf4190@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Nov 2000 17:18:54 -0600 To: policy@raleigh.ibm.com From: Yoram Ramberg Subject: new version of QPIM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg A new (-02) version of the QoS Policy Information Model draft has been sent to the IETF for posting. You can get a copy via ftp: ftp ftpeng.cisco.com. user: anonymous cd ietf-policy-wg (under login dir) get draft-ietf-policy-qos-info-model-02.txt Enjoy! *Yoram From majordomo@raleigh.ibm.com Wed Nov 29 20:15:11 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01114 for ; Wed, 29 Nov 2000 20:15:11 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA21798; Wed, 29 Nov 2000 20:04:13 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA15540; Wed, 29 Nov 2000 20:04:10 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45370; Wed, 29 Nov 2000 16:26:41 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41258; Wed, 29 Nov 2000 16:26:36 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA28500 for ; Wed, 29 Nov 2000 16:26:41 -0500 Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA29088 for ; Wed, 29 Nov 2000 16:11:15 -0500 Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id QAA29519; Wed, 29 Nov 2000 16:11:34 -0500 (EST) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 29 Nov 2000 21:11:34 UT Received: from mears.indy.cr.irs.gov (mailhub-2.net.treas.gov [10.7.8.10]) by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id QAA10085; Wed, 29 Nov 2000 16:10:50 -0500 (EST) Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id QAA00372; Wed, 29 Nov 2000 16:10:45 -0500 Message-Id: <3A2570D6.8D7F7857@parnelli.indy.cr.irs.gov> Date: Wed, 29 Nov 2000 16:10:46 -0500 From: "Larry S. Bartz" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy WG LIST Cc: "LIST, DEN discussion" , chair-ldap@dmtf.org, cim-support@dmtf.org, chair-network@dmtf.org, chair-den@dmtf.org Subject: CIM24 schema tweaks Content-Type: multipart/mixed; boundary="------------B13ECC9BA2BB1600F2004B2B" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" This is a multi-part message in MIME format. --------------B13ECC9BA2BB1600F2004B2B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have encountered some difficulties implementing the CIM v2.4 schema, as described in the DSP0117 documents at http://www.dmtf.org/spec/denh.html --------------B13ECC9BA2BB1600F2004B2B-- From majordomo@raleigh.ibm.com Thu Nov 30 04:56:12 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07067 for ; Thu, 30 Nov 2000 04:56:12 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA28322; Thu, 30 Nov 2000 04:46:14 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA37090; Thu, 30 Nov 2000 04:45:54 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35136; Thu, 30 Nov 2000 04:04:36 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49398; Thu, 30 Nov 2000 04:04:27 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA26614 for ; Thu, 30 Nov 2000 04:04:33 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA26702 for ; Thu, 30 Nov 2000 04:04:24 -0500 Received: from ysnirnt70 (telaviv1-dhcp43.cisco.com [144.254.90.171]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with SMTP id LAA28048; Thu, 30 Nov 2000 11:04:15 +0200 (IST) From: "Yoram Snir" To: "'Policy Mailing List' \(E-mail\)" Cc: "Yoram Ramberg \(E-mail\)" , "Ron Cohen \(E-mail\)" , "John Strassner \(E-mail\)" Subject: QoS Policy Information Model draft Date: Thu, 30 Nov 2000 11:02:11 +0200 Message-Id: <001c01c05aac$3ae14350$ab5afe90@ysnirnt70> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit All A new (-02) version of the QoS Policy Information Model draft (draft-ietf-policy-qos-info-model-02.txt) is available. We tried to answer all the concerns and comments we received on the previous version of the draft. It includes the following changes from the previous version: 1. Some of the classes defined in QPIM are intended for usage outside the scope of QoS domain. The concept of conditions as building blocks of filters, the basic condition structure of , the concept of variable binding and the concept of variable to value relationship are valuable to domains out side QoS policy. In order to allow more natural usage of these concept in other domains, the relevant classes prefix was changed from qosPolicyXXX to gpsPolicyXXX and properties prefix was changed from qpPolicyXXX to gpPolicy ,i.e., general policy XXX. 2. The notion of a class representing a filter or a Boolean expression made of policy conditions, that could also serve as a reusable filter was added. The class gpsPolicyCompoundCondition allows the definition of a flexible reusable filter, leveraging the mechanism defined in CPIM for associating policy conditions to a policy rule . 3. This draft was updated to be compatible with the latest PCIM draft. 4. PHB Actions added to allow full coverage of the QoS policy model required for definition of policies for a differential service domain. References to external PHB definitions removed. 5. Alignment between policy definition of QPIM and low level PIB / MIB Was illustrated. 6. Reuse of Policy groups and their QPIM extensions, gpsPolicyGroups and Policy rules were explained and examples were added. 7. Role usage in the context of QoS policy was explained. No new concepts were introduced. Role were also defined per gpsPolicyGroups. 8. Change gpsPolicyMeter to include a traffic profile and scope. The previous way of binding the meter the traffic profile and a scope using a provisioning action could lead to inconsistencies if not used properly. 9. Clarification of the use of gpValueTypes property of values and the meaning of table 3. 10. Rewriting the draft in a storage independent way. The previous draft was not general enough. Added appropriate association and aggregations and removed references from objects. Changed text appropriately. 11. qpsNamedPolicyContainer class name was changes to gpsPolicyGroup to allow for usage outside the scope of QoS domain. The draft is available in via ftp (util the ietf repository updates): ftp ftpeng.cisco.com. user: anonymous cd ietf-policy-wg (under login dir) get draft-ietf-policy-qos-info-model-02.txt Enjoy Yoram Snir From majordomo@raleigh.ibm.com Thu Nov 30 08:51:38 2000 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 IAA10247 for ; Thu, 30 Nov 2000 08:51:34 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA35062; Thu, 30 Nov 2000 08:18:05 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA33506; Thu, 30 Nov 2000 08:10:52 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51424; Thu, 30 Nov 2000 07:44:08 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42708; Thu, 30 Nov 2000 07:44:03 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA40048 for ; Thu, 30 Nov 2000 07:44:07 -0500 Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA30734 for ; Thu, 30 Nov 2000 07:44:03 -0500 Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay2.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id HAA04167; Thu, 30 Nov 2000 07:42:06 -0500 (EST) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 30 Nov 2000 12:42:06 UT Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11]) by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id HAA15160; Thu, 30 Nov 2000 07:40:17 -0500 (EST) Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id HAA01727; Thu, 30 Nov 2000 07:42:01 -0500 Message-Id: <3A264B19.C13E835@parnelli.indy.cr.irs.gov> Date: Thu, 30 Nov 2000 07:42:01 -0500 From: "Larry S. Bartz" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy WG LIST Cc: "LIST, DEN discussion" , chair-den@dmtf.org, chair-ldap@dmtf.org, chair-network@dmtf.org, cim-support@dmtf.org Subject: CIM24 schema tweaks Content-Type: multipart/mixed; boundary="------------EE8FAB113B66D730A66B2A7F" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" This is a multi-part message in MIME format. --------------EE8FAB113B66D730A66B2A7F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My previous message on this subject was mishandled by my mailer, resulting in severe truncation. Here's a retry: I have encountered some difficulties implementing the CIM v2.4 schema, as described in the DSP0117 documents at http://www.dmtf.org/spec/denh.html . Since the IETF Policy WG's draft-ietf-policy-core-schema-08.txt depends upon the cim24 schema, experimental implementers of "schema-08" may find the following comments and attached edited ABNF helpful. I am also sharing these comments with the DMTF's WG chairs and CIM support e-mail addresses. I request that these comments be forwarded to the appropriate individuals for review. - DESC - Some Directory products enforce a length limit on the DESC terms of objectclass and attributeType descriptions. X.501 defines the limit as {ub-schema}. Annex C of X.520 defines {ub-schema} as 1024. DESC term values which exceed 1024 characters violate this limit. Several of the descriptions in DSP0117 contain DESC term values which exceed 1024 characters in length. - Matching Rules - Many of the attribute descriptions in DSP0117 have no matching rule terms specified. The attachment nominates matching rule terms where appropriate, with comments designated by #LSB. - Unspecified Attributes - Several attribute types are nominated by objectClass descriptions but which have not been defined. These include three whose names begin with "dlmHelperRefTo...". Based on a presumption that other previously-defined attributes were intended, the attachment substitutes defined attribute names for those which are not defined, with comments designated by #LSB. - Forward references precluded - The attachment relocates entries in the file to avoid forward references. -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| --------------EE8FAB113B66D730A66B2A7F Content-Type: text/plain; charset=us-ascii; name="tweakedCIM24schema.txt" Content-Disposition: inline; filename="tweakedCIM24schema.txt" Content-Transfer-Encoding: 7bit #LSB ########################################################################## #LSB #LSB 20001129 - Larry S. Bartz - Internal Revenue Service - Indianapolis, IN #LSB #LSB This document extracted from DMTF Specification DSP0117, then modified #LSB somewhat. See the complete specification at http://www.dmtf.org/ #LSB #LSB This document is suitable for use as a schema definition by OpenLDAP 2.0.x. #LSB #LSB Format of this document, lines with leading: #LSB #LSB #LSB = comments added by me, LSB #LSB ## = commented text from DSP0117 #LSB # = comment-out ABNF from DSP0117 #LSB #LSB CHANGES: #LSB #LSB - Some Directory products do not support explicit descriptions of nameForm, #LSB ditContentRule, and ditStructureRule. The ABNF for these are commented-out. #LSB #LSB - DESC - Some Directory products enforce a length limit on the DESC terms #LSB of objectclass and attributeType descriptions. X.501 defines the limit #LSB as ub-schema. Annex C of X.520 defines ub-schema as 1024. DESC term #LSB values which exceed 1024 characters violate this limit. Several of the #LSB descriptions in DSP0117 contain DESC term values which exceed 1024 #LSB characters in length. This document comments-out all DESC terms as an #LSB expedient remedy. #LSB #LSB - Matching Rules - Many of the attribute descriptions in DSP0117 have no #LSB matching rule terms specified. This document nominates matching rule terms #LSB where appropriate, with comments designated by #LSB. #LSB #LSB - Unspecified Attributes - Several attribute types are nominated by #LSB objectClass descriptions but which have not been defined. These include #LSB three whose names begin with "dlmHelperRefTo...". Based on a presumption #LSB that other previously-defined attributes were intended, this document #LSB substitutes defined attribute names for those which are not defined, #LSB with comments designated by #LSB. #LSB #LSB - ABNF format #LSB - Put NAME term and value on its own line for readability. #LSB - Since OpenLDAP doesn't parse ABNF with embedded comments, #LSB commented lines which might otherwise be embedded within #LSB the ABNF are listed immediately following the ABNF. #LSB #LSB - Forward references precluded - relocated entries in the file to preclude #LSB forward references. #LSB #LSB - "objectclass" and "attributetype" identifiers prepended to ABNF stanzas #LSB to enhance readability and to enable this document to serve as a valid #LSB schema definition for OpenLDAP 2.0.x. #LSB #LSB ########################################################################## ## ## Copyright (c) "2000" Distributed Management Task Force, Inc. (DMTF). ## All rights reserved. ## ## DMTF is a not-for-profit association of industry members dedicated to ## promoting enterprise and systems management and interoperability. DMTF ## specifications and documents may be reproduced for uses consistent with ## this purpose by members and non-members, if correct attribution is given. ## As DMTF specifications may be revised from time to time, the particular ## version and release cited should always be noted. ## ## DMTF LDAP Schema for the CIM v2.4 Core Information Model v1.0 ## ## November 22, 2000 ## ## Abstract ## This document presents an LDAP schema for the ## CIM version 2.4 Core Information Model ## #LSB ########################################################################## ## ## 2.3 Helper Classes ## 2.3.1 dlmOtherIdentifyingInfoInstance ## CIM defines the concept of an ordered array, which LDAP does not support. In the core ## CIM model, indexed arrays are only used in two abstract classes (CIM_ComputerSystem ## and CIM_LogicalDevice) to tie the values of two property arrays together. In the LDAP ## mapping, these properties are replaced with separate instances of ## dlmOtherIdentifyingInfoInstance that each contain a single pair of attribute values and ## are DIT contained by the parent class. The attribute dlmOtherIdentifyingInfo is defined ## in Section 3.3 and reused here and the attribute arrayIndex is defined as the RDN for this ## class. Finally, the structure rule is provided as a template to be filled in with structure ## rule pointers to structural rules defined for concrete sub-classes of dlm1ComputerSystem ## and dlm1LogicalDevice. attributetype ( 1.3.6.1.4.1.412.100.1.2.5 NAME 'arrayIndex' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch ) # DESC 'the index of this child' attributetype ( 1.3.6.1.4.1.412.100.2.2.101 NAME 'dlmIdentifyingDescription' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # DESC 'A free-form string providing explanation and # details behind the entries in the dlmOtherIdentifyingInfo # attribute.' #LSB - added matching rules #LSB - Relocated following attribute from its numerical sequence location in #LSB the file, in order to preclude an annoying forward reference. #LSB attributetype ( 1.3.6.1.4.1.412.100.2.2.112 NAME 'dlmOtherIdentifyingInfo' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # DESC 'OtherIdentifyingInfo captures additional data, # beyond asset tag information, that could be used to # identify a Physical Element. One example is bar code # data associated with an Element that also has an asset # tag. Note that if only bar code data is available and # is unique/able to be used as an Element key, this # property would be NULL and the bar code data used as # the class key, in the Tag property.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.92 NAME 'dlmOtherIdentifyingInfoInstance' SUP top MUST ( arrayIndex ) MAY ( dlmOtherIdentifyingInfo $ dlmIdentifyingDescription ) ) # DESC 'helper class to tie indexed arrays in core model together' # ( 1.3.6.1.4.1.412.100.2.3.3.9 # NAME 'dlmOtherIdentifyingInfoInstanceNameForm' # OC dlmOtherIdentifyingInfoInstance # MUST ( arrayIndex ) # ) # ( # NAME 'dlmOtherIdentifyingInfoInstanceStructureRule' # FORM dlmOtherIdentifyingInfoInstanceNameForm # ) ## 2.4 Naming considerations ## To support naming in the LDAP mapping of the core schema, the attribute ## orderedCimKeys is defined, to provide the RDN for directory implementations. attributetype ( 1.3.6.1.4.1.412.100.1.2.1 NAME 'orderedCimKeys' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE EQUALITY octetStringMatch ) # DESC 'The model path for the instance (without propagated # keys). May be used as an RDN' ## The value of this attribute is constructed by ordering the CIM keys [formatted as ## ".=[,=]*"] of the object in the US-ASCII ## collation order of the property names. For an instance with propagated keys in the CIM ## namespace, the value of this attribute takes one of two forms: either it includes all of the ## instance's keys, or it includes only the non-propagated ones. Ordinarily the propagated ## keys will be included when the DIT hierarchy in which an instance appears does not ## reflect the CIM naming hierarchy represented by the propagation of keys via weak ## associations. When the DIT hierarchy does mirror the CIM naming hierarchy, the ## propagated keys are unnecessary and may be omitted. By consulting the CIM schema, a ## directory client can tell whether propagated keys may have been included. ## In a previous version of this specification, the value of orderedCimKeys never included ## propagated keys. A second attribute, orderedCimModelPath, was used when propagated ## keys were required. Now that orderedCimKeys includes the case where propagated keys ## are included, orderedCimModelPath can be marked as "obsolete". attributetype ( 1.3.6.1.4.1.412.100.1.2.2 NAME 'orderedCimModelPath' OBSOLETE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE EQUALITY octetStringMatch ) # DESC 'The model path for the instance (with propagated keys). May # be used as an RDN' ## 3.1 ManagedElement ## This abstract class provides a base for non-association classes in CIM. Its addition is one ## of the major changes between CIM v2.2 and CIM v2.3. attributetype ( 1.3.6.1.4.1.412.100.2.2.103 NAME 'dlmCaption' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The Caption property is a short textual # description (oneline string) of the object.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.104 NAME 'dlmDescription' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # DESC 'The Description property provides a textual # description of the object.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.1 NAME 'dlm1ManagedElement' SUP top ABSTRACT MAY ( dlmCaption $ dlmDescription $ orderedCimModelPath $ orderedCimKeys ) ) # DESC 'ManagedElement is an abstract class that provides # a common superclass (or top of the inheritance tree) # for the non-association classes in the CIM Schema.' ## 3.2 ManagedSystemElement ## This is the base class for the system element hierarchy. Any distinguishable component ## of a system is a candidate for inclusion in this class. Examples of this are software ## components, such as files and devices, such as disk drives and controllers, and physical ## components such as chips and cards. attributetype ( 1.3.6.1.4.1.412.100.2.2.105 NAME 'dlmInstallDate' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) # DESC 'A datetime value indicating when the object was # installed. A lack of a value does not indicate that # the object is not installed.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.106 NAME 'dlmName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The Name property defines the label by which the # object is known. When subclassed, the Name property # can be overridden to be a Key property.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.107 NAME 'dlmStatus' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{10} SINGLE-VALUE ) # DESC 'A string indicating the current status of the # object. Various operational and non-operational # statuses are defined. Operational statuses are "OK", # "Degraded", "Stressed" and "Pred Fail". "Stressed" # indicates that the Element is functioning, but needs # attention. Examples of "Stressed" states are overload, # overheated, etc. The condition "Pred Fail" (failure # predicted) indicates that an Element is functioning # properly but predicting a failure in the near future. # An example is a SMART-enabled hard drive. # Non-operational statuses can also be specified. These # are "Error", "NonRecover", "Starting", "Stopping", # "Service", "No Contact" and "Lost Comm". "NonRecover" # indicates that a non-recoverable error has occurred. # "Service" describes an Element being configured, # maintained, cleaned, or otherwise administered. This # status could apply during mirror-resilvering of a # disk, reload of a user permissions list, or other # administrative task. Not all such work is on-line, yet # the Element is neither "OK" nor in one of the other # states. "No Contact" indicates that the current # instance of the monitoring system has knowledge of # this Element but has never been able to establish # communications with it. "Lost Comm" indicates that the # ManagedSystemElement is known to exist and has been # contacted successfully in the past, but is currently # unreachable. Value Mappings are "OK", "Error", # "Degraded", "Unknown", "Pred Fail", "Starting", # "Stopping", "Service", "Stressed", "NonRecover", "No # Contact", "Lost Comm"' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.2 NAME 'dlm1ManagedSystemElement' SUP dlm1ManagedElement ABSTRACT MAY ( dlmInstallDate $ dlmName $ dlmStatus ) ) # DESC 'ManagedSystemElement is the base class for the # System Element hierarchy. Membership Criteria: Any # distinguishable component of a System is a candidate # for inclusion in this class. Examples: software # components, such as files; and devices, such as disk # drives and controllers, and physical components such # as chips and cards.' ## 3.3 PhysicalElement ## This class acts as the base class for any component of a system that has a distinct physical ## identity. Instances of this class can be defined in terms of labels that can be physically ## attached to the object. All processes, files, and logical devices are considered not to be ## physical elements. For example, it is not possible to attach a label to a modem. It is only ## possible to attach a label to the card that implements the modem. The same card could ## also implement a LAN adapter. This is an example of a single physical element (the card) ## hosting more than one logical device. attributetype ( 1.3.6.1.4.1.412.100.2.2.108 NAME 'dlmCreationClassName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'CreationClassName indicates the name of the class # or the subclass used in the creation of an instance. # When used with the other key properties of this class, # this property allows all instances of this class and # its subclasses to be uniquely identified.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.109 NAME 'dlmManufactureDate' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) # DESC 'Date that this PhysicalElement was manufactured.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.110 NAME 'dlmManufacturer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The name of the organization responsible for # producing the PhysicalElement. This may be the entity # from whom the Element is purchased, but this is not # necessarily true. The latter information is contained # in the Vendor property of Product.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.111 NAME 'dlmModel' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The name by which the PhysicalElement is # generally known.' #LSB - added matching rules #LSB - Relocated 1.3.6.1.4.1.412.100.2.2.112 from its numerical sequence #LSB location in the file, in order to preclude an annoying forward reference. attributetype ( 1.3.6.1.4.1.412.100.2.2.113 NAME 'dlmPartNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The part number assigned by the organization # responsible for producing or manufacturing the # PhysicalElement.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.114 NAME 'dlmPoweredOn' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'Boolean indicating that the PhysicalElement is # powered on (TRUE), or is currently off (FALSE).' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.115 NAME 'dlmSKU' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The stock keeping unit number for this # PhysicalElement.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.116 NAME 'dlmSerialNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'A manufacturer-allocated number used to identify # the Physical Element.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.117 NAME 'dlmTag' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'An arbitrary string that uniquely identifies the # Physical Element and serves as the Element"s key. The # Tag property can contain information such as asset tag # or serial number data. The key for PhysicalElement is # placed very high in the object hierarchy in order to # independently identify the hardware/entity, regardless # of physical placement in or on Cabinets, Adapters, etc. # For example, a hotswappable or removeable component # may be taken from its containing (scoping) Package and # be temporarily unused. The object still continues to # exist - and may even be inserted into a different # scoping container. Therefore, the key for Physical # Element is an arbitrary string and is defined # independently of any placement or location-oriented # hierarchy.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.118 NAME 'dlmVersion' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'A string indicating the version of the # PhysicalElement.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.3 NAME 'dlm1PhysicalElement' SUP dlm1ManagedSystemElement ABSTRACT MAY ( dlmCreationClassName $ dlmManufactureDate $ dlmManufacturer $ dlmModel $ dlmOtherIdentifyingInfo $ dlmPartNumber $ dlmPoweredOn $ dlmSKU $ dlmSerialNumber $ dlmTag $ dlmVersion ) ) # DESC 'Subclasses of PhysicalElement define any # component of a System that has a distinct physical # identity. Instances of this class can be defined in # terms of labels that can be physically attached to the # object. All Processes, Files, and LogicalDevices are # considered not to be Physical Elements. For example, # it is not possible to attach a label to a modem. It is # only possible to attach a label to the card that # implements the modem. The same card could also # implement a LAN adapter. These are tangible Managed # System Elements (usually actual hardware items) that # have a physical manifestation of some sort. A Managed # System Element is not necessarily a discrete # component. For example, it is possible for a single # Card (which is a type of Physical Element) to host # more than one Logical Device. The card would be # represented by a single Physical Element associated # with multiple Logical Devices.' ## 3.4 LogicalElement ## This class is the base class for all the components of a system that represent abstract ## system components, such as files, processes, or system capabilities as logical devices. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.4 NAME 'dlm1LogicalElement' SUP dlm1ManagedSystemElement ABSTRACT ) # DESC 'LogicalElement is a base class for all the # components of a System that represent abstract system # components, such as Files, Processes, or system # capabilities in the form of Logical Devices.' ## 3.5 System ## This class is a logical element that aggregates an enumerable set of managed system ## elements and operates as a functional whole. Within any particular subclass of system, ## there is a well-defined list of managed system element classes whose instances must be ## aggregated. attributetype ( 1.3.6.1.4.1.412.100.2.2.119 NAME 'dlmNameFormat' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The System object and its derivatives are Top # Level Objects of CIM. They provide the scope for # numerous components. Having unique System keys is # required. A heuristic can be defined in individual # System subclasses to attempt to always generate the # same System Name Key. The NameFormat property # identifies how the System name was generated, using # the subclass" heuristic.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.120 NAME 'dlmPrimaryOwnerContact' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'A string that provides information on how the # primary system owner can be reached (e.g. phone # number, email address, ...).' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.121 NAME 'dlmPrimaryOwnerName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The name of the primary system owner.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.122 NAME 'dlmRoles' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseExactMatch ) # DESC 'An array (bag) of strings that specify the roles # this System plays in the IT-environment. Subclasses of # System may override this property to define explicit # Roles values. Alternately, a Working Group may # describe the heuristics, conventions and guidelines # for specifying Roles. For example, for an instance of # a networking system, the Roles property might contain # the string, "Switch" or "Bridge".' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.5 NAME 'dlm1System' SUP dlm1LogicalElement ABSTRACT MAY ( dlmCreationClassName $ dlmName $ dlmNameFormat $ dlmPrimaryOwnerContact $ dlmPrimaryOwnerName $ dlmRoles ) ) # DESC 'A System is a LogicalElement that aggregates an # enumerable set of Managed System Elements. The # aggregation operates as a functional whole. Within any # particular subclass of System, there is a well-defined # list of Managed System Element classes whose instances # must be aggregated.' ## 3.6 ComputerSystem ## This class is derived from System and represents a special collection of managed system ## elements that provide compute capabilities. Thus, it serves as aggregation point to ## associate one or more of the following elements: file systems, operating systems, ## processors and memory (volatile and/or non-volatile storage). attributetype ( 1.3.6.1.4.1.412.100.2.2.123 NAME 'dlmDedicated' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch ) # DESC 'Enumeration indicating whether the ComputerSystem # is a special-purpose System (ie, dedicated to a # particular use), versus being "general purpose". For # example, one could specify that the System is # dedicated to "Print" (value=11) or acts as a "Hub" # (value=8). Values are 0="Not Dedicated", # 1="Unknown", 2="Other", 3="Storage", 4="Router", # 5="Switch", 6="Layer 3 Switch", 7="Central Office # Switch", 8="Hub", 9="Access Server", 10="Firewall", # 11="Print", 12="I/O", 13="Web Caching", # 14="Management"' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.6 NAME 'dlm1ComputerSystem' SUP dlm1System ABSTRACT MAY ( dlmDedicated $ dlmNameFormat ) ) #LSB - original has a superfluous right paren in the last line of the stanza # ) ) # DESC 'A class derived from System that is a special # collection of ManagedSystemElements. This collection # provides compute capabilities and serves as # aggregation point to associate one or more of the # following elements: FileSystem, OperatingSystem, # Processor and Memory (Volatile and/or NonVolatile # Storage).' ## 3.7 AdminDomain ## This abstract class represents a special grouping of MSEs that are all administered by the ## same user or group of users. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.93 NAME 'dlm1AdminDomain' SUP dlm1System ABSTRACT ) # DESC 'This is a special grouping of ManagedSystemElements that # are all administered by the same user or group of users. # It serves as an aggregation point to associate one or more # of the following elements: network devices, such as # routers and switches, servers, and other resources that # can be accessed by end systems. This grouping of devices # plays an essential role in ensuring that the same # administrative POLICY is applied to all of the devices # in the grouping.' ## 3.8 LogicalDevice ## This class represents an abstraction or emulation of a hardware entity that may or may ## not be realized in physical hardware. Any characteristics of a logical device that are used ## to manage its operation or configuration are contained in, or associated with, this object. attributetype ( 1.3.6.1.4.1.412.100.2.2.124 NAME 'dlmAdditionalAvailability' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch ) # DESC 'Additional availability and status of the Device, # beyond that specified in the Availability property. The # Availability property denotes the primary status and # availability of the Device. In some cases, this will # not be sufficient to denote the complete status of the # Device. In those cases, the AdditionalAvailability # property can be used to provide further information. # For example, a Device"s primary Availability may be # "Off line" (value=8), but it may also be in a low # power state (AdditonalAvailability value=14), or the # Device could be running Diagnostics (Additional # Availability value=5, "In Test"). Values are # 1="Other", 2="Unknown", 3="Running/Full Power", # 4="Warning", 5="In Test", 6="Not Applicable", 7="Power # Off", 8="Off Line", 9="Off Duty", 10="Degraded", # 11="Not Installed", 12="Install Error", 13="Power Save # - Unknown", 14="Power Save - Low Power Mode", 15="Power # Save - Standby", 16="Power Cycle", 17="Power Save - # Warning", 18="Paused", 19="Not Ready", 20="Not # Configured", 21="Quiesced"' attributetype ( 1.3.6.1.4.1.412.100.2.2.125 NAME 'dlmAvailability' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'The primary availability and status of the # Device. (Additional status information can be # specified using the AdditionalAvailability array # property.) For example, the Availability property # indicates that the Device is running and has full # power (value=3), or is in a warning (4), test (5), # degraded (10) or power save state (values 13-15 and # 17). Regarding the Power Save states, these are # defined as follows: Value 13 ("Power Save - Unknown\ # Values are 1="Other", 2="Unknown", 3="Running/Full # Power", 4="Warning", 5="In Test", 6="Not Applicable", # 7="Power Off", 8="Off Line", 9="Off Duty", # 10="Degraded", 11="Not Installed", 12="Install Error", # 13="Power Save - Unknown", 14="Power Save - Low Power # Mode", 15="Power Save - Standby", 16="Power Cycle", # 17="Power Save - Warning", 18="Paused", 19="Not # Ready", 20="Not Configured", 21="Quiesced"' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.126 NAME 'dlmDeviceID' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'An address or other identifying information to # uniquely name the LogicalDevice.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.127 NAME 'dlmErrorCleared' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'ErrorCleared is a boolean property indicating # that the error reported in LastErrorCode is now # cleared.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.128 NAME 'dlmErrorDescription' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # DESC 'ErrorDescription is a free-form string supplying # more information about the error recorded in # LastErrorCode, and information on any corrective # actions that may be taken.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.129 NAME 'dlmLastErrorCode' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'LastErrorCode captures the last error code # reported by the LogicalDevice.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.130 NAME 'dlmMaxQuiesceTime' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'Maximum time in milliseconds, that a Device can # run in a "Quiesced" state. A Device"s state is defined # in its Availability and Additional Availability # properties, where "Quiesced" is conveyed by the value # 21. What occurs at the end of the time limit is # device-specific. The Device may unquiesce, may offline # or take other action. A value of 0 indicates that a # Device can remain quiesced indefinitely. The value is # considered to be MilliSeconds.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.131 NAME 'dlmPowerManagementCapabilities' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY integerMatch ) # DESC 'Indicates the specific power-related capabilities # of a LogicalDevice. The array values, 0="Unknown", # 1="Not Supported" and 2="Disabled" are # self-explanatory. The value, 3="Enabled" indicates # that the power management features are currently # enabled but the exact feature set is unknown or the # information is unavailable. "Power Saving Modes # Entered Automatically" (4) describes that a Device can # change its power state based on usage or other # criteria. "Power State Settable" (5) indicates that # the SetPowerState method is supported. "Power Cycling # Supported" (6) indicates that the SetPowerState method # can be invoked with the PowerState input variable set # to 5 ("Power Cycle"). "Timed Power On Supported" (7) # indicates that the SetPowerState method can be invoked # with the Power State input variable set to 5 ("Power # Cycle") Values are 0="Unknown", 1="Not Supported", # 2="Disabled", 3="Enabled", 4="Power Saving Modes # Entered Automatically", 5="Power State Settable", # 6="Power Cycling Supported", 7="Timed Power On # Supported"' attributetype ( 1.3.6.1.4.1.412.100.2.2.132 NAME 'dlmPowerManagementSupported' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'Boolean indicating that the Device can be power # managed - ie, put into a power save state. This # boolean does not indicate that power management # features are currently enabled, or if enabled, what # features are supported. Refer to the # PowerManagementCapabilities array for this # information. If this boolean is false, the integer # value 1, for the string, "Not Supported", should be # the only entry in the PowerManagementCapabilities # array.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.133 NAME 'dlmPowerOnHours' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'The number of consecutive hours that this Device # has been powered, since its last power cycle. The # value is considered to be Hours.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.134 NAME 'dlmStatusInfo' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'StatusInfo is a string indicating whether the # Logical Device is in an enabled (value = 3), disabled # (value = 4) or some other (1) or unknown (2) state. If # this property does not apply to the LogicalDevice, the # value, 5 ("Not Applicable"). Values are 1="Other", # 2="Unknown", 3="Enabled", 4="Disabled", 5="Not #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.135 NAME 'dlmTotalPowerOnHours' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'The total number of hours that this Device has # been powered. The value is considered to be Hours.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.7 NAME 'dlm1LogicalDevice' SUP dlm1LogicalElement ABSTRACT MAY ( dlmAdditionalAvailability $ dlmAvailability $ dlmCreationClassName $ dlmDeviceID $ dlmErrorCleared $ dlmErrorDescription $ dlmLastErrorCode $ dlmMaxQuiesceTime $ dlmPowerManagementCapabilities $ dlmPowerManagementSupported $ dlmPowerOnHours $ dlmStatusInfo $ dlmTotalPowerOnHours ) ) # DESC 'An abstraction or emulation of a hardware entity, # that may or may not be Realized in physical hardware. # Any characteristics of a LogicalDevice that are used # to manage its operation or configuration are contained # in, or associated with, the LogicalDevice object. # Examples of the operational properties of a Printer # would be paper sizes supported, or detected errors. # Examples of the configuration properties of a Sensor # Device would be threshold settings. Various # configurations could exist for a LogicalDevice. These # configurations could be contained in Setting objects # and associated with the LogicalDevice.' ## 3.9 Service ## This class represents a Logical Element that contains the information necessary to ## represent and manage the functionality provided by a device and/or software feature. A ## service is a general-purpose object to configure and manage the implementation of ## functionality. It is not the functionality itself. attributetype ( 1.3.6.1.4.1.412.100.2.2.136 NAME 'dlmStartMode' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{10} SINGLE-VALUE ) # DESC 'StartMode is a string value indicating whether # the Service is automatically started by a System, # Operating System, etc. or only started upon request. # Value Mapping are "Automatic", "Manual"' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.137 NAME 'dlmStarted' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'Started is a boolean indicating whether the # Service has been started (TRUE), or stopped (FALSE).' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.8 NAME 'dlm1Service' SUP dlm1LogicalElement ABSTRACT MAY ( dlmCreationClassName $ dlmName $ dlmStartMode $ dlmStarted ) ) # DESC 'A Service is a Logical Element that contains the # information necessary to represent and manage the # functionality provided by a Device and/or # SoftwareFeature. A Service is a general-purpose object # to configure and manage the implementation of # functionality. It is not the functionality itself.' ## 3.10 ServiceAccessPoint ## This class represents the ability to use or invoke a service. Access points represent that a ## service is made available to other entities for use. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.9 NAME 'dlm1ServiceAccessPoint' SUP dlm1LogicalElement ABSTRACT MAY ( dlmCreationClassName $ dlmName ) ) # DESC 'ServiceAccessPoint represents the ability to # utilize or invoke a Service. Access points represent # that a Service is made available to other entities for # use.' ## 3.11 Collection ## This abstract class provides a common superclass for classes that represent collections of ## managed elements. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.10 NAME 'dlm1Collection' SUP dlm1ManagedElement ABSTRACT ) # DESC 'Collection is an abstract class that provides a # common superclass for data elements that represent # collections of ManagedElements and its subclasses.' ## 3.12 CollectionOfMSEs ## This object allows the grouping of ManagedSystemElement objects for associating ## settings and configurations. It is abstract to require further definition and semantic ## refinement in subclasses. As this object does not carry any state or status information, it ## only represents a grouping or 'bag' of elements. So, it is incorrect to subclass groups that ## have state/status from this class - an example is RedundancyGroup (which is correctly ## subclassed from LogicalElement). ## Collections typically aggregate 'like' objects, and represent an optimization. Without ## collections, one is forced to define individual associations, to tie settings and ## configuration objects to individual ManagedSystemElements. There may be much ## duplication in assigning the same setting to multiple objects. In addition, using this object ## allows the determination that the setting and configuration associations are indeed the ## same for the collection's members. This information would otherwise be obtained by ## defining the collection in a proprietary way, and then querying the associations to ## determine if the collection set is completely covered. attributetype ( 1.3.6.1.4.1.412.100.2.2.138 NAME 'dlmCollectionID' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The identification of the Collection object. When # subclassed, the CollectionID property can be overridden # to be a Key property.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.11 NAME 'dlm1CollectionOfMSEs' SUP dlm1Collection ABSTRACT MAY ( dlmCollectionID ) ) # DESC 'The CollectionOfMSEs object allows the grouping # of Managed SystemElements for the purposes of # associating Settings and Configurations. It is # abstract to require further definition and semantic # refinement in subclasses. The CollectionOfMSEs object # does not carry any state or status information, but # only represents a grouping or "bag" of Elements. For # this reason, it is incorrect to subclass groups that # have state/status from CollectionOfMSEs - an example # is Redundancy Group (which is correctly subclassed # from LogicalElement). Collections typically aggregate # "like" objects, and represent an optimization. Without # Collections, one is forced to define individual # ElementSetting and ElementConfiguration associations, # to tie Settings and Configuration objects to # individual ManagedSystemElements. There may be much # duplication in assigning the same Setting to multiple # objects. In addition, using the Collection object # allows the determination that the Setting and # Configuration associations are indeed the same for the # Collection"s members. This information would otherwise # be obtained by defining the Collection in a # proprietary manner, and then querying the # ElementSetting and ElementConfiguration associations # to determine if the Collection set is completely # covered.' ## 3.13 Configuration Classes ## This object allows the grouping of sets of parameters (defined in Setting objects) and ## dependencies for one or more managed system elements. The configuration object ## represents a certain behavior, or a desired functional state for the managed system ## elements. The desired functional state is typically driven by external requirements such as ## time or location. For example, to connect to a Mail System from 'home', a dependency on ## a modem exists, but a dependency on a network adapter exists at 'work'. Settings for the ## pertinent logical devices can be defined and aggregated by the configuration. Therefore, ## two 'Connect to Mail' configurations may be defined grouping the relevant dependencies ## and setting objects. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.12 NAME 'dlm1Configuration' SUP dlm1ManagedElement ABSTRACT ) # DESC 'The Configuration object allows the grouping of # sets of parameters (defined in Setting objects) and # dependencies for one or more ManagedSystemElements. # The Configuration object represents a certain # behavior, or a desired functional state for the # ManagedSystemElements. The desired functional state is # typically driven by external requirements such as time # or location. For example, to connect to a Mail System # from "home", a dependency on a modem exists, but a # dependency on a network adapter exists at "work". # Settings for the pertinent LogicalDevices (in this # example, POTSModem and NetworkAdapter) can be defined # and aggregated by the Configuration. Therefore, two # "Connect to Mail" Configurations may be defined # grouping the relevant dependencies and Setting # objects.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.13 NAME 'dlm1ConfigurationAuxClass' SUP dlm1Configuration AUXILIARY ) # DESC 'The Configuration object allows the grouping of # sets of parameters (defined in Setting objects) and # dependencies for one or more ManagedSystemElements. # The Configuration object represents a certain # behavior, or a desired functional state for the # ManagedSystemElements. The desired functional state is # typically driven by external requirements such as time # or location. For example, to connect to a Mail System # from "home", a dependency on a modem exists, but a # dependency on a network adapter exists at "work". # Settings for the pertinent LogicalDevices (in this # example, POTSModem and NetworkAdapter) can be defined # and aggregated by the Configuration. Therefore, two # "Connect to Mail" Configurations may be defined # grouping the relevant dependencies and Setting # objects.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.14 NAME 'dlm1ConfigurationInstance' SUP dlm1Configuration ) # DESC 'The Configuration object allows the grouping of # sets of parameters (defined in Setting objects) and # dependencies for one or more ManagedSystemElements. # The Configuration object represents a certain # behavior, or a desired functional state for the # ManagedSystemElements. The desired functional state is # typically driven by external requirements such as time # or location. For example, to connect to a Mail System # from "home", a dependency on a modem exists, but a # dependency on a network adapter exists at "work". # Settings for the pertinent LogicalDevices (in this # example, POTSModem and NetworkAdapter) can be defined # and aggregated by the Configuration. Therefore, two # "Connect to Mail" Configurations may be defined # grouping the relevant dependencies and Setting # objects.' # ( 1.3.6.1.4.1.412.100.2.3.3.1 NAME 'dlm1ConfigurationInstanceNameForm1' # OC dlm1ConfigurationInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1ConfigurationInstanceStructureRule1' # Form dlm1ConfigurationInstanceNameForm1 # ) ## The following content rule specifies the auxiliary classes that may be attached to ##dlm1ConfigurationInstance. # ( 1.3.6.1.4.1.412.100.2.1.3.14 # NAME 'dlm1ConfigurationInstanceContentRule' # DESC 'Aux classes that can attach to # dlm1ConfigurationInstance.' # MAY ( dlm1ElementConfigurationAuxClass $ # dlm1CollectionConfigurationAuxClass $ # dlm1ConfigurationComponentAuxClass $ # dlm1SettingContextAuxClass ) # ) ##3.14 Setting ##This class represents configuration-related and operational parameters for one or more ##managed system element(s). A managed system element may have multiple setting ##objects associated with it. The current operational values for an element's parameters are ##reflected by properties in the element itself or by properties in its associations. These ##properties do not have to be the same values present in the setting object. For example, a ##modem may have a setting baud rate of 56Kb/sec but be operating at 19.2Kb/sec. attributetype ( 1.3.6.1.4.1.412.100.2.2.139 NAME 'dlmSettingID' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The identifier by which the Setting object is # known.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.15 NAME 'dlm1Setting' SUP dlm1ManagedElement ABSTRACT MAY ( dlmSettingID ) ) # DESC 'The Setting class represents # configuration-related and operational parameters for # one or more ManagedSystem Element(s). A # ManagedSystemElement may have multiple Setting objects # associated with it. The current operational values for # an Element"s parameters are reflected by properties in # the Element itself or by properties in its # associations. These properties do not have to be the # same values present in the Setting object. For # example, a modem may have a Setting baud rate of # 56Kb/sec but be operating at 19.2Kb/sec.' ## 3.15 Product Classes ## This concrete class that is a collection of physical elements, software features and/or ## other products, acquired as a unit. Acquisition implies an agreement between supplier and ## consumer that may have implications to product licensing, support and warranty. attributetype ( 1.3.6.1.4.1.412.100.2.2.140 NAME 'dlmIdentifyingNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'Product identification such as a serial number on # software, a die number on a hardware chip, or (for # non-commercial Products) a project number.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.141 NAME 'dlmSKUNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'Product SKU (stock keeping unit) information.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.142 NAME 'dlmVendor' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'The name of the Product"s supplier, or entity # selling the Product (the manufacturer, reseller, OEM, # etc.). Corresponds to the Vendor property in the # Product object in the DMTF Solution Exchange Standard.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.143 NAME 'dlmWarrantyDuration' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'If this Product is under warranty, the duration # of the warranty in days. The value is considered to be # Days.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.144 NAME 'dlmWarrantyStartDate' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) # DESC 'If this Product is under warranty, the start date # of the warranty.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.16 NAME 'dlm1Product' SUP dlm1ManagedElement ABSTRACT MAY ( dlmIdentifyingNumber $ dlmName $ dlmSKUNumber $ dlmVendor $ dlmVersion $ dlmWarrantyDuration $ dlmWarrantyStartDate ) ) # DESC 'Product is a concrete class that is a collection # of PhysicalElements, SoftwareFeatures and/or other # Products, acquired as a unit. Acquisition implies an # agreement between supplier and consumer which may have # implications to Product licensing, support and # warranty. Non-commercial (e.g., in-house developed # Products) should also be identified as an instance of # Product.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.17 NAME 'dlm1ProductAuxClass' SUP dlm1Product AUXILIARY ) # DESC 'Product is a concrete class that is a collection # of PhysicalElements, SoftwareFeatures and/or other # Products, acquired as a unit. Acquisition implies an # agreement between supplier and consumer which may have # implications to Product licensing, support and # warranty. Non-commercial (e.g., in-house developed # Products) should also be identified as an instance of # Product.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.18 NAME 'dlm1ProductInstance' SUP dlm1Product ) # DESC 'Product is a concrete class that is a collection # of PhysicalElements, SoftwareFeatures and/or other # Products, acquired as a unit. Acquisition implies an # agreement between supplier and consumer which may have # implications to Product licensing, support and # warranty. Non-commercial (e.g., in-house developed # Products) should also be identified as an instance of # Product.' # ( 1.3.6.1.4.1.412.100.2.3.3.2 # NAME 'dlm1ProductInstanceNameForm1' # OC dlm1ProductInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1ProductInstanceStructureRule1' # Form dlm1ProductInstanceNameForm1 # ) ## The following content rule specifies the auxiliary classes that may be attached to ## dlm1ProductInstance. # ( 1.3.6.1.4.1.412.100.2.1.3.18 NAME 'dlm1ProductInstanceContentRule' # DESC 'Aux classes that can attach to # dlm1ProductInstance.' # MAY ( dlm1ProductProductDependencyAuxClass $ # dlm1ProductSupportAuxClass $ dlm1ProductFRUAuxClass $ # dlm1ProductParentChildAuxClass $ # dlm1FRUIncludesProductAuxClass $ # dlm1ProductPhysicalElementsAuxClass ) # ) ## 3.16 SupportAccess Classes ## These classes define how to obtain help for a product. attributetype ( 1.3.6.1.4.1.412.100.2.2.145 NAME 'dlmCommunicationInfo' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # DESC 'CommunicationInfo provides the details of the # Communication Mode. For example, if the # CommunicationMode is "Phone", CommunicationInfo # specifies the phone number to be called.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.146 NAME 'dlmCommunicationMode' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'CommunicationMode defines the form of # communication in order to obtain support. For example, # phone communication (value =2), fax (3) or email (8) # can be specified. Values are 1="Other", 2="Phone", # 3="Fax", 4="BBS", 5="Online Service", 6="Web Page", # 7="FTP", 8="E-mail"' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.147 NAME 'dlmLocale' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'Locale defines the geographic region and/or # language dialect to which this Support resource # pertains.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.148 NAME 'dlmSupportAccessId' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) # DESC 'SupportAccessID is an arbitrary, free form string # defined by the Product Vendor or by the organization # that deploys the Product. This property, since it is # a key, should be unique throughout the enterprise.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.19 NAME 'dlm1SupportAccess' SUP dlm1ManagedElement ABSTRACT MAY ( dlmCommunicationInfo $ dlmCommunicationMode $ dlmDescription $ dlmLocale $ dlmSupportAccessId ) ) # DESC 'The SupportAccess association defines how to # obtain assistance for a Product.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.20 NAME 'dlm1SupportAccessAuxClass' SUP dlm1SupportAccess AUXILIARY ) # DESC 'The SupportAccess association defines how to # obtain assistance for a Product.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.21 NAME 'dlm1SupportAccessInstance' SUP dlm1SupportAccess ) # DESC 'The SupportAccess association defines how to # obtain assistance for a Product.' # ( 1.3.6.1.4.1.412.100.2.3.3.3 NAME 'dlm1SupportAccessInstanceNameForm1' # OC dlm1SupportAccessInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1SupportAccessInstanceStructureRule1' # Form dlm1SupportAccessInstanceNameForm1 # ) ## The following content rule specifies the auxiliary classes that may be attached to ## dlm1SupportAccessInstance. # ( 1.3.6.1.4.1.412.100.2.1.3.21 NAME 'dlm1SupportAccessInstanceContentRule' # DESC 'Aux classes that can attach to # dlm1SupportAccessInstance.' # MAY ( dlm1ProductSupportAuxClass ) # ) ## 3.17 FRU Classes ## These classes model vendor-defined collection of products and/or physical elements that ## is associated with a product for supporting, maintaining or upgrading that product at the ## customer's location. FRU is an acronym for 'field replaceable unit'. attributetype ( 1.3.6.1.4.1.412.100.2.2.149 NAME 'dlmFRUNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'FRU ordering information.' #LSB - added matching rules attributetype ( 1.3.6.1.4.1.412.100.2.2.150 NAME 'dlmRevisionLevel' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) # DESC 'The FRU"s revision level.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.22 NAME 'dlm1FRU' SUP dlm1ManagedElement ABSTRACT MAY ( dlmDescription $ dlmFRUNumber $ dlmIdentifyingNumber $ dlmName $ dlmRevisionLevel $ dlmVendor ) ) # DESC 'The FRU class is a vendor-defined collection of # Products and/or PhysicalElements that is associated # with a Product for the purpose of supporting, # maintaining or upgrading that Product at the # customer"s location. FRU is an acronym for "field # replaceable unit". ' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.23 NAME 'dlm1FRUAuxClass' SUP dlm1FRU AUXILIARY ) # DESC 'The FRU class is a vendor-defined collection of # Products and/or PhysicalElements that is associated # with a Product for the purpose of supporting, # maintaining or upgrading that Product at the # customer"s location. FRU is an acronym for "field # replaceable unit". ' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.24 NAME 'dlm1FRUInstance' SUP dlm1FRU ) # DESC 'The FRU class is a vendor-defined collection of # Products and/or PhysicalElements that is associated # with a Product for the purpose of supporting, # maintaining or upgrading that Product at the # customer"s location. FRU is an acronym for "field # replaceable unit". ' # ( 1.3.6.1.4.1.412.100.2.3.3.4 NAME 'dlm1FRUInstanceNameForm1' # OC dlm1FRUInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1FRUInstanceStructureRule1' # Form dlm1FRUInstanceNameForm1 # ) ## The following content rule specifies the auxiliary classes that may be attached to ## dlm1FRUInstance. # ( 1.3.6.1.4.1.412.100.2.1.3.24 NAME 'dlm1FRUInstanceContentRule' # DESC 'Aux classes that can attach to dlm1FRUInstance.' # MAY ( dlm1ProductFRUAuxClass $ # dlm1FRUPhysicalElementsAuxClass $ # dlm1FRUIncludesProductAuxClass ) # ) ## 3.18 CollectedCollections Classes ## These classes represent that a CollectionOfMSEs may itself be contained in another ## CollectionOfMSEs object. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.25 NAME 'dlm1CollectedCollections' SUP top ABSTRACT ) # DESC 'CollectedCollections is an aggregation # association representing that a CollectionOfMSEs may # itself be contained in a CollectionOfMSEs.' attributetype ( 1.3.6.1.4.1.412.100.2.2.151 NAME 'dlmCollectedCollectionsCollectionRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # DESC 'The "higher level" or parent element in the # aggregation.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.152 NAME 'dlmCollectedCollectionsCollectionInCollectionRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # DESC 'The "collected" Collection.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.26 NAME 'dlm1CollectedCollectionsAuxClass' SUP dlm1CollectedCollections AUXILIARY MAY ( dlmCollectedCollectionsCollectionRef $ dlmCollectedCollectionsCollectionInCollectionRef ) ) # DESC 'CollectedCollections is an aggregation # association representing that a CollectionOfMSEs may # itself be contained in a CollectionOfMSEs.' ## 3.19 LogicalIdentity ## This auxiliary class represents an abstract and generic association, showing that two ## LogicalElements represent different aspects of the same underlying entity. This ## relationship conveys what could be defined with multiple inheritance. It is restricted to ## the 'logical' aspects of a ManagedSystemElement. In most scenarios, the equivalence of ## keys or some other identifying properties of the related elements determines the identity ## relationship. The association should only be used in well-understood scenarios. This is ## why the association is abstract - allowing more concrete definition and clarification in ## subclasses. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.27 NAME 'dlm1LogicalIdentity' SUP top ABSTRACT ) # DESC 'LogicalIdentity is an abstract and generic # association, indicating that two LogicalElements # represent different aspects of the same underlying # entity. This relationship conveys what could be # defined with multiple inheritance. It is restricted to # the "logical" aspects of a ManagedSystem Element. In # most scenarios, the Identity relationship is # determined by the equivalence of Keys or some other # identifying properties of the related Elements. The # association should only be used in well understood # scenarios. This is why the association is abstract - # allowing more concrete definition and clarification in # subclasses. One of the scenarios where this # relationship is reasonable is to represent that a # Device is both a "bus" entity and a "functional" # entity. For example, a Device could be both a USB # (bus) and a Keyboard (functional) entity.' ## 3.20 ConfigurationComponent Classes ## This association aggregates 'lower-level' configuration objects into a \'high-level' ## configuration. This enables the assembly of complex configurations by grouping together ## simpler ones. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.28 NAME 'dlm1ConfigurationComponent' SUP top ABSTRACT ) # DESC 'ConfigurationComponent aggregates "lower-level" # Configuration objects into a "high-level" # Configuration. This enables the assembly of complex # Configurations by grouping together simpler ones. For # example, a logon policy for the United States could # consist of two Configuration groups, one for the east # coast and one for the west coast. Each of these could # in turn consist of multiple Configurations to handle # different aspects of the logon process.' attributetype ( 1.3.6.1.4.1.412.100.2.2.153 NAME 'dlmConfigurationComponentConfigComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'A Configuration that is part of a "higher-level" # Configuration.' attributetype ( 1.3.6.1.4.1.412.100.2.2.154 NAME 'dlmConfigurationComponentConfigGroupRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Configuration that aggregates additional # Configurations. ' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.29 NAME 'dlm1ConfigurationComponentAuxClass' SUP dlm1ConfigurationComponent AUXILIARY MAY ( dlmConfigurationComponentConfigComponentRef $ dlmConfigurationComponentConfigGroupRef ) ) # DESC 'ConfigurationComponent aggregates "lower-level" # Configuration objects into a "high-level" # Configuration. This enables the assembly of complex # Configurations by grouping together simpler ones. For # example, a logon policy for the United States could # consist of two Configuration groups, one for the east # coast and one for the west coast. Each of these could # in turn consist of multiple Configurations to handle # different aspects of the logon process.' ## 3.21 ElementConfiguration Classes ## This association relates a configuration object to one or more managed system elements. ## The configuration object represents a certain behavior, or a desired functional state for ## the associated managed system elements. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.30 NAME 'dlm1ElementConfiguration' SUP top ABSTRACT ) # DESC 'This association relates a Configuration object # to one or more ManagedSystemElements. The # Configuration object represents a certain behavior, or # a desired functional state for the associated # ManagedSystemElements.' attributetype ( 1.3.6.1.4.1.412.100.2.2.155 NAME 'dlmElementConfigurationConfigurationRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Configuration object that groups the Settings # and dependencies associated with the # ManagedSystemElement.' attributetype ( 1.3.6.1.4.1.412.100.2.2.156 NAME 'dlmElementConfigurationElementRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The ManagedSystemElement.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.31 NAME 'dlm1ElementConfigurationAuxClass' SUP dlm1ElementConfiguration AUXILIARY MAY ( dlmElementConfigurationConfigurationRef $ dlmElementConfigurationElementRef ) ) # DESC 'This association relates a Configuration object # to one or more ManagedSystemElements. The # Configuration object represents a certain behavior, or # a desired functional state for the associated # ManagedSystemElements.' ## 3.22 ConfigurationCollection Classes ## These classes relate a Configuration object to one or more CollectionOfMSEs objects. ## The Configuration object represents a certain behavior, or a desired functional state for ## the associated collection. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.32 NAME 'dlm1CollectionConfiguration' SUP top ABSTRACT ) # DESC 'This association relates a Configuration object # to one or more CollectionOfMSEs objects. The # Configuration object represents a certain behavior, or # a desired functional state for the associated # Collection.' attributetype ( 1.3.6.1.4.1.412.100.2.2.157 NAME 'dlmCollectionConfigurationCollectionRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The CollectionOfMSEs.' attributetype ( 1.3.6.1.4.1.412.100.2.2.158 NAME 'dlmCollectionConfigurationConfigurationRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Configuration object that groups the Settings # and dependencies associated with the Collection.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.33 NAME 'dlm1CollectionConfigurationAuxClass' SUP dlm1CollectionConfiguration AUXILIARY MAY ( dlmCollectionConfigurationCollectionRef $ dlmCollectionConfigurationConfigurationRef ) ) # DESC 'This association relates a Configuration object # to one or more CollectionOfMSEs objects. The # Configuration object represents a certain behavior, or # a desired functional state for the associated # Collection.' ## 3.23 ElementSetting Classes ## These classes represent the association between managed system elements and the setting ## class(es) defined for them. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.34 NAME 'dlm1ElementSetting' SUP top ABSTRACT ) # DESC 'ElementSetting represents the association between # Managed SystemElements and the Setting class(es) # defined for them.' attributetype ( 1.3.6.1.4.1.412.100.2.2.159 NAME 'dlmElementSettingElementRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The ManagedSystemElement.' attributetype ( 1.3.6.1.4.1.412.100.2.2.160 NAME 'dlmElementSettingSettingRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Setting object associated with the # ManagedSystem Element.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.35 NAME 'dlm1ElementSettingAuxClass' SUP dlm1ElementSetting AUXILIARY MAY ( dlmElementSettingElementRef $ dlmElementSettingSettingRef ) ) # DESC 'ElementSetting represents the association between # Managed SystemElements and the Setting class(es) # defined for them.' ## 3.24 DefaultSetting Classes ## These classes represent the association between a ManagedSystemElement and the single ## Setting class that is defined to be the default setting for this element. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.36 NAME 'dlm1DefaultSetting' SUP dlm1ElementSetting ABSTRACT ) # DESC 'DefaultSetting represents the association between # a Managed SystemElement and the single Setting class # that is defined to be the default setting for this # Element.' attributetype ( 1.3.6.1.4.1.412.100.2.2.161 NAME 'dlmDefaultSettingElementRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The ManagedSystemElement.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.162 NAME 'dlmDefaultSettingSettingRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Setting object which is the default.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.37 NAME 'dlm1DefaultSettingAuxClass' SUP dlm1DefaultSetting AUXILIARY MAY ( dlmDefaultSettingElementRef $ dlmDefaultSettingSettingRef ) ) # DESC 'DefaultSetting represents the association between # a Managed SystemElement and the single Setting class # that is defined to be the default setting for this # Element.' ## 3.25 SettingContext Classes ## These classes associate a setting with one or more configuration objects. For example, a ## network adapter's settings could change based on the site/network to which its hosting ## computer system is attached. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.38 NAME 'dlm1SettingContext' SUP top ABSTRACT ) # DESC 'This relationship associates Configuration # objects with Setting objects. For example, a # NetworkAdapter"s Settings could change based on the # site/network to which its hosting ComputerSystem is # attached. In this case, the ComputerSystem would have # two different Configuration objects, corresponding to # the differences in network configuration for the two # network segments. Configuration A would aggregate a # Setting object for the NetworkAdapter when operating # on segment \"ANet\", whereas Configuration B would # aggregate a different NetworkAdapter Setting object, # specific to segment \"BNet\". Note that many Settings # of the computer are independent of the network # Configuration. For example, both Configurations A and # B would aggregate the same Setting object for the # ComputerSystem"s MonitorResolution.' attributetype ( 1.3.6.1.4.1.412.100.2.2.163 NAME 'dlmSettingContextContextRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Configuration object that aggregates the # Setting.' attributetype ( 1.3.6.1.4.1.412.100.2.2.164 NAME 'dlmSettingContextSettingRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'An aggregated Setting.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.39 NAME 'dlm1SettingContextAuxClass' SUP dlm1SettingContext AUXILIARY MAY ( dlmSettingContextContextRef $ dlmSettingContextSettingRef ) ) # DESC 'This relationship associates Configuration # objects with Setting objects. For example, a # NetworkAdapter"s Settings could change based on the # site/network to which its hosting ComputerSystem is # attached. In this case, the ComputerSystem would have # two different Configuration objects, corresponding to # the differences in network configuration for the two # network segments. Configuration A would aggregate a # Setting object for the NetworkAdapter when operating # on segment \"ANet\", whereas Configuration B would # aggregate a different NetworkAdapter Setting object, # specific to segment \"BNet\". Note that many Settings # of the computer are independent of the network # Configuration. For example, both Configurations A and # B would aggregate the same Setting object for the # ComputerSystem"s MonitorResolution.' ## 3.26 CollectionSetting Classes ## These classes represent the association between a CollectionOfMSEs class and the ## Setting class(es) defined for them. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.40 NAME 'dlm1CollectionSetting' SUP top ABSTRACT ) # DESC 'CollectionSetting represents the association # between a CollectionOfMSEs class and the Setting # class(es) defined for them.' attributetype ( 1.3.6.1.4.1.412.100.2.2.165 NAME 'dlmCollectionSettingCollectionRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The CollectionOfMSEs.' attributetype ( 1.3.6.1.4.1.412.100.2.2.166 NAME 'dlmCollectionSettingSettingRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Setting object associated with the # Collection.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.41 NAME 'dlm1CollectionSettingAuxClass' SUP dlm1CollectionSetting AUXILIARY MAY ( dlmCollectionSettingCollectionRef $ dlmCollectionSettingSettingRef ) ) # DESC 'CollectionSetting represents the association # between a CollectionOfMSEs class and the Setting # class(es) defined for them.' ## 3.27 Dependency ## This abstract class represents a generic association used to establish dependency ## relationships between objects. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.42 NAME 'dlm1Dependency' SUP top ABSTRACT ) # DESC 'Dependency is a generic association used to # establish dependency relationships between # ManagedElements.' ## 3.28 ServiceAccessBySAP Classes ## These classes identify the access points for a service. For example, Netware, MacIntosh ## or Windows service access points may access a printer, which may be hosted on different ## system. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.43 NAME 'dlm1ServiceAccessBySAP' SUP dlm1Dependency ABSTRACT ) # DESC 'ServiceAccessBySAP is an association that # identifies the access points for a Service. For # example, a printer may be accessed by Netware, # MacIntosh or Windows ServiceAccess Points, potentially # hosted on different Systems.' attributetype ( 1.3.6.1.4.1.412.100.2.2.167 NAME 'dlmServiceAccessBySAPAntecedentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Service. ' attributetype ( 1.3.6.1.4.1.412.100.2.2.168 NAME 'dlmServiceAccessBySAPDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'An Access Point for a Service. Access points are # dependent in this relationship since they have no # function without a corresponding Service. ' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.44 NAME 'dlm1ServiceAccessBySAPAuxClass' SUP dlm1ServiceAccessBySAP AUXILIARY MAY ( dlmServiceAccessBySAPAntecedentRef $ dlmServiceAccessBySAPDependentRef ) ) # DESC 'ServiceAccessBySAP is an association that # identifies the access points for a Service. For # example, a printer may be accessed by Netware, # MacIntosh or Windows ServiceAccess Points, potentially # hosted on different Systems.' ## 3.29 HostedService ## This class maps the association between a Service and the System on which it resides. ## While this could be represented with DIT containment, this class is provided to allow for ## more general relationships. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.45 NAME 'dlm1HostedService' SUP dlm1Dependency ABSTRACT ) # DESC 'HostedService is an association between a Service # and the System on which the functionality resides. The # cardinality of this association is 1-to-many. A System # may host many Services. Services are weak with respect # to their hosting System. Heuristic: A Service is # hosted on the System where the LogicalDevices or # SoftwareFeatures that implement the Service are # located. The model does not represent Services hosted # across multiple systems. This is modeled as an # ApplicationSystem that acts as an aggregation point # for Services, that are each located on a single host.' attributetype ( 1.3.6.1.4.1.412.100.2.2.169 NAME 'dlmHostedServiceDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Service hosted on the System.' attributetype ( 1.3.6.1.4.1.412.100.2.2.170 NAME 'dlmHostedServiceAntecedentRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The hosting System.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.46 NAME 'dlm1HostedServiceAuxClass' SUP dlm1HostedService AUXILIARY MAY ( dlmHostedServiceDependentRef $ dlmHostedServiceAntecedentRef ) ) # DESC 'HostedService is an association between a Service # and the System on which the functionality resides. The # cardinality of this association is 1-to-many. A System # may host many Services. Services are weak with respect # to their hosting System. Heuristic: A Service is # hosted on the System where the LogicalDevices or # SoftwareFeatures that implement the Service are # located. The model does not represent Services hosted # across multiple systems. This is modeled as an # ApplicationSystem that acts as an aggregation point # for Services, that are each located on a single host.' ## 3.30 HostedAccessPoint ## These classes map an association between a ServiceAccessPoint and the System that ## provides it. Like HostedService, this is provided for more general representations than ## what is available through DIT containment. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.47 NAME 'dlm1HostedAccessPoint' SUP dlm1Dependency ABSTRACT ) # DESC 'HostedAccessPoint is an association between a # Service AccessPoint and the System on which it is # provided. The cardinality of this association is # 1-to-many and is weak with respect to the System. Each # System may host many ServiceAccessPoints. Heuristic: # If the implementation of the ServiceAccessPoint is # modeled, it must be implemented by a Device or # SoftwareFeature that is part of the System hosting the # ServiceAccessPoint.' attributetype ( 1.3.6.1.4.1.412.100.2.2.171 NAME 'dlmHostedAccessPointDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The SAP(s) that are hosted on this System.' attributetype ( 1.3.6.1.4.1.412.100.2.2.172 NAME 'dlmHostedAccessPointAntecedentRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The hosting System.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.48 NAME 'dlm1HostedAccessPointAuxClass' SUP dlm1HostedAccessPoint AUXILIARY MAY ( dlmHostedAccessPointDependentRef $ dlmHostedAccessPointAntecedentRef ) ) # DESC 'HostedAccessPoint is an association between a # Service AccessPoint and the System on which it is # provided. The cardinality of this association is # 1-to-many and is weak with respect to the System. Each # System may host many ServiceAccessPoints. Heuristic: # If the implementation of the ServiceAccessPoint is # modeled, it must be implemented by a Device or # SoftwareFeature that is part of the System hosting the # ServiceAccessPoint.' ## 3.31 ProvidesServiceToElement Classes ## These classes map an association is used to describe that ManagedSystemElements may ## be dependent on the functionality of one or more Services. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.49 NAME 'dlm1ProvidesServiceToElement' SUP dlm1Dependency ABSTRACT ) # DESC 'ProvidesServiceToElement is used to describe that # ManagedSystemElements may be dependent on the # functionality of one or more Services. An example is # that a Processor and an Enclosure (PhysicalElement) # are dependent on AlertOn LAN Services to signal an # incomplete or erroneous boot, and hardware-related # errors.' attributetype ( 1.3.6.1.4.1.412.100.2.2.173 NAME 'dlmProvidesServiceToElementDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The ManagedSystemElement dependent on the # Service.' attributetype ( 1.3.6.1.4.1.412.100.2.2.174 NAME 'dlmProvidesServiceToElementAntecedentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Service provided.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.50 NAME 'dlm1ProvidesServiceToElementAuxClass' SUP dlm1ProvidesServiceToElement AUXILIARY MAY ( dlmProvidesServiceToElementDependentRef $ dlmProvidesServiceToElementAntecedentRef ) ) # DESC 'ProvidesServiceToElement is used to describe that # ManagedSystemElements may be dependent on the # functionality of one or more Services. An example is # that a Processor and an Enclosure (PhysicalElement) # are dependent on AlertOn LAN Services to signal an # incomplete or erroneous boot, and hardware-related # errors.' ## 3.32 ServiceServiceDependency Classes ## These classes map an association between two services, showing that the latter is required ## to be present, required to have completed, or must be absent for the former Service to ## provide its functionality. For example, boot Services may be dependent on underlying ## BIOS disk and initialization services. For initialization services, the boot service is ## simply dependent on the initialization services completing. attributetype ( 1.3.6.1.4.1.412.100.2.2.175 NAME 'dlmRestartService' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'this property describes that the antecedent # service must be restarted after the dependent # operation is complete.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.176 NAME 'dlmTypeOfDependency' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) # DESC 'The nature of the Service to Service dependency. # This property describes that the associated Service # must have completed (value=2), must be started (3) or # must not be started (4) in order for the Service to # function. Values are 0="Unknown", 1="Other", # 2="Service Must Have Completed", 3="Service Must Be # Started", 4="Service Must Not Be Started"' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.51 NAME 'dlm1ServiceServiceDependency' SUP dlm1ProvidesServiceToElement ABSTRACT MAY ( dlmRestartService $ dlmTypeOfDependency ) ) # DESC 'ServiceServiceDependency is an association # between a Service and another Service, indicating that # the latter is required to be present, required to have # completed, or must be absent for the former Service to # provide its functionality. For example, Boot Services # may be dependent upon underlying BIOS Disk and # initialization Services. In the case of the # initialization Services, the Boot Service is simply # dependent on the init Services completing. For the # Disk Services, Boot Services may actually utilize the # SAPs of this Service. This usage dependency is # modeled via the ServiceSAPDependency association.' attributetype ( 1.3.6.1.4.1.412.100.2.2.177 NAME 'dlmServiceServiceDependencyAntecedentRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The required Service.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.178 NAME 'dlmServiceServiceDependencyDependentRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Service that is dependent on an underlying # Service.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.52 NAME 'dlm1ServiceServiceDependencyInstance' SUP dlm1ServiceServiceDependency MAY ( dlmServiceServiceDependencyAntecedentRef $ dlmServiceServiceDependencyDependentRef ) ) # DESC 'ServiceServiceDependency is an association # between a Service and another Service, indicating that # the latter is required to be present, required to have # completed, or must be absent for the former Service to # provide its functionality. For example, Boot Services # may be dependent upon underlying BIOS Disk and # initialization Services. In the case of the # initialization Services, the Boot Service is simply # dependent on the init Services completing. For the # Disk Services, Boot Services may actually utilize the # SAPs of this Service. This usage dependency is # modeled via the ServiceSAPDependency association.' # ( 1.3.6.1.4.1.412.100.2.3.3.5 NAME 'dlm1ServiceServiceDependencyInstanceNameForm1' # OC dlm1ServiceServiceDependencyInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1ServiceServiceDependencyInstanceStructureRule1' # Form dlm1ServiceServiceDependencyInstanceNameForm1 # ) attributetype ( 1.3.6.1.4.1.412.100.2.2.179 NAME 'dlmServiceServiceDependencyHelperRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'Pointer to ServiceServiceDependencyInstance.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.53 NAME 'dlm1ServiceServiceDependencyHelper' SUP top AUXILIARY MAY ( dlmServiceServiceDependencyHelperRef ) ) # DESC 'Helper class for finding # ServiceServiceDependency.' #LSB - dlmHelperRefToServiceServiceDependency is not defined in DSP0117 #LSB MAY ( dlmHelperRefToServiceServiceDependency ) #LSB - Perhaps DSP0117's authors meant... ## 3.33 ServiceSAPDependency Classes ## These classes map an association between a service and a service access point showing ## that the referenced SAP is used by the service to provide its functionality. For example, ## boot services may invoke BIOS disk services (interrupts) to function. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.54 NAME 'dlm1ServiceSAPDependency' SUP dlm1Dependency ABSTRACT ) # DESC 'ServiceSAPDependency is an association between a # Service and a ServiceAccessPoint indicating that the # referenced SAP is utilized by the Service to provide # its functionality. For example, Boot Services may # invoke BIOS" Disk Services (interrupts) in order to # function.' attributetype ( 1.3.6.1.4.1.412.100.2.2.180 NAME 'dlmServiceSAPDependencyDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Service that is dependent on an underlying # SAP.' attributetype ( 1.3.6.1.4.1.412.100.2.2.181 NAME 'dlmServiceSAPDependencyAntecedentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The required ServiceAccessPoint' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.55 NAME 'dlm1ServiceSAPDependencyAuxClass' SUP dlm1ServiceSAPDependency AUXILIARY MAY ( dlmServiceSAPDependencyDependentRef $ dlmServiceSAPDependencyAntecedentRef ) ) # DESC 'ServiceSAPDependency is an association between a # Service and a ServiceAccessPoint indicating that the # referenced SAP is utilized by the Service to provide # its functionality. For example, Boot Services may # invoke BIOS" Disk Services (interrupts) in order to # function.' ## 3.34 SAPSAPDependency Classes ## These classes model an association between two service access points showing that the ## latter is required in order for the former to use or connect with its service. For example, to ## print at a network printer, local print access points must use underlying network-related ## SAPs, or protocol endpoints, to send the print request. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.56 NAME 'dlm1SAPSAPDependency' SUP dlm1Dependency ABSTRACT ) # DESC 'SAPSAPDependency is an association between a # Service AccessPoint and another ServiceAccessPoint # indicating that the latter is required in order for # the former ServiceAccess Point to utilize or connect # with its Service. For example, to print at a network # printer, local Print Access Points must utilize # underlying network-related SAPs, or ProtocolEndpoints, # in order to send the print request.' attributetype ( 1.3.6.1.4.1.412.100.2.2.182 NAME 'dlmSAPSAPDependencyAntecedentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The required ServiceAccessPoint.' attributetype ( 1.3.6.1.4.1.412.100.2.2.183 NAME 'dlmSAPSAPDependencyDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The ServiceAccessPoint that is dependent on an # underlying SAP.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.57 NAME 'dlm1SAPSAPDependencyAuxClass' SUP dlm1SAPSAPDependency AUXILIARY MAY ( dlmSAPSAPDependencyAntecedentRef $ dlmSAPSAPDependencyDependentRef ) ) # DESC 'SAPSAPDependency is an association between a # Service AccessPoint and another ServiceAccessPoint # indicating that the latter is required in order for # the former ServiceAccess Point to utilize or connect # with its Service. For example, to print at a network # printer, local Print Access Points must utilize # underlying network-related SAPs, or ProtocolEndpoints, # in order to send the print request.' ## 3.35 Realizes Classes ## These classes define the mapping between a logical device and the physical component ## that implements the device. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.58 NAME 'dlm1Realizes' SUP dlm1Dependency ABSTRACT ) # DESC 'Realizes is the association that defines the # mapping between a Logical Device and the physical # component that implements the Device.' attributetype ( 1.3.6.1.4.1.412.100.2.2.184 NAME 'dlmRealizesDependentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The LogicalDevice.' attributetype ( 1.3.6.1.4.1.412.100.2.2.185 NAME 'dlmRealizesAntecedentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The physical component that implements the # Device.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.59 NAME 'dlm1RealizesAuxClass' SUP dlm1Realizes AUXILIARY MAY ( dlmRealizesDependentRef $ dlmRealizesAntecedentRef ) ) # DESC 'Realizes is the association that defines the # mapping between a Logical Device and the physical # component that implements the Device.' ## 3.36 MemberOfCollection Classes ## These classes establish membership of ManagedElement objects in a collection. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.60 NAME 'dlm1MemberOfCollection' SUP top ABSTRACT ) # DESC 'MemberOfCollection is an aggregation used to # establish membership of ManagedElements in a # Collection.' attributetype ( 1.3.6.1.4.1.412.100.2.2.186 NAME 'dlmMemberOfCollectionCollectionRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Collection that aggregates members' attributetype ( 1.3.6.1.4.1.412.100.2.2.187 NAME 'dlmMemberOfCollectionMemberRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The aggregated member of the collection.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.61 NAME 'dlm1MemberOfCollectionAuxClass' SUP dlm1MemberOfCollection AUXILIARY MAY ( dlmMemberOfCollectionCollectionRef $ dlmMemberOfCollectionMemberRef ) ) # DESC 'MemberOfCollection is an aggregation used to # establish membership of ManagedElements in a # Collection.' ## 3.37 CollectedMSEs Classes ## These classes represent a generic association used to establish the members of the ## grouping object, CollectionOfMSEs. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.62 NAME 'dlm1CollectedMSEs' SUP dlm1MemberOfCollection ABSTRACT ) # DESC 'CollectedMSEs is a generic association used to # establish the members of the grouping object, # CollectionOf MSEs.' attributetype ( 1.3.6.1.4.1.412.100.2.2.188 NAME 'dlmCollectedMSEsCollectionRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The grouping or "bag" object that represents the # Collection.' attributetype ( 1.3.6.1.4.1.412.100.2.2.189 NAME 'dlmCollectedMSEsMemberRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The members of the Collection.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.63 NAME 'dlm1CollectedMSEsAuxClass' SUP dlm1CollectedMSEs AUXILIARY MAY ( dlmCollectedMSEsCollectionRef $ dlmCollectedMSEsMemberRef ) ) # DESC 'CollectedMSEs is a generic association used to # establish the members of the grouping object, # CollectionOf MSEs.' ## 3.38 Component ## This abstract class maps a generic association used to establish 'part of' relationships ## between managed system elements. For example, the system component association ## defines parts of a system. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.64 NAME 'dlm1Component' SUP top ABSTRACT ) # DESC 'Component is a generic association used to # establish "part of" relationships between Managed # System Elements. For example, the SystemComponent # association defines parts of a System.' ## 3.39 SystemComponent Classes ## These classes specialize dlmComponent to establish relationships between a system and ## the managed system elements of which it is composed. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.65 NAME 'dlm1SystemComponent' SUP dlm1Component ABSTRACT ) # DESC 'SystemComponent is a specialization of the # Component association that establishes "part of" # relationships between a System and the Managed System # Elements of which it is composed.' attributetype ( 1.3.6.1.4.1.412.100.2.2.190 NAME 'dlmSystemComponentPartComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The child element that is a component of a # System.' attributetype ( 1.3.6.1.4.1.412.100.2.2.191 NAME 'dlmSystemComponentGroupComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The parent System in the Association.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.66 NAME 'dlm1SystemComponentAuxClass' SUP dlm1SystemComponent AUXILIARY MAY ( dlmSystemComponentPartComponentRef $ dlmSystemComponentGroupComponentRef ) ) # DESC 'SystemComponent is a specialization of the # Component association that establishes "part of" # relationships between a System and the Managed System # Elements of which it is composed.' ## 3.40 SystemDevice Classes ## These classes model the aggregation of a LogicalDevices by a System. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.67 NAME 'dlm1SystemDevice' SUP dlm1SystemComponent ABSTRACT ) # DESC 'LogicalDevices may be aggregated by a System. # This relationship is made explicit by the SystemDevice # association. ' attributetype ( 1.3.6.1.4.1.412.100.2.2.192 NAME 'dlmSystemDevicePartComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The LogicalDevice that is a component of a # System.' attributetype ( 1.3.6.1.4.1.412.100.2.2.193 NAME 'dlmSystemDeviceGroupComponentRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The parent system in the Association.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.68 NAME 'dlm1SystemDeviceAuxClass' SUP dlm1SystemDevice AUXILIARY MAY ( dlmSystemDevicePartComponentRef $ dlmSystemDeviceGroupComponentRef ) ) # DESC 'LogicalDevices may be aggregated by a System. # This relationship is made explicit by the SystemDevice # association. ' ## 3.41 ServiceComponent Classes ## These classes model a set of subordinate services that are aggregated together to form a ## higher-level service. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.69 NAME 'dlm1ServiceComponent' SUP dlm1Component ABSTRACT ) # DESC 'The ServiceComponent aggregation models a set of # subordinate Services that are aggregated together to # form a higher-level service.' attributetype ( 1.3.6.1.4.1.412.100.2.2.194 NAME 'dlmServiceComponentGroupComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The parent Service.' attributetype ( 1.3.6.1.4.1.412.100.2.2.195 NAME 'dlmServiceComponentPartComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The component Service.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.70 NAME 'dlm1ServiceComponentAuxClass' SUP dlm1ServiceComponent AUXILIARY MAY ( dlmServiceComponentGroupComponentRef $ dlmServiceComponentPartComponentRef ) ) # DESC 'The ServiceComponent aggregation models a set of # subordinate Services that are aggregated together to # form a higher-level service.' ## 3.42 ProductParentChild Classes ## These classes define a parent child hierarchy among products. For example, a product ## may come bundled with other products. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.71 NAME 'dlm1ProductParentChild' SUP top ABSTRACT ) # DESC 'The ProductParentChild association defines a # parent child hierarchy among Products. For example, a # Product may come bundled with other Products. ' attributetype ( 1.3.6.1.4.1.412.100.2.2.196 NAME 'dlmProductParentChildChildRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The child Product in the association.' attributetype ( 1.3.6.1.4.1.412.100.2.2.197 NAME 'dlmProductParentChildParentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The parent Product in the association.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.72 NAME 'dlm1ProductParentChildAuxClass' SUP dlm1ProductParentChild AUXILIARY MAY ( dlmProductParentChildChildRef $ dlmProductParentChildParentRef ) ) # DESC 'The ProductParentChild association defines a # parent child hierarchy among Products. For example, a # Product may come bundled with other Products. ' ## 3.43 CompatibleProduct Classes ## These classes model an association between products can show a wide variety of ## information. For example, it can show that the two referenced products interoperate, that ## they can be installed together, that one can be the physical container for the other, etc. attributetype ( 1.3.6.1.4.1.412.100.2.2.198 NAME 'dlmCompatibilityDescription' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # DESC 'CompatibilityDescription is a free-form string # defining how the two referenced Products interoperate # or are compatible, any limitations to compatibility, # etc.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.73 NAME 'dlm1CompatibleProduct' SUP top ABSTRACT MAY ( dlmCompatibilityDescription ) ) # DESC 'CompatibleProduct is an association between # Products that can indicate a wide variety of # information. For example, it can indicate that the two # referenced Products interoperate, that they can be # installed together, that one can be the physical # container for the other, etc. The string property, # CompatibilityDescription, defines how the Products # interoperate or are compatible, any limitations # regarding interoperability or installation, ...' attributetype ( 1.3.6.1.4.1.412.100.2.2.199 NAME 'dlmCompatibleProductCompatibleProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The compatible Product.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.200 NAME 'dlmCompatibleProductProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Product for which compatible offerings are # defined.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.74 NAME 'dlm1CompatibleProductInstance' SUP dlm1CompatibleProduct MAY ( dlmCompatibleProductCompatibleProductRef $ dlmCompatibleProductProductRef ) ) # DESC 'CompatibleProduct is an association between # Products that can indicate a wide variety of # information. For example, it can indicate that the two # referenced Products interoperate, that they can be # installed together, that one can be the physical # container for the other, etc. The string property, # CompatibilityDescription, defines how the Products # interoperate or are compatible, any limitations # regarding interoperability or installation, ...' # ( 1.3.6.1.4.1.412.100.2.3.3.6 NAME 'dlm1CompatibleProductInstanceNameForm1' # OC dlm1CompatibleProductInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1CompatibleProductInstanceStructureRule1' # Form dlm1CompatibleProductInstanceNameForm1 # ) attributetype ( 1.3.6.1.4.1.412.100.2.2.201 NAME 'dlmCompatibleProductHelperRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'Pointer to CompatibleProductInstance.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.75 NAME 'dlm1CompatibleProductHelper' SUP top AUXILIARY MAY ( dlmCompatibleProductHelperRef ) ) # DESC 'Helper class for finding CompatibleProduct.' #LSB - dlmHelperRefToCompatibleProduct is not defined in DSP0117 #LSB MAY ( dlmHelperRefToCompatibleProduct ) #LSB - Perhaps DSP0117's authors meant... ## 3.44 ProductProductDependency Classes ## These classes model an association between two products, showing that one must be ## installed, or must be absent, for the other to function. This is conceptually equivalent to ## the service to service dependency association. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.76 NAME 'dlm1ProductProductDependency' SUP top ABSTRACT MAY ( dlmTypeOfDependency ) ) # DESC 'ProductProductDependency is an association # between two Products, indicating that one must be # installed, or must be absent, for the other to # function. This is conceptually equivalent to the # ServiceServiceDependency association.' attributetype ( 1.3.6.1.4.1.412.100.2.2.202 NAME 'dlmProductProductDependencyDependentProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Product that is dependent on another Product.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.203 NAME 'dlmProductProductDependencyRequiredProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The required Product.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.77 NAME 'dlm1ProductProductDependencyInstance' SUP dlm1ProductProductDependency MAY ( dlmProductProductDependencyDependentProductRef $ dlmProductProductDependencyRequiredProductRef ) ) # DESC 'ProductProductDependency is an association # between two Products, indicating that one must be # installed, or must be absent, for the other to # function. This is conceptually equivalent to the # ServiceServiceDependency association.' # ( 1.3.6.1.4.1.412.100.2.3.3.7 NAME 'dlm1ProductProductDependencyInstanceNameForm1' # OC dlm1ProductProductDependencyInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1ProductProductDependencyInstanceStructureRule1' # Form dlm1ProductProductDependencyInstanceNameForm1 # ) attributetype ( 1.3.6.1.4.1.412.100.2.2.204 NAME 'dlmProductProductDependencyHelperRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'Pointer to ProductProductDependencyInstance.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.78 NAME 'dlm1ProductProductDependencyHelper' SUP top AUXILIARY MAY ( dlmProductProductDependencyHelperRef ) ) # DESC 'Helper class for finding # ProductProductDependency.' #LSB - dlmHelperRefToProductProductDependency is not defined in DSP0117 #LSB MAY ( dlmHelperRefToProductProductDependency ) #LSB - Perhaps DSP0117's authors meant... ## 3.45 ProductSupport Classes ## This classes represent the association between products and support access that conveys ## how support is obtained for the product. This is a many-to-many relationship, implying ## that various types of support are available for a product, and that the same support object ## can provide help for multiple products. This class defines two attributes that are self- ## explanatory. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.79 NAME 'dlm1ProductSupport' SUP top ABSTRACT ) # DESC 'ProductSupport is an association between Product # and SupportAccess that conveys how support is obtained # for the Product. This is a many-to-many relationship, # implying that various types of Support are available # for a Product, and that the same Support object can # provide assistance for multiple Products.' attributetype ( 1.3.6.1.4.1.412.100.2.2.205 NAME 'dlmProductSupportProductRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Product.' attributetype ( 1.3.6.1.4.1.412.100.2.2.206 NAME 'dlmProductSupportSupportRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'Support for the Product.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.80 NAME 'dlm1ProductSupportAuxClass' SUP dlm1ProductSupport AUXILIARY MAY ( dlmProductSupportProductRef $ dlmProductSupportSupportRef ) ) # DESC 'ProductSupport is an association between Product # and SupportAccess that conveys how support is obtained # for the Product. This is a many-to-many relationship, # implying that various types of Support are available # for a Product, and that the same Support object can # provide assistance for multiple Products.' ## 3.46 ProductFRU Classes ## These classes provides information regarding what product components have been or are ## being replaced. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.81 NAME 'dlm1ProductFRU' SUP top ABSTRACT ) # DESC 'ProductFRU is an association between Product and # FRU that provides information regarding what Product # components have been or are being replaced. The # association is one to many, conveying that a Product # can have many FRUs, and that a particular instance of # a FRU is only applied to one (instance of a) Product.' attributetype ( 1.3.6.1.4.1.412.100.2.2.207 NAME 'dlmProductFRUFRURef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The FRU.' attributetype ( 1.3.6.1.4.1.412.100.2.2.208 NAME 'dlmProductFRUProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Product to which the FRU is applied.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.82 NAME 'dlm1ProductFRUAuxClass' SUP dlm1ProductFRU AUXILIARY MAY ( dlmProductFRUFRURef $ dlmProductFRUProductRef ) ) # DESC 'ProductFRU is an association between Product and # FRU that provides information regarding what Product # components have been or are being replaced. The # association is one to many, conveying that a Product # can have many FRUs, and that a particular instance of # a FRU is only applied to one (instance of a) Product.' ## 3.47 ProductPhysicalElements Classes ## These classes show the physical elements that make up a product. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.83 NAME 'dlm1ProductPhysicalElements' SUP top ABSTRACT ) # DESC 'Indicates the PhysicalElements that make up a # Product.' attributetype ( 1.3.6.1.4.1.412.100.2.2.209 NAME 'dlmProductPhysicalElementsComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The PhysicalElement which is a part of the # Product.' attributetype ( 1.3.6.1.4.1.412.100.2.2.210 NAME 'dlmProductPhysicalElementsProductRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The Product.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.84 NAME 'dlm1ProductPhysicalElementsAuxClass' SUP dlm1ProductPhysicalElements AUXILIARY MAY ( dlmProductPhysicalElementsComponentRef $ dlmProductPhysicalElementsProductRef ) ) # DESC 'Indicates the PhysicalElements that make up a # Product.' ## 3.48 FRUPhysicalElements Classes ## These classes show the physical elements that make up a FRU. objectclass ( 1.3.6.1.4.1.412.100.2.1.3.85 NAME 'dlm1FRUPhysicalElements' SUP top ABSTRACT ) # DESC 'Indicates the PhysicalElements that make up a # FRU.' attributetype ( 1.3.6.1.4.1.412.100.2.2.211 NAME 'dlmFRUPhysicalElementsFRURef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The FRU.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.212 NAME 'dlmFRUPhysicalElementsComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The PhysicalElement which is a part of the FRU.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.86 NAME 'dlm1FRUPhysicalElementsAuxClass' SUP dlm1FRUPhysicalElements AUXILIARY MAY ( dlmFRUPhysicalElementsFRURef $ dlmFRUPhysicalElementsComponentRef ) ) # DESC 'Indicates the PhysicalElements that make up a # FRU.' ## 3.49 FRUIncludesProduct Classes ## These classes show that a FRU may be composed of other product(s). objectclass ( 1.3.6.1.4.1.412.100.2.1.3.87 NAME 'dlm1FRUIncludesProduct' SUP top ABSTRACT ) # DESC 'Indicates that a FRU may be composed of other # Product(s).' attributetype ( 1.3.6.1.4.1.412.100.2.2.213 NAME 'dlmFRUIncludesProductFRURef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'The FRU.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.214 NAME 'dlmFRUIncludesProductComponentRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'The Product which is a part of the FRU.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.88 NAME 'dlm1FRUIncludesProductAuxClass' SUP dlm1FRUIncludesProduct AUXILIARY MAY ( dlmFRUIncludesProductFRURef $ dlmFRUIncludesProductComponentRef ) ) # DESC 'Indicates that a FRU may be composed of other # Product(s).' ## 3.50 Synchronized Classes ## These classes indicate that two logical elements were aligned or made to be equivalent at ## the specified point in time. Preservation of synchronization is determined by the value of ## the dlmSyncMaintained attribute. attributetype ( 1.3.6.1.4.1.412.100.2.2.215 NAME 'dlmSyncMaintained' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) # DESC 'Boolean indicating whether synchronization is # maintained.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.216 NAME 'dlmWhenSynced' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) # DESC 'The point in time that the Elements were # synchronized.' #LSB - added matching rules objectclass ( 1.3.6.1.4.1.412.100.2.1.3.89 NAME 'dlm1Synchronized' SUP top ABSTRACT MAY ( dlmSyncMaintained $ dlmWhenSynced ) ) # DESC 'Indicates that two LogicalElements were aligned # or made to be equivalent at the specified point in # time. If the boolean property SyncMaintained is TRUE, # then synchronization of the Elements is preserved. # Both like and unlike objects may be synchronized. For # example, two WatchDog timers may be aligned, or the # contents of a LogicalFile may be synchronized with the # contents of a StorageExtent.' attributetype ( 1.3.6.1.4.1.412.100.2.2.217 NAME 'dlmSynchronizedSyncedElementRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'SyncedElement represents another LogicalElement # that is synchronized with the entity referenced as # SystemElement.' #LSB - added matching rule attributetype ( 1.3.6.1.4.1.412.100.2.2.218 NAME 'dlmSynchronizedSystemElementRef' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) # DESC 'SystemElement represents one LogicalElement that # is synchronized with the entity referenced as # SyncedElement.' #LSB - added matching rule objectclass ( 1.3.6.1.4.1.412.100.2.1.3.90 NAME 'dlm1SynchronizedInstance' SUP dlm1Synchronized MAY ( dlmSynchronizedSyncedElementRef $ dlmSynchronizedSystemElementRef ) ) # DESC 'Indicates that two LogicalElements were aligned # or made to be equivalent at the specified point in # time. If the boolean property SyncMaintained is TRUE, # then synchronization of the Elements is preserved. # Both like and unlike objects may be synchronized. For # example, two WatchDog timers may be aligned, or the # contents of a LogicalFile may be synchronized with the # contents of a StorageExtent.' # ( 1.3.6.1.4.1.412.100.2.3.3.8 NAME 'dlm1SynchronizedInstanceNameForm1' # OC dlm1SynchronizedInstance # MUST ( orderedCimKeys ) # ) # ( NAME 'dlm1SynchronizedInstanceStructureRule1' # Form dlm1SynchronizedInstanceNameForm1 # ) attributetype ( 1.3.6.1.4.1.412.100.2.2.219 NAME 'dlmSynchronizedHelperRef' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch ) # DESC 'Pointer to SynchronizedInstance.' objectclass ( 1.3.6.1.4.1.412.100.2.1.3.91 NAME 'dlm1SynchronizedHelper' SUP top AUXILIARY MAY ( dlmSynchronizedHelperRef ) ) # DESC 'Helper class for finding Synchronized.' --------------EE8FAB113B66D730A66B2A7F--