From majordomo@raleigh.ibm.com Tue Apr 3 17:22:26 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17450 for ; Tue, 3 Apr 2001 17:22:25 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA19040; Tue, 3 Apr 2001 17:12:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA33056; Tue, 3 Apr 2001 17:12:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47082; Tue, 3 Apr 2001 16:44:11 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54478; Tue, 3 Apr 2001 16:44:07 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA27690 for ; Tue, 3 Apr 2001 16:44:10 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA11800 for ; Tue, 3 Apr 2001 16:44:06 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Apr 2001 16:43:57 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: Alternate Dates/Venue for Interim Meeting Date: Tue, 3 Apr 2001 16:43:50 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson Policy WG: We had a rather poor response to the suggested dates and venues we sent out the last time, so we are going to try again. IBM has offered to host the interim meeting of the IETF Policy Framework working group in Research Triangle Park , NC (that's within 10 miles of the Raleigh/Durham Airport) either the week of May 7, or the week of May 14. Please respond with which week you would prefer. We are thinking a two and one-half day meeting, say: Tuesday, Wednesday, and half day Thursday. (The half day Thursday helps people to make it back home on Thursday night, in some cases.) That works out to May 8 - 10, or May 15 - 17. Please respond with your preference. Note: We are looking for as much participation as we can get, including the document authors for the documents that we targetted for draft revisions this month, including PCIMe and QPIM, drafts of which are due out within the next week or so. We plan to be discussing at least these revised drafts in this interim meeting. Please respond with your preference, and whether you intend to attend. We especially need the document authors to respond. Thanks, Ed From majordomo@raleigh.ibm.com Mon Apr 9 15:47:45 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15166 for ; Mon, 9 Apr 2001 15:47:43 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25690; Mon, 9 Apr 2001 15:35:23 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA32514; Mon, 9 Apr 2001 15:35:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51902; Mon, 9 Apr 2001 14:42:35 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA62902; Mon, 9 Apr 2001 14:42:32 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA29614 for ; Mon, 9 Apr 2001 14:42:35 -0400 Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA26052 for ; Mon, 9 Apr 2001 14:42:31 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 9 Apr 2001 14:41:17 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KNJJ4; Mon, 9 Apr 2001 14:41:17 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8NKV; Mon, 9 Apr 2001 14:41:20 -0400 Message-Id: <3AD201E7.72052660@americasm01.nt.com> Date: Mon, 09 Apr 2001 14:39:35 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: PolicyGroup component type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit In "2. Modeling Policies", PCIM defines: "Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both." PCLS-10, however, specifies in "5.2. The Three policyGroup Classes", that: "The information model defines a policyGroup class to serve as a generalized aggregation container. It enables policyRules and policyGroups to be aggregated in the same container." Also, PCIMe-00, in "4.5.1. Structuring Decision Strategies" gives an example where the same policyGroup instance aggregates both policyRules and policyGroups. Isn't this an error in PCLS and PCIMe ? Regards, Mircea. From majordomo@raleigh.ibm.com Mon Apr 9 21:31:53 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20969 for ; Mon, 9 Apr 2001 21:31:52 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA24174; Mon, 9 Apr 2001 21:17:34 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA24024; Mon, 9 Apr 2001 21:07:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48956; Mon, 9 Apr 2001 16:22:50 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48898; Mon, 9 Apr 2001 16:22:26 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA30054 for ; Mon, 9 Apr 2001 16:21:55 -0400 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA22074 for ; Mon, 9 Apr 2001 16:21:46 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f39KJoJ25509 for ; Mon, 9 Apr 2001 16:19:50 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 9 Apr 2001 16:20:46 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KNX97; Mon, 9 Apr 2001 16:20:46 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8NQS; Mon, 9 Apr 2001 16:20:49 -0400 Message-Id: <3AD21937.659B6534@americasm01.nt.com> Date: Mon, 09 Apr 2001 16:19:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: PCLS-10: LDAP query for policyRoles Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit WRT. PCLS-10 "5.3. The Three policyRule Classes" (page 27): "This approach eliminates the extraneous replies, but it requires the PDP to build the role combinations ("R1&&R2", "R1&&R3", etc.) itself, and it requires extra queries." IMO it doesn't necessarily require extra queries. The same result could be obtained with a single complex query: (|(policyRoles=R1&&R2)(policyRoles=R1&&R3)etc.). However, LDAP vendor specific or performance related issues may limit applicability of either approach. Regards, Mircea. From majordomo@raleigh.ibm.com Mon Apr 9 22:42:09 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23562 for ; Mon, 9 Apr 2001 22:42:08 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA27444; Mon, 9 Apr 2001 22:29:11 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA25412; Mon, 9 Apr 2001 22:22:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38908; Mon, 9 Apr 2001 17:41:14 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB65464; Mon, 9 Apr 2001 17:40:57 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA13224 for ; Mon, 9 Apr 2001 17:41:00 -0400 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA08718 for ; Mon, 9 Apr 2001 17:40:16 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f39Lc5J19609 for ; Mon, 9 Apr 2001 17:38:05 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 9 Apr 2001 17:39:23 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6K3GG9; Mon, 9 Apr 2001 17:39:22 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8NTV; Mon, 9 Apr 2001 17:39:26 -0400 Message-Id: <3AD22BA4.6688E1D8@americasm01.nt.com> Date: Mon, 09 Apr 2001 17:37:40 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: PCLS: ptpContitionTime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit The attribute "ptpConditionTime" doesn't allow "SUBSTR caseIgnoreSubstringsMatch". IMO the substring matching rule should be added to this attribute as well (like it is for "ptpConditionTimeOfDay"). This enables a policy server to select or (partially) validate ptpConditionAuxClass instances by setting the appropriate criteria in the LDAP search filter. Regards, Mircea. From majordomo@raleigh.ibm.com Tue Apr 10 11:30:40 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18340 for ; Tue, 10 Apr 2001 11:30:38 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA21396; Tue, 10 Apr 2001 11:23:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA35642; Tue, 10 Apr 2001 11:23:50 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB54392; Tue, 10 Apr 2001 10:56:22 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43632; Tue, 10 Apr 2001 10:56:16 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA26214 for ; Tue, 10 Apr 2001 10:56:17 -0400 Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA23122 for ; Tue, 10 Apr 2001 10:56:14 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3AEsHJ22189 for ; Tue, 10 Apr 2001 10:54:17 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 10 Apr 2001 10:55:21 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2M6KRTH2; Tue, 10 Apr 2001 10:55:20 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB831D; Tue, 10 Apr 2001 10:55:23 -0400 Message-Id: <3AD31E73.F5CE55C6@americasm01.nt.com> Date: Tue, 10 Apr 2001 10:53:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: PolicyGroup component type References: <3AD201E7.72052660@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I believe that this message did not get to the list. Therefore, I'm re-sending it. Sorry if you receive it twice. Thanks, Mircea. > In "2. Modeling Policies", PCIM defines: "Policy groups are aggregations > of policy rules, or aggregations of policy groups, but not both." > > PCLS-10, however, specifies in "5.2. The Three policyGroup Classes", > that: "The information model defines a policyGroup class to serve as a > generalized aggregation container. It enables policyRules and > policyGroups to be aggregated in the same container." > > Also, PCIMe-00, in "4.5.1. Structuring Decision Strategies" gives an > example where the same policyGroup instance aggregates both policyRules > and policyGroups. > > Isn't this an error in PCLS and PCIMe ? > > Regards, > Mircea. From majordomo@raleigh.ibm.com Wed Apr 11 07:07:34 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20303 for ; Wed, 11 Apr 2001 07:07:33 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA20924; Wed, 11 Apr 2001 06:59:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA23786; Wed, 11 Apr 2001 06:59:04 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35508; Wed, 11 Apr 2001 06:07:49 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49708; Wed, 11 Apr 2001 06:07:39 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA09814 for ; Wed, 11 Apr 2001 06:07:40 -0400 Received: from leeloo.ipg.pt (leeloo.ipg.pt [193.137.232.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id GAA10838 for ; Wed, 11 Apr 2001 06:07:38 -0400 Received: from jaguar (unverified [193.137.232.8]) by leeloo.ipg.pt (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 11 Apr 2001 11:03:38 +0100 From: "Vitor Roque" To: "IETF Policy Group" Subject: Development Projects on PBNM Date: Wed, 11 Apr 2001 11:05:32 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Vitor Roque" Content-Transfer-Encoding: 7bit Hi, I would like to know sites (internet addresses) about development projects on Policy Based Networking. If somebody could help me i appreciate. Thanks in advance Best Regards V.Roque From majordomo@raleigh.ibm.com Wed Apr 11 10:14:33 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24525 for ; Wed, 11 Apr 2001 10:14:33 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA28848; Wed, 11 Apr 2001 10:06:25 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA29746; Wed, 11 Apr 2001 10:05:10 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA64324; Wed, 11 Apr 2001 09:07:07 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35070; Wed, 11 Apr 2001 09:06:57 -0400 Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA35318 for ; Wed, 11 Apr 2001 09:06:59 -0400 Message-Id: <002101c0c287$e508b320$11312509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <3AD201E7.72052660@americasm01.nt.com> Subject: Re: PolicyGroup component type Date: Wed, 11 Apr 2001 09:04:07 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Mircea, There's clearly an inconsistency but I don't think it's an error. The original thinking was that a group would be homogeneous in it's content. But since then, we've recognized that such a restriction was really unnecessary in a core model. The IPSP model, for example, does restrict the contents of a group to be either groups or rules. I suspect the decision to relax the restriction was made after 3060 was stabilized but it might have been an oversight. In any case, we should call out the change more clearly in PCIMe. For consistency, we might want to make the PCLS draft reflect the old restriction, but I'm personally inclined to leave it knowing we're changing it in PCIMe. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com ----- Original Message ----- From: "Mircea Pana" To: "IETF Policy" Sent: Monday, April 09, 2001 2:39 PM Subject: PolicyGroup component type > In "2. Modeling Policies", PCIM defines: "Policy groups are aggregations > of policy rules, or aggregations of policy groups, but not both." > > PCLS-10, however, specifies in "5.2. The Three policyGroup Classes", > that: "The information model defines a policyGroup class to serve as a > generalized aggregation container. It enables policyRules and > policyGroups to be aggregated in the same container." > > Also, PCIMe-00, in "4.5.1. Structuring Decision Strategies" gives an > example where the same policyGroup instance aggregates both policyRules > and policyGroups. > > Isn't this an error in PCLS and PCIMe ? > > Regards, > Mircea. From majordomo@raleigh.ibm.com Thu Apr 12 00:12:16 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09473 for ; Thu, 12 Apr 2001 00:12:15 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA28340; Thu, 12 Apr 2001 00:04:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id AAA25550; Thu, 12 Apr 2001 00:04:11 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54616; Wed, 11 Apr 2001 23:14:51 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB61264; Wed, 11 Apr 2001 23:14:48 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id XAA21600; Wed, 11 Apr 2001 23:14:49 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA37464; Wed, 11 Apr 2001 23:14:44 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA27247; Wed, 11 Apr 2001 20:14:41 -0700 (PDT) Received: from andreawlap (rtp-dial-1-142.cisco.com [10.83.97.142]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AED02605; Wed, 11 Apr 2001 20:14:14 -0700 (PDT) From: "Andrea Westerinen" To: "Lee Rafalow" , "IETF Policy" Subject: RE: PolicyGroup component type Date: Wed, 11 Apr 2001 20:16:05 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <002101c0c287$e508b320$11312509@raleigh.ibm.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Lee and Mircea, We made the change to generalize PolicyGroups late last year. There were many places in the draft/RFC, where this was listed. It looks like we missed 1 place in the text, plus the CIM MOF in the Appendix. BTW, the CIM MOF has indeed been updated in the V2.5 release. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Lee Rafalow Sent: Wednesday, April 11, 2001 6:04 AM To: IETF Policy Subject: Re: PolicyGroup component type Mircea, There's clearly an inconsistency but I don't think it's an error. The original thinking was that a group would be homogeneous in it's content. But since then, we've recognized that such a restriction was really unnecessary in a core model. The IPSP model, for example, does restrict the contents of a group to be either groups or rules. I suspect the decision to relax the restriction was made after 3060 was stabilized but it might have been an oversight. In any case, we should call out the change more clearly in PCIMe. For consistency, we might want to make the PCLS draft reflect the old restriction, but I'm personally inclined to leave it knowing we're changing it in PCIMe. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com ----- Original Message ----- From: "Mircea Pana" To: "IETF Policy" Sent: Monday, April 09, 2001 2:39 PM Subject: PolicyGroup component type > In "2. Modeling Policies", PCIM defines: "Policy groups are aggregations > of policy rules, or aggregations of policy groups, but not both." > > PCLS-10, however, specifies in "5.2. The Three policyGroup Classes", > that: "The information model defines a policyGroup class to serve as a > generalized aggregation container. It enables policyRules and > policyGroups to be aggregated in the same container." > > Also, PCIMe-00, in "4.5.1. Structuring Decision Strategies" gives an > example where the same policyGroup instance aggregates both policyRules > and policyGroups. > > Isn't this an error in PCLS and PCIMe ? > > Regards, > Mircea. From majordomo@raleigh.ibm.com Fri Apr 13 19:55:52 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20810 for ; Fri, 13 Apr 2001 19:55:51 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA27492; Fri, 13 Apr 2001 19:48:53 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA13694; Fri, 13 Apr 2001 19:48:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52482; Fri, 13 Apr 2001 18:31:44 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52726; Fri, 13 Apr 2001 18:31:41 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA31608 for ; Fri, 13 Apr 2001 18:31:42 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA24342 for ; Fri, 13 Apr 2001 18:31:38 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 13 Apr 2001 18:31:27 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: Minutes submitted to Proceedings Date: Fri, 13 Apr 2001 18:31:23 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson Here are the minutes I submitted to the IETF Proceedings this morning. I thought I was in danger of missing the deadline, so I submitted them as-is. It turns out that we actually have until Monday, so if you see something here that I screwed up on, let me know, and I will fix it and try to ask the kind folks at the secretariat to accept an update on Monday.Actually, we went over the summary in the meeting wrap-up in Minneapolis, which includes the important actions items, revised charter, etc, so I felt somewhat safe in going ahead and releasing these to the proceedings, but I'll be glad to change them if I made a mistake or left something out. I also submitted everyone's presentation charts to the proceedings, (thanks to all of the presenters for giving them/sending them to me!), but I did not attach them here, due to the size of the attachment files. You should be able to access the charts from the IETF proceedings repository in the near future. Thanks, Ed Ellesson Highlights: Notes: First session of Policy Framework Monday, March 19, 2001 Agenda: Monday, March 19 * Agenda Bash/Intro (Chairs) 10 min * * PCLS Status, Ryan Moats 20 min * * * QPIM Status and Issues, Ron Cohen 20 min * * * PCIMe Status and Issues, Bob Moore 60 min. (Part One) * * * Recap/Summary (Chairs) 10 min * * Wednesday, March 21 * * Agenda Re-Bash/Recap (Chairs) 5 min * PCIMe (Continued), Bob Moore 40 min. (Part 2) * QDDIM Status and Issues, Bob Moore 20 min * * IPSec Policy Update/Issues, Lee Rafalow 20 min (ipsp) * * PP VPN Issues, M. Iyer 20 min (fyi) * * Terminology Status, Andrea Westerinen 20 min * * Recap/Summary (Chairs) 25 min Incl. Proposed Interim meeting and charter discussion Summary of Results of Meeting: Summary of Policy Framework WG Meeting Results, at 50th IETF: -PCLS to be modified with "MUST" changed to "MAY" for naming, and then to LAST CALL as of next week. -Need quick new version of QPIM to comment on, and then another rev before London, after PCIMe is updated. (see date list below) -New text will be created for PCIMe to address the remaining issues, including "State in Rule Engine". Authors will meet to plan way forward toward new text, prior to 2nd session. (update: multiple meetings scheduled and significant consensus on multiple issues accomplished during the week in Minneapolis. Further productive author discussions are in progress via email.) -Another draft is ready for last call (terminology), with potential minor modifications on two terms possible, after consultation with snmpconf representative. -Our model is getting used....let's take credit for it! (IPSP, and unchartered work on MPLS and VPN) -Interim Meeting (See dates below) -Charter refresh (See dates below) -New Charter Dates, as well as Interim Draft and Meeting Dates (Discussed in Meeting): *Nov. '00: PCIM submittal for Proposed Std Status (done) *Mar. '01: PCLS last call *Mar. '01: Terminology draft last call (fyi track) *(May '01: Proposed Interim Meeting) *(April 6 '01: PCIM Extensions Next Draft) *Jul. 13, '01: PCIM Extensions Final *(Apr 6, '01: QPIM Next Draft) *Jul. 13, '01: QPIM Final *Aug. '01: QPLS *(Apr 27, '01: QDDIM Next Draft) *Jul. 14, '01: QDDIM Final *Aug. '01: last face-to-face wg meeting Detailed Minutes: Ryan Moats: See charts. PCLS: Accepted for last call with some minor modifications: "MUST" changed to "MAY" for naming, and then to LAST CALL as of next week. Ron Cohen: see charts. issues from San Diego: -we need a clear separation between what is defined in QPIM and what is defined in QDDIM -Yoram Bernet did not like the separation between RSVP and DiffServ. Simplification: -intend to use hierarchical rules instead of the explicit resource sharing that was in the current qpim document. Relationship to QDDIM: -removing the queue and meter classes were key, in order to remove confusion with QDDIM Bob Moore: (question to chairs) should we put variables, values, and compound condxs, into pcime, and take them out of qpim? Joel: we need to see the document. dependence will exist. before next ietf. We need a new qpim draft very soon after this meeting, and two revs of the draft before London. Agreed. PCIMe presentation by Bob Moore: see the charts: The assignment was to take experience from modeling qpim, and generalize it, also based on experience in icpm, and mplspim. -urgency recognized -Transactional semantics for action execution: this was rejected and will not be in the next draft (do all or do none) -variables and values: want to apply to actions, as well as conditions -packet filtering in policy conditions: based on variables and values now. The Open Issues in PCIMe: Need working group input. -Lee Rafalow: Rules within rules, and the action of the first rule affects the conditions of the second rule, in the context of the state created by the first rule. You can call it a program counter. Lee thinks it is a mistake. Rule engine is no longer a table, but a interpreter of a language. If we do this, we should just do the whole language thing, and not get half pregnant. -Ron Cohen: we have requirement for both "match all" across multiple rules, and also the req for hierarchy of rules. We can perhaps agree that if the rules change the conditions of following rules evaluation, does that solve the problem. -Joel: nobody has asked for removing match all. Ron is ok with adding text that the evaluation of subsequent rules should not be changed . Joel wants more text describing things very clearly. -Andrea: does rule within rule always create a procedural situation? Andrea says no. Just clarify about the side-effects. -Ron Coehn: wants some flexibility to do hierarchical rules for bandwidth nesting rules. Joel: let's wait for the new text from the authors Implicit and Explicit Variables: Need relative instance identification. Have not figured it out yet. Variables rely on contexts for identifying the instances to examine/modify. For implicit: can overall context lead to different fields? For explict, how to id an instance in an instance-independent way? Ron does not see the need. Joel: as participant: implicit variables are a mistake. Unbounded guessing of the context variables is the wrong answer. Bob: Is it important for the administrator? no. but it is important for the policy engine rule evaluator: the execution engine needs to be told where to find, for example, the ip address Walter: His main concern with implicit variables is that it is a flat, unstructured space, and tempts you to define things in a different way initially and then later re-user may change the semantics without the necessary constraints. Structured data needs to reflect the context for the data. Needs definition. Need new structure or extn of the structure. You want to encourage the crisp definition. Mahadevan Iyer: agrees with ron. wants to specify that it is from the data packet, but not how it is obtained. No resolution for now. Issue 1: dnf/cnf for compound policy conditions -when building compound policy conditions, should we allow the same dnf/cnf logic we have for aggregating policy condtions in a policy rule? Alternative is to allow only ANDing and negation here, no ORing, and no parentheses. -straz: tease out re-usable from this question. the reason this came up was efficiency. say we have source and destination port. this requires two separate objects in the model, which may require two separate accesses. want to avoid overhead. Not just for making it re-usable. don't want to lose function of the full boolean logic that we have in compound condtion. -bob: does this really reduce the complexity? -straz: yes, it reduces the number of associations to the rule. the compound condition is conceptually one object. -lee: how general do we want to make it a general language? we have put re-usability at the core of what we are doing. are we building extensions to solve known problems, like filters, do we need to go farther than that? ron: wants to build something that is re-usable. make it an arbitrary re-usable compound condition, why cripple it that way? guy at mic: EE course for nand gates. You have the logic already, so why restirct urself. you already have it already. they want one level to make it simpler (joel) straz: do we really believe that limiting the condition is simpler, then why arbitrary logic at rule level? bob compromise on this issue? mahedevan iyer: compound condition purpose is to make it more efficient. what makes you think that you can use the and and not, but not the or's. Lee thinks it is a reusable thing. a condition is reusable. a filter is one condition and reusable. filter is the use that lee has in mind. don't need the rest of the logic for a filter. Iyer: its a different result, depending on reusable vs. efficiency. issue 3: Transactional semantics for actions: we think we agreed to pull back from this: do all or do none (involves commit/rollback) the first on the list. Ron: wants to explain what we agreed to: we cannot have the commit and rollback. we are gettng rid of it. does not want to get rid of examining all ahead of time, then if you can't do none, if you don't have to roll back, cuz you know ahead of time not to do it. Joel: if you are free to write the conditions to succeed, then you are free to write the conditions. but how can you tell the policy rule to figure out whether they will succeed or not, ahead of time? Not resolved in this meeting. Session 2, Wednesday 2nd policy session: Issue 4: Packet Filtering are we going to recommend a way to do modeling of packet filtering? (MUST or SHOULD?) Lee: suggests we do make recommendation and say SHOULD. Before we said if you use policy classes, you should use variable and value. Let's slice it differently. Let's say device level model use filter entry mechanism, and domain level model use variable and value approach. author of ipsp policy mib: first part of this is all generic not specific to ipsp. much more useful to have this working group set a recommended way to represeent this, but we may need to go beyond the 5-tuple. ed: keep it extendable, but do the draft based on ipsec policy and qos policy requirements. bob agrees: no dissenters Issue 5: Prohibit Equal Priority Values -pcime makes three changes to pcim for priorites for rules. most major change is to prohibit equal priorities, because it introduces indeterminate behavior. -forces an admin to go ahead and pick a priority, even if he/she does not care. -no dissenters Issue 6: MATCH and SET Semantics -In SimplePolicyCondition, the MATCH operator is currently implicit and overloaded. but what does "MATCH" mean? flexibility is too great maybe? Marcus: wants more explicit statement of what is going on with the match. the implementation is complex enough. You need to have a clear statement of what operator means what? Eric Fleischman: (Boeing) as end user, they like this. informal policy statement would be great. the implementation is harder. Bob:is this past what the implentors can do to get right? Marcus: at least define the operators and the objects.Marcus can write this up. Good! Issue 7: representation of policy values? like ip addresses. Marcus sees problems with the match again. 32 bit match for ipv4. different match for ipv6. also depends on string vs. integer. Have to convert to an integer to compare. m.iyer: wants determinism on type of value. reduce the ambiguity marcus: its like the filters. top level spec of filters and device level spec of filters. it is different but interchangeable. depends on where it is. device or domain. bob: the two are not independent. strings in pcime. more strictly typed in device level? joel : we are talking about the string that the user types in. why not let the user put in one or the other, and let the syntax determine it. comment: jeff wheeler: pattern matches require keeping it native in the format. no resolution. on list issue 9: rule priority in disjoint policy sets: how to prioritize two rules/groups that don't share a common aggregation tree? no answer to this now. open work item. M. Iyer: policy consumer (pdp) from two diff policy trees. he suggests having pdp having a policy for each tree. Bob: How do we represent this in the model is the problem? Eric Fleischman: what about scoping the policy? he has seen an implicit convention for this, in the tools he has played with. QDDIM: Status: see charts and new charter milestones name change: now qos device datapath info model: because intserv/diffserv have same data path elements what about QOSService: this identifies diffserv? maybe don't need them here. modeling schedulers and queues: yellow boxes by walter need to be worked into the model alignment with diffserv: mib, pib and informal model: meetings this week to finalize. expect diffserv wg last call very soon. that means we need to pass thru and re-align to any changes ipsec policy: lee rafalow reviewed same charts that he went thru with ipsp working group. ipsp info model will be updated to represent the "musts" for IKE key point: filter representation they won't wait for pcime. they will factor in the ideas per their expectations of pcime. other than that, it is based on pcim. Bob asked Andrea: snmp conf policy mib: couple of uses of policy action and another term. Will ask policy filter and policy action review by Steve Waldbusser, who is polterm liaison for snmpconf For other agenda items, please see the charts. Minutes taker: Ed Ellesson From majordomo@raleigh.ibm.com Mon Apr 16 12:11:51 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07536 for ; Mon, 16 Apr 2001 12:11:50 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA21260; Mon, 16 Apr 2001 12:04:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA28688; Mon, 16 Apr 2001 12:03:16 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31020; Mon, 16 Apr 2001 11:28:35 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45088; Mon, 16 Apr 2001 11:28:31 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32936 for ; Mon, 16 Apr 2001 11:28:31 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA27626 for ; Mon, 16 Apr 2001 11:28:30 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Apr 2001 11:28:17 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Cc: Ed Ellesson , "'Joel M. Halpern'" Subject: WG Last Call on draft-ietf-policy-core-schema-10.txt Date: Mon, 16 Apr 2001 11:28:16 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson The latest revision of the Policy Framework LDAP Core Schema is in the I-D repository. This revision reflects all known issues and comments. This note commences a two week working group last call, intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for approval as a proposed standard. This last call ends at CoB on Mon, April 30. Thank you, Joel M. Halpern w/ Ed Ellesson From majordomo@raleigh.ibm.com Wed Apr 18 13:38:07 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14720 for ; Wed, 18 Apr 2001 13:38:06 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA20854; Wed, 18 Apr 2001 13:30:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA30068; Wed, 18 Apr 2001 13:30:09 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34178; Wed, 18 Apr 2001 12:55:39 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54138; Wed, 18 Apr 2001 12:55:36 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA29196 for ; Wed, 18 Apr 2001 12:55:39 -0400 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 MAA28948 for ; Wed, 18 Apr 2001 12:55:33 -0400 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 MAA19311; Wed, 18 Apr 2001 12:29:22 -0400 (EDT) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 18 Apr 2001 16:29:22 UT Received: from mears.indy.cr.irs.gov (mailhub-2 [10.7.8.10]) by mailhub-2.net.treas.gov (8.9.1b+Sun/8.9.3) with ESMTP id MAA09621; Wed, 18 Apr 2001 12:28:52 -0400 (EDT) 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 LAA16912; Wed, 18 Apr 2001 11:29:14 -0500 Message-Id: <3ADDC0DA.40DD504C@parnelli.indy.cr.irs.gov> Date: Wed, 18 Apr 2001 11:29:14 -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: Mircea Pana Cc: IETF Policy Subject: schema-10 Last Call and Re: PCLS: ptpContitionTime References: <3AD22BA4.6688E1D8@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" Content-Transfer-Encoding: 7bit Since draft-ietf-policy-core-schema-10.txt is the "Last Call", would the authors please ACK this issue and address it? on Mon, 09 Apr 2001 17:37:40 -0400, Mircea Pana wrote: > > The attribute "ptpConditionTime" doesn't allow "SUBSTR > caseIgnoreSubstringsMatch". IMO the substring matching rule should be > added to this attribute as well (like it is for > "ptpConditionTimeOfDay"). This enables a policy server to select or > (partially) validate ptpConditionAuxClass instances by setting the > appropriate criteria in the LDAP search filter. > > Regards, > Mircea. -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From majordomo@raleigh.ibm.com Wed Apr 18 14:54:48 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15859 for ; Wed, 18 Apr 2001 14:54:47 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA24532; Wed, 18 Apr 2001 14:44:12 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA30802; Wed, 18 Apr 2001 14:44:12 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35776; Wed, 18 Apr 2001 14:11:02 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA65972; Wed, 18 Apr 2001 14:10:59 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA19174 for ; Wed, 18 Apr 2001 14:11:02 -0400 From: moats@tconl.com Received: from hermes.tconl.com (mail.tconl.com [204.26.80.9]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA08172 for ; Wed, 18 Apr 2001 14:11:00 -0400 Received: from 10.9.200.11 ([10.100.0.124]) by hermes.tconl.com (8.11.0/TeleChoice) with SMTP id f3IIAuq28641 for ; Wed, 18 Apr 2001 13:10:56 -0500 Message-Id: <200104181810.f3IIAuq28641@hermes.tconl.com> To: IETF Policy Subject: re: schema-10 Last Call and Re: PCLS: ptpContitionTime Date: 18 Apr 2001 13:03:16 -0600 X-Mailer: NeoPlanet Version: 5.2.0.1702 X-Id: CFC0538004D911D5A37A0080AD732513 X-Brand: NeoPlanet X-Build: 1702 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: moats@tconl.com This looks like a good suggestion and we will add it. Ryan > > Since draft-ietf-policy-core-schema-10.txt is the "Last Call", would > the authors please ACK this issue and address it? > > on Mon, 09 Apr 2001 17:37:40 -0400, Mircea Pana wrote: > > > > The attribute "ptpConditionTime" doesn't allow "SUBSTR > > caseIgnoreSubstringsMatch". IMO the substring matching rule should be > > added to this attribute as well (like it is for > > "ptpConditionTimeOfDay"). This enables a policy server to select or > > (partially) validate ptpConditionAuxClass instances by setting the > > appropriate criteria in the LDAP search filter. > > > > Regards, > > Mircea. > > -- > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| > # 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 | | > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| >** --------- End Original Message ----------- ** > From majordomo@raleigh.ibm.com Wed Apr 18 16:34:00 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17468 for ; Wed, 18 Apr 2001 16:34:00 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA06292; Wed, 18 Apr 2001 16:27:28 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA32826; Wed, 18 Apr 2001 16:27:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA73236; Wed, 18 Apr 2001 15:50:56 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA80652; Wed, 18 Apr 2001 15:50:53 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA33482 for ; Wed, 18 Apr 2001 15:50:57 -0400 Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA21256 for ; Wed, 18 Apr 2001 15:50:54 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 18 Apr 2001 15:49:58 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JASK4Z8J; Wed, 18 Apr 2001 15:49:57 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8VPK; Wed, 18 Apr 2001 15:50:00 -0400 Message-Id: <3ADDEF63.385D95FC@americasm01.nt.com> Date: Wed, 18 Apr 2001 15:47:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: criticality of extended conditions and actions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit PCIM/PCLS recommend the specialization of the policyCondition and policyAction as the preferred extension mechanism for creating domain-specific models and schema. However, it is unclear how a PDP/PEP should behave when it encounters an unknown/unsupported element. For example let's say that an IPSec specific policyAction is present in a policyRule loaded by a QPIM capable PDP/PEP. Should this action be ignored or should it be considered as failed? The way we interpret such situations may affect execution of the other actions (see PCIMe execution strategy). A similar situation can occur in with groups of heterogeneous policyRules. I would suggest the addition (to policyCondition and policyAction in PCIMe) of a "Criticality" property in order to allow an administratively controlled behavior: - a critical unknown/unsupported condition is evaluated FALSE. - a critical unknown/unsupported action is considered Failed. - a non-critical condition or action is ignored. Thanks, Mircea. From majordomo@raleigh.ibm.com Thu Apr 19 05:44:47 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09419 for ; Thu, 19 Apr 2001 05:44:45 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA28046; Thu, 19 Apr 2001 05:36:20 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA30738; Thu, 19 Apr 2001 05:36:16 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53292; Thu, 19 Apr 2001 05:01:17 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32956; Thu, 19 Apr 2001 05:01:11 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA35674 for ; Thu, 19 Apr 2001 05:01:12 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA24760 for ; Thu, 19 Apr 2001 05:01:03 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3J90we75171; Thu, 19 Apr 2001 11:00:58 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id EAD26C054; Thu, 19 Apr 2001 12:07:31 +0200 (CEST) Date: Thu, 19 Apr 2001 11:03:28 +0200 From: Marcus Brunner To: Mircea Pana Cc: IETF Policy Subject: Re: criticality of extended conditions and actions Message-Id: <4130697647.987678208@[192.168.102.79]> In-Reply-To: <3ADDEF63.385D95FC@americasm01.nt.com> X-Mailer: Mulberry/2.0.6 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit --On Wednesday, April 18, 2001 3:47 PM -0400 Mircea Pana wrote: > PCIM/PCLS recommend the specialization of the policyCondition and > policyAction as the preferred extension mechanism for creating > domain-specific models and schema. > > However, it is unclear how a PDP/PEP should behave when it encounters an > unknown/unsupported element. For example let's say that an IPSec > specific policyAction is present in a policyRule loaded by a QPIM > capable PDP/PEP. Should this action be ignored or should it be > considered as failed? The way we interpret such situations may affect > execution of the other actions (see PCIMe execution strategy). A similar > situation can occur in with groups of heterogeneous policyRules. You used the wording IPSec specific policyAction is present in a policyRule loaded by a QPIM capable PDP/PEP". I think in most cases the loading already should encounter the problem. So it is not a matter of the execution engine. My proposel is that the loading of the whole rule fails. Marcus > > I would suggest the addition (to policyCondition and policyAction in > PCIMe) of a "Criticality" property in order to allow an administratively > controlled behavior: > - a critical unknown/unsupported condition is evaluated FALSE. > - a critical unknown/unsupported action is considered Failed. > - a non-critical condition or action is ignored. > > Thanks, > Mircea. > -------------------------------------- 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 Thu Apr 19 12:16:07 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13784 for ; Thu, 19 Apr 2001 12:16:06 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA28352; Thu, 19 Apr 2001 12:09:13 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA33702; Thu, 19 Apr 2001 12:09:10 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA80212; Thu, 19 Apr 2001 11:33:36 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA108604; Thu, 19 Apr 2001 11:33:32 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA29594 for ; Thu, 19 Apr 2001 11:33:36 -0400 Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA07050 for ; Thu, 19 Apr 2001 11:33:33 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Thu, 19 Apr 2001 11:28:08 -0400 Received: from zcard04n.ca.nortel.com (ZCARD04N [47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSWN42P; Thu, 19 Apr 2001 11:27:47 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8WHF; Thu, 19 Apr 2001 11:27:25 -0400 Message-Id: <3ADF0352.41C4E6F2@americasm01.nt.com> Date: Thu, 19 Apr 2001 11:25:06 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: <4130697647.987678208@[192.168.102.79]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit The loading doesn't necessarily fail in case of vendorCondition or vendorAction. Also, a PDP may support a specific types of conditions or actions which are not supported by some of the PEPs served by this PDP (PEP has limited capability). IMO, the loading of a policyRule with unsupported components should not fail. The condition(s) evaluation and action(s) execution should fail if critical components are unsupported. However, if the recommended behavior is to fail on loading rules that contain unsupported components, then this should be explicitly added to PCIMe. In that case: 1. the policyRule becomes an aggregation of homogenous, domain [and optionally version] specific conditions and actions - this has serious implications on the domain independence of the policyRule concept. 2. a mechanism should be added for improving the detection of the policyRule specificity. Otherwise, one may have to "dig deep down" through compound structures to find whether the rule is supported or not. 3. the decision strategy for policyGroups with unsupported policyRules should be defined as well. I believe that the criticality flag is more valuable and it contributes to the * heterogeneous * aspect of the policy framework stated among the WG objectives. Regards, Mircea. Marcus Brunner wrote: > > --On Wednesday, April 18, 2001 3:47 PM -0400 Mircea Pana > wrote: > > > PCIM/PCLS recommend the specialization of the policyCondition and > > policyAction as the preferred extension mechanism for creating > > domain-specific models and schema. > > > > However, it is unclear how a PDP/PEP should behave when it encounters an > > unknown/unsupported element. For example let's say that an IPSec > > specific policyAction is present in a policyRule loaded by a QPIM > > capable PDP/PEP. Should this action be ignored or should it be > > considered as failed? The way we interpret such situations may affect > > execution of the other actions (see PCIMe execution strategy). A similar > > situation can occur in with groups of heterogeneous policyRules. > > You used the wording IPSec specific policyAction is present in a policyRule > loaded by a QPIM capable PDP/PEP". I think in most cases the loading > already should encounter the problem. So it is not a matter of the > execution engine. > > My proposel is that the loading of the whole rule fails. > > Marcus > > > > > I would suggest the addition (to policyCondition and policyAction in > > PCIMe) of a "Criticality" property in order to allow an administratively > > controlled behavior: > > - a critical unknown/unsupported condition is evaluated FALSE. > > - a critical unknown/unsupported action is considered Failed. > > - a non-critical condition or action is ignored. > > > > Thanks, > > Mircea. > > > > -------------------------------------- > 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 Thu Apr 19 12:29:11 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13969 for ; Thu, 19 Apr 2001 12:29:10 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA23730; Thu, 19 Apr 2001 12:21:35 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA26854; Thu, 19 Apr 2001 12:21:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA98522; Thu, 19 Apr 2001 11:45:56 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA72388; Thu, 19 Apr 2001 11:45:52 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27462 for ; Thu, 19 Apr 2001 11:45:55 -0400 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 LAA21774 for ; Thu, 19 Apr 2001 11:45:52 -0400 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 f3JFidA10967; Thu, 19 Apr 2001 11:44:39 -0400 (EDT) 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 LAA19082; Thu, 19 Apr 2001 11:44:38 -0400 (EDT) Message-Id: <200104191544.LAA19082@monday.research.telcordia.com> Date: Thu, 19 Apr 2001 11:44:38 -0400 (EDT) From: Ritu Chadha Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt To: policy@raleigh.ibm.com Cc: eellesson@lboard.com, joel@longsys.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: j846l39YikeC3NpwjqxPuQ== 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 Error in Section 5.5 of the Policy Core LDAP Schema: The document lists policyConditionName as a possible naming attribute for the class policyRuleValidityAssociation, when in fact the attribute policyConditionName is not an attribute of this class. I believe the naming attribute here should be policyValidityConditionName, not policyConditionName. Ritu >From: Ed Ellesson >To: "'policy@raleigh.ibm.com'" >Cc: Ed Ellesson , "'Joel M. Halpern'" >Subject: WG Last Call on draft-ietf-policy-core-schema-10.txt >Date: Mon, 16 Apr 2001 11:28:16 -0400 >Mime-Version: 1.0 > >The latest revision of the Policy Framework LDAP Core Schema is in the I-D >repository. This revision reflects all known issues and comments. >This note commences a two week working group last call, intended to bring >forth any last issues. After such issues are resolved according to the >working group consensus, we will be submitting this document to the IESG >for approval as a proposed standard. > >This last call ends at CoB on Mon, April 30. > >Thank you, >Joel M. Halpern >w/ Ed Ellesson > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Thu Apr 19 15:05:24 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16590 for ; Thu, 19 Apr 2001 15:05:23 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA21712; Thu, 19 Apr 2001 14:55:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA27256; Thu, 19 Apr 2001 14:55:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA102146; Thu, 19 Apr 2001 13:07:15 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA131578; Thu, 19 Apr 2001 13:07:12 -0400 Received: from lmr (dyn9-37-48-225.raleigh.ibm.com [9.37.48.225]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA27466 for ; Thu, 19 Apr 2001 13:07:16 -0400 Message-Id: <008201c0c8f2$c1c92680$e1302509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <4130697647.987678208@[192.168.102.79]> <3ADF0352.41C4E6F2@americasm01.nt.com> Subject: Re: criticality of extended conditions and actions Date: Thu, 19 Apr 2001 13:04:09 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit I'm not sure I understand the utility of having conditions and actions flagged as optional or required (i.e., not critical and critical, respectively). If a condition is truly optional there are two ways to handle it in the current model: 1) exclude it, or 2) have a second, lower priority rule that excludes it (most likely with a different action). That is, the model only supports required conditions (and, I personally, don't understand optional conditions). For actions, we've already discussed and dismissed (at least for the time being) the notion that we can specify recovery behavior (the transactional support discussed last meeting). You can think of it as only supporting optional actions at this point because the behavior when a failure occurs is submodel and/or implementation dependent. I tend to agree with Marcus that rules that contain conditions or actions for which there is no semantic routine should be rejected. If the analog of a compiler fits (and I think it does) then it can be argued that the whole policy should be rejected (compilation error) since a single missing rule may dramatically change the network behavior. Actually, I think we should have text that says the policy MUST be rejected. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com ----- Original Message ----- From: "Mircea Pana" To: "IETF Policy" Sent: Thursday, April 19, 2001 11:25 AM Subject: Re: criticality of extended conditions and actions > The loading doesn't necessarily fail in case of vendorCondition or > vendorAction. Also, a PDP may support a specific types of conditions or > actions which are not supported by some of the PEPs served by this PDP > (PEP has limited capability). > IMO, the loading of a policyRule with unsupported components should not > fail. The condition(s) evaluation and action(s) execution should fail if > critical components are unsupported. > > However, if the recommended behavior is to fail on loading rules that > contain unsupported components, then this should be explicitly added to > PCIMe. In that case: > 1. the policyRule becomes an aggregation of homogenous, domain [and > optionally version] specific conditions and actions - this has serious > implications on the domain independence of the policyRule concept. > 2. a mechanism should be added for improving the detection of the > policyRule specificity. Otherwise, one may have to "dig deep down" > through compound structures to find whether the rule is supported or > not. > 3. the decision strategy for policyGroups with unsupported policyRules > should be defined as well. > > I believe that the criticality flag is more valuable and it contributes > to the * heterogeneous * aspect of the policy framework stated among the > WG objectives. > > Regards, > Mircea. > > > > Marcus Brunner wrote: > > > > --On Wednesday, April 18, 2001 3:47 PM -0400 Mircea Pana > > wrote: > > > > > PCIM/PCLS recommend the specialization of the policyCondition and > > > policyAction as the preferred extension mechanism for creating > > > domain-specific models and schema. > > > > > > However, it is unclear how a PDP/PEP should behave when it encounters an > > > unknown/unsupported element. For example let's say that an IPSec > > > specific policyAction is present in a policyRule loaded by a QPIM > > > capable PDP/PEP. Should this action be ignored or should it be > > > considered as failed? The way we interpret such situations may affect > > > execution of the other actions (see PCIMe execution strategy). A similar > > > situation can occur in with groups of heterogeneous policyRules. > > > > You used the wording IPSec specific policyAction is present in a policyRule > > loaded by a QPIM capable PDP/PEP". I think in most cases the loading > > already should encounter the problem. So it is not a matter of the > > execution engine. > > > > My proposel is that the loading of the whole rule fails. > > > > Marcus > > > > > > > > I would suggest the addition (to policyCondition and policyAction in > > > PCIMe) of a "Criticality" property in order to allow an administratively > > > controlled behavior: > > > - a critical unknown/unsupported condition is evaluated FALSE. > > > - a critical unknown/unsupported action is considered Failed. > > > - a non-critical condition or action is ignored. > > > > > > Thanks, > > > Mircea. > > > > > > > -------------------------------------- > > 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 Thu Apr 19 15:33:25 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17238 for ; Thu, 19 Apr 2001 15:33:23 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA09344; Thu, 19 Apr 2001 15:23:11 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA36034; Thu, 19 Apr 2001 15:21:29 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46882; Thu, 19 Apr 2001 14:53:13 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43798; Thu, 19 Apr 2001 14:53:10 -0400 Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA10022 for ; Thu, 19 Apr 2001 14:53:15 -0400 Received: from d04nm200nm300.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay01.raleigh.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA46726; Thu, 19 Apr 2001 14:52:57 -0400 Importance: Normal Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt To: Ritu Chadha Cc: policy@raleigh.ibm.com, eellesson@lboard.com, joel@longsys.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Thu, 19 Apr 2001 15:01:19 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 04/19/2001 02:52:58 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Ritu, You're absolutely right. We'll have to fix this as you suggest before we submit the draft to the IESG. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Ritu Chadha @raleigh.ibm.com on 04/19/2001 11:44:38 AM Please respond to Ritu Chadha Sent by: policy-owner@raleigh.ibm.com To: policy@raleigh.ibm.com cc: eellesson@lboard.com, joel@longsys.com Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt Error in Section 5.5 of the Policy Core LDAP Schema: The document lists policyConditionName as a possible naming attribute for the class policyRuleValidityAssociation, when in fact the attribute policyConditionName is not an attribute of this class. I believe the naming attribute here should be policyValidityConditionName, not policyConditionName. Ritu >From: Ed Ellesson >To: "'policy@raleigh.ibm.com'" >Cc: Ed Ellesson , "'Joel M. Halpern'" >Subject: WG Last Call on draft-ietf-policy-core-schema-10.txt >Date: Mon, 16 Apr 2001 11:28:16 -0400 >Mime-Version: 1.0 > >The latest revision of the Policy Framework LDAP Core Schema is in the I-D >repository. This revision reflects all known issues and comments. >This note commences a two week working group last call, intended to bring >forth any last issues. After such issues are resolved according to the >working group consensus, we will be submitting this document to the IESG >for approval as a proposed standard. > >This last call ends at CoB on Mon, April 30. > >Thank you, >Joel M. Halpern >w/ Ed Ellesson > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Thu Apr 19 15:50:03 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17541 for ; Thu, 19 Apr 2001 15:50:02 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA32772; Thu, 19 Apr 2001 15:44:03 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA27656; Thu, 19 Apr 2001 15:43:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43948; Thu, 19 Apr 2001 15:09:28 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43798; Thu, 19 Apr 2001 14:53:10 -0400 Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA10022 for ; Thu, 19 Apr 2001 14:53:15 -0400 Received: from d04nm200nm300.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay01.raleigh.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id OAA46726; Thu, 19 Apr 2001 14:52:57 -0400 Importance: Normal Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt To: Ritu Chadha Cc: policy@raleigh.ibm.com, eellesson@lboard.com, joel@longsys.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Thu, 19 Apr 2001 15:01:19 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 04/19/2001 02:52:58 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Ritu, You're absolutely right. We'll have to fix this as you suggest before we submit the draft to the IESG. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Ritu Chadha @raleigh.ibm.com on 04/19/2001 11:44:38 AM Please respond to Ritu Chadha Sent by: policy-owner@raleigh.ibm.com To: policy@raleigh.ibm.com cc: eellesson@lboard.com, joel@longsys.com Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt Error in Section 5.5 of the Policy Core LDAP Schema: The document lists policyConditionName as a possible naming attribute for the class policyRuleValidityAssociation, when in fact the attribute policyConditionName is not an attribute of this class. I believe the naming attribute here should be policyValidityConditionName, not policyConditionName. Ritu >From: Ed Ellesson >To: "'policy@raleigh.ibm.com'" >Cc: Ed Ellesson , "'Joel M. Halpern'" >Subject: WG Last Call on draft-ietf-policy-core-schema-10.txt >Date: Mon, 16 Apr 2001 11:28:16 -0400 >Mime-Version: 1.0 > >The latest revision of the Policy Framework LDAP Core Schema is in the I-D >repository. This revision reflects all known issues and comments. >This note commences a two week working group last call, intended to bring >forth any last issues. After such issues are resolved according to the >working group consensus, we will be submitting this document to the IESG >for approval as a proposed standard. > >This last call ends at CoB on Mon, April 30. > >Thank you, >Joel M. Halpern >w/ Ed Ellesson > ============================================================================= Ritu Chadha Director Service Management Research Telcordia Technologies (973) 829-4869 (voice) MCC 1A-216R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Thu Apr 19 22:31:29 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22731 for ; Thu, 19 Apr 2001 22:31:28 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA26424; Thu, 19 Apr 2001 22:25:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA34006; Thu, 19 Apr 2001 22:25:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA129860; Thu, 19 Apr 2001 21:47:47 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA121660; Thu, 19 Apr 2001 21:47:43 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA34638; Thu, 19 Apr 2001 21:47:49 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA19478; Thu, 19 Apr 2001 21:47:47 -0400 Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA13004; Thu, 19 Apr 2001 18:47:44 -0700 (PDT) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id AGY01324; Thu, 19 Apr 2001 18:47:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20010419184032.00b279a0@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Apr 2001 18:47:06 -0700 To: "Lee Rafalow" From: John Strassner Subject: Re: criticality of extended conditions and actions Cc: "IETF Policy" In-Reply-To: <008201c0c8f2$c1c92680$e1302509@raleigh.ibm.com> References: <4130697647.987678208@[192.168.102.79]> <3ADF0352.41C4E6F2@americasm01.nt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Strassner I have to agree with Lee here. I also don't understand the purpose or benefit of an optional condition as a dedicated construct instead of simply splitting the rule into multiple rules or even sub-rules. I also don't understand the following statement of yours: > > IMO, the loading of a policyRule with unsupported components should not > > fail. If the component is unsupported, how can the policyRule even be evaluated? I think that it has to fail (note that rejection is another form of failing). I also don't see the need for adding this to PCIMe. You seem to be arguing that the policyRule is itself an aggregation of different conditions and actions that have different scopes and/or administrative domains. I'm unconvinced that we even have a use case for this, and even if there is one, I think that if the components of a policyRule are really that different, you're overloading the policyRule and it should be split into multiple rules. I'd suggest you provide a detailed use case that clearly shows the benefits of optional rules and aggregating components that affect different PEPs or have different scopes. In doing that, I'd also be appreciative of you showing why existing constructs fail. regards, John At 01:04 PM 4/19/2001 -0400, Lee Rafalow wrote: >I'm not sure I understand the utility of having conditions and actions >flagged as optional or required (i.e., not critical and critical, >respectively). > >If a condition is truly optional there are two ways to handle it in the >current model: 1) exclude it, or 2) have a second, lower priority rule that >excludes it (most likely with a different action). That is, the model only >supports required conditions (and, I personally, don't understand optional >conditions). > >For actions, we've already discussed and dismissed (at least for the time >being) the notion that we can specify recovery behavior (the transactional >support discussed last meeting). You can think of it as only supporting >optional actions at this point because the behavior when a failure occurs is >submodel and/or implementation dependent. > >I tend to agree with Marcus that rules that contain conditions or actions >for which there is no semantic routine should be rejected. If the analog of >a compiler fits (and I think it does) then it can be argued that the whole >policy should be rejected (compilation error) since a single missing rule >may dramatically change the network behavior. Actually, I think we should >have text that says the policy MUST be rejected. > > >Lee M. Rafalow >Voice: 1-919-254-4455; Fax: 1-919-254-6243 >IBM Internet Technology Management >IBM Corporation >P.O. Box 12195, BRQA/502 >RTP, NC 27709 USA >Alternate email: rafalow@us.ibm.com >Home email: rafalow@mindspring.com >----- Original Message ----- >From: "Mircea Pana" >To: "IETF Policy" >Sent: Thursday, April 19, 2001 11:25 AM >Subject: Re: criticality of extended conditions and actions > > > > The loading doesn't necessarily fail in case of vendorCondition or > > vendorAction. Also, a PDP may support a specific types of conditions or > > actions which are not supported by some of the PEPs served by this PDP > > (PEP has limited capability). > > IMO, the loading of a policyRule with unsupported components should not > > fail. The condition(s) evaluation and action(s) execution should fail if > > critical components are unsupported. > > > > However, if the recommended behavior is to fail on loading rules that > > contain unsupported components, then this should be explicitly added to > > PCIMe. In that case: > > 1. the policyRule becomes an aggregation of homogenous, domain [and > > optionally version] specific conditions and actions - this has serious > > implications on the domain independence of the policyRule concept. > > 2. a mechanism should be added for improving the detection of the > > policyRule specificity. Otherwise, one may have to "dig deep down" > > through compound structures to find whether the rule is supported or > > not. > > 3. the decision strategy for policyGroups with unsupported policyRules > > should be defined as well. > > > > I believe that the criticality flag is more valuable and it contributes > > to the * heterogeneous * aspect of the policy framework stated among the > > WG objectives. > > > > Regards, > > Mircea. > > > > > > > > Marcus Brunner wrote: > > > > > > --On Wednesday, April 18, 2001 3:47 PM -0400 Mircea Pana > > > wrote: > > > > > > > PCIM/PCLS recommend the specialization of the policyCondition and > > > > policyAction as the preferred extension mechanism for creating > > > > domain-specific models and schema. > > > > > > > > However, it is unclear how a PDP/PEP should behave when it encounters >an > > > > unknown/unsupported element. For example let's say that an IPSec > > > > specific policyAction is present in a policyRule loaded by a QPIM > > > > capable PDP/PEP. Should this action be ignored or should it be > > > > considered as failed? The way we interpret such situations may affect > > > > execution of the other actions (see PCIMe execution strategy). A >similar > > > > situation can occur in with groups of heterogeneous policyRules. > > > > > > You used the wording IPSec specific policyAction is present in a >policyRule > > > loaded by a QPIM capable PDP/PEP". I think in most cases the loading > > > already should encounter the problem. So it is not a matter of the > > > execution engine. > > > > > > My proposel is that the loading of the whole rule fails. > > > > > > Marcus > > > > > > > > > > > I would suggest the addition (to policyCondition and policyAction in > > > > PCIMe) of a "Criticality" property in order to allow an >administratively > > > > controlled behavior: > > > > - a critical unknown/unsupported condition is evaluated FALSE. > > > > - a critical unknown/unsupported action is considered Failed. > > > > - a non-critical condition or action is ignored. > > > > > > > > Thanks, > > > > Mircea. > > > > > > > > > > -------------------------------------- > > > 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 Apr 20 05:24:39 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09326 for ; Fri, 20 Apr 2001 05:24:38 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA27120; Fri, 20 Apr 2001 05:16:05 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA30034; Fri, 20 Apr 2001 05:16:01 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61614; Fri, 20 Apr 2001 04:33:16 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA72590; Fri, 20 Apr 2001 04:33:09 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA30570; Fri, 20 Apr 2001 04:33:10 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA06984; Fri, 20 Apr 2001 04:33:06 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3K8WMe04705; Fri, 20 Apr 2001 10:32:22 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D959BC095; Fri, 20 Apr 2001 11:38:54 +0200 (CEST) Date: Fri, 20 Apr 2001 10:34:52 +0200 From: Marcus Brunner To: Lee Rafalow , IETF Policy , Mircea Pana Subject: Re: criticality of extended conditions and actions Message-Id: <4215381584.987762892@[192.168.102.79]> In-Reply-To: <008201c0c8f2$c1c92680$e1302509@raleigh.ibm.com> X-Mailer: Mulberry/2.0.6 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Lee, Mircea, I am not happy with the proposed solution, nevertheless we need to deal with the problem of "unsupported" or "optional" elements in a policy rule. What does exclude a condition mean (Lees first handling)? replace it by FALSE, by TRUE? or skip it? The second question is what entity detects a policy with unsupported conditions and actions? And at what point in the policy lifecycle it is/needs to be detected? 1) policy definition language to LDAP translator detects it (needs to know what policy engine is used) 2) at load time of policies from a database into the execution engine 3) at run-time, execution engine fails evaluating a condition or performing an action, because it is not known. Marcus --On Thursday, April 19, 2001 1:04 PM -0400 Lee Rafalow wrote: > I'm not sure I understand the utility of having conditions and actions > flagged as optional or required (i.e., not critical and critical, > respectively). > > If a condition is truly optional there are two ways to handle it in the > current model: 1) exclude it, or 2) have a second, lower priority rule > that excludes it (most likely with a different action). That is, the > model only supports required conditions (and, I personally, don't > understand optional conditions). > > For actions, we've already discussed and dismissed (at least for the time > being) the notion that we can specify recovery behavior (the transactional > support discussed last meeting). You can think of it as only supporting > optional actions at this point because the behavior when a failure occurs > is submodel and/or implementation dependent. > > I tend to agree with Marcus that rules that contain conditions or actions > for which there is no semantic routine should be rejected. If the analog > of a compiler fits (and I think it does) then it can be argued that the > whole policy should be rejected (compilation error) since a single > missing rule may dramatically change the network behavior. Actually, I > think we should have text that says the policy MUST be rejected. > > > Lee M. Rafalow > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > IBM Internet Technology Management > IBM Corporation > P.O. Box 12195, BRQA/502 > RTP, NC 27709 USA > Alternate email: rafalow@us.ibm.com > Home email: rafalow@mindspring.com > ----- Original Message ----- > From: "Mircea Pana" > To: "IETF Policy" > Sent: Thursday, April 19, 2001 11:25 AM > Subject: Re: criticality of extended conditions and actions > > >> The loading doesn't necessarily fail in case of vendorCondition or >> vendorAction. Also, a PDP may support a specific types of conditions or >> actions which are not supported by some of the PEPs served by this PDP >> (PEP has limited capability). >> IMO, the loading of a policyRule with unsupported components should not >> fail. The condition(s) evaluation and action(s) execution should fail if >> critical components are unsupported. >> >> However, if the recommended behavior is to fail on loading rules that >> contain unsupported components, then this should be explicitly added to >> PCIMe. In that case: >> 1. the policyRule becomes an aggregation of homogenous, domain [and >> optionally version] specific conditions and actions - this has serious >> implications on the domain independence of the policyRule concept. >> 2. a mechanism should be added for improving the detection of the >> policyRule specificity. Otherwise, one may have to "dig deep down" >> through compound structures to find whether the rule is supported or >> not. >> 3. the decision strategy for policyGroups with unsupported policyRules >> should be defined as well. >> >> I believe that the criticality flag is more valuable and it contributes >> to the * heterogeneous * aspect of the policy framework stated among the >> WG objectives. >> >> Regards, >> Mircea. >> >> >> >> Marcus Brunner wrote: >> > >> > --On Wednesday, April 18, 2001 3:47 PM -0400 Mircea Pana >> > wrote: >> > >> > > PCIM/PCLS recommend the specialization of the policyCondition and >> > > policyAction as the preferred extension mechanism for creating >> > > domain-specific models and schema. >> > > >> > > However, it is unclear how a PDP/PEP should behave when it encounters > an >> > > unknown/unsupported element. For example let's say that an IPSec >> > > specific policyAction is present in a policyRule loaded by a QPIM >> > > capable PDP/PEP. Should this action be ignored or should it be >> > > considered as failed? The way we interpret such situations may affect >> > > execution of the other actions (see PCIMe execution strategy). A > similar >> > > situation can occur in with groups of heterogeneous policyRules. >> > >> > You used the wording IPSec specific policyAction is present in a > policyRule >> > loaded by a QPIM capable PDP/PEP". I think in most cases the loading >> > already should encounter the problem. So it is not a matter of the >> > execution engine. >> > >> > My proposel is that the loading of the whole rule fails. >> > >> > Marcus >> > >> > > >> > > I would suggest the addition (to policyCondition and policyAction in >> > > PCIMe) of a "Criticality" property in order to allow an > administratively >> > > controlled behavior: >> > > - a critical unknown/unsupported condition is evaluated FALSE. >> > > - a critical unknown/unsupported action is considered Failed. >> > > - a non-critical condition or action is ignored. >> > > >> > > Thanks, >> > > Mircea. From majordomo@raleigh.ibm.com Fri Apr 20 10:16:45 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12242 for ; Fri, 20 Apr 2001 10:16:44 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA27238; Fri, 20 Apr 2001 10:03:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA29976; Fri, 20 Apr 2001 10:02:11 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA110838; Fri, 20 Apr 2001 09:09:08 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA74212; Fri, 20 Apr 2001 09:09:04 -0400 Received: from lmr (dyn9-37-48-225.raleigh.ibm.com [9.37.48.225]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA38002 for ; Fri, 20 Apr 2001 09:09:06 -0400 Message-Id: <003e01c0c99a$aa26f400$e1302509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <4215381584.987762892@[192.168.102.79]> Subject: Re: criticality of extended conditions and actions Date: Fri, 20 Apr 2001 09:06:07 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Marcus, > I am not happy with the proposed solution, nevertheless we need to deal > with the problem of "unsupported" or "optional" elements in a policy rule. > > What does exclude a condition mean (Lees first handling)? replace it by > FALSE, by TRUE? or skip it? What I meant by "exclude it" is that if a policy author intends a condition to be "optional" then the author should just exclude the condition (because I don't understand an optional condition). I do not think that there is ANY machine interpretation for a condition for which there is no syntax or semantics. It's the same as telling a compiler that you want it generate code for a nonexistant language element. The compiler generates an error, continues to parse as best it can flagging other errors but does not generate any code. > > The second question is what entity detects a policy with unsupported > conditions and actions? And at what point in the policy lifecycle it > is/needs to be detected? > 1) policy definition language to LDAP translator detects it (needs to know > what policy engine is used) > 2) at load time of policies from a database into the execution engine > 3) at run-time, execution engine fails evaluating a condition or performing > an action, because it is not known. > My answer is 1 and 2 above. The Policy Management Tool may have an opportunity to interact with the rule author but if it can't make sense of the rule, then it shouldn't generate the policy. The PDP should reject policies that contain syntax and/or semantics that it does not understand and the PEP should do likewise. To do otherwise is to make assumptions about the intent of the policy and if we could do that we wouldn't need the rule author at all. Run-time errors should be confined as best as possible to errors caused by network state rather than by faulty rules. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Fri Apr 20 10:30:40 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12523 for ; Fri, 20 Apr 2001 10:30:40 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA26542; Fri, 20 Apr 2001 10:23:43 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA38908; Fri, 20 Apr 2001 10:23:41 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA131466; Fri, 20 Apr 2001 09:39:16 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA130170; Fri, 20 Apr 2001 09:39:12 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA27124 for ; Fri, 20 Apr 2001 09:39:15 -0400 Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA26338 for ; Fri, 20 Apr 2001 09:39:11 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id GAA01997 for ; Fri, 20 Apr 2001 06:38:41 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.4 [HUB])) with ESMTP id GAA07196 for ; Fri, 20 Apr 2001 06:38:25 -0700 (PDT) X-Interscan: Passed Received: from ind.alcatel.com ([208.19.33.105]) by newman.xylan.com (Netscape Messaging Server 4.15) with ESMTP id GC3F8100.E91; Fri, 20 Apr 2001 06:38:25 -0700 Message-Id: <3AE03C69.AEEE7C0A@ind.alcatel.com> Date: Fri, 20 Apr 2001 09:40:57 -0400 From: "Michael See" Organization: Alcatel Internetworking X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Marcus Brunner Cc: IETF Policy Subject: Re: criticality of extended conditions and actions References: <4215381584.987762892@[192.168.102.79]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Michael See" Content-Transfer-Encoding: 7bit Marcus Brunner wrote: > Lee, Mircea, > > I am not happy with the proposed solution, nevertheless we need to deal > with the problem of "unsupported" or "optional" elements in a policy rule. > > What does exclude a condition mean (Lees first handling)? replace it by > FALSE, by TRUE? or skip it? > > The second question is what entity detects a policy with unsupported > conditions and actions? And at what point in the policy lifecycle it > is/needs to be detected? > 1) policy definition language to LDAP translator detects it (needs to know > what policy engine is used) > 2) at load time of policies from a database into the execution engine > 3) at run-time, execution engine fails evaluating a condition or performing > an action, because it is not known. > There is also the case where the execution of a rule fails because the action defined in the rule cannot be implemented. From majordomo@raleigh.ibm.com Fri Apr 20 11:20:22 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13115 for ; Fri, 20 Apr 2001 11:20:21 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA34916; Fri, 20 Apr 2001 11:13:28 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA26220; Fri, 20 Apr 2001 11:13:28 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA73488; Fri, 20 Apr 2001 10:47:38 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA71940; Fri, 20 Apr 2001 10:47:35 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA29714 for ; Fri, 20 Apr 2001 10:47:38 -0400 Received: from d04nm200nm300.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3KElWQ72254 for ; Fri, 20 Apr 2001 10:47:32 -0400 Importance: Normal Subject: Re: criticality of extended conditions and actions To: "IETF Policy" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Fri, 20 Apr 2001 10:55:54 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 04/20/2001 10:47:31 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" First, let me say that I agree with Lee and some of the other authors, that this capability isn't something that we need in PCIMe. That said, let me bring into the discussion an example of an area where something like this capability does make sense. In CMIP / GDMO, we have a general extension mechanism for EventReports and Actions called ManagementExtension. A ManagementExtension contains 3 elements: an OID to identify which extension it is, an ANY DEFINED BY whose format and semantics are determined by the OID, and a boolean field called "significance" which corresponds, to some extent, to the Criticality property we're discussing here. The "significance" field works like this: - If "significance" = TRUE, then if the receiver doesn't understand the ManagementExtension, it is supposed to behave as if it never received the Action or EventReport containing the ManagementExtension. - If "significance" = FALSE, then if the receiver doesn't understand the ManagementExtension, it is supposed to process the Action or EventReport as if it did not contain that particular ManagementExtension. A use case for "significance" = FALSE would be a ManagementExtension for an alarm to report the detecting module. (Actually, this may be in the standard alarm -- I just don't remember. But you get the idea.) The desired behavior is for an alarm receiver that doesn't understand this ManagementExtension to process the remainder of the alarm. A use case for "significance" = TRUE would be a boolean ManagementExtension "isFictional". If an alarm receiver doesn't understand this ManagementExtension, it should ignore the alarm completely. (This is what went wrong with the famous Orson Welles "War of the Worlds" broadcast -- listeners who didn't understand that isFictional was TRUE acted on the "alarm" anyway.) It's safe for a vendor, or another standard, to introduce a ManagementExtension like isFictional precisely because the "significance" field for ManagementExtension is defined in the core GDMO model. Now if we tried very hard, we *might* be able to construct a case where we'd like our PolicyRules to work this way. But I can't do this for Policy nearly as easily I can for the CMIP Actions and EventReports. Hence my assessment that this is a complication we should not be adding to our PCIM / PCIMe model. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Lee Rafalow" @raleigh.ibm.com on 04/20/2001 09:06:07 AM Please respond to "Lee Rafalow" Sent by: policy-owner@raleigh.ibm.com To: "IETF Policy" cc: Subject: Re: criticality of extended conditions and actions Marcus, > I am not happy with the proposed solution, nevertheless we need to deal > with the problem of "unsupported" or "optional" elements in a policy rule. > > What does exclude a condition mean (Lees first handling)? replace it by > FALSE, by TRUE? or skip it? What I meant by "exclude it" is that if a policy author intends a condition to be "optional" then the author should just exclude the condition (because I don't understand an optional condition). I do not think that there is ANY machine interpretation for a condition for which there is no syntax or semantics. It's the same as telling a compiler that you want it generate code for a nonexistant language element. The compiler generates an error, continues to parse as best it can flagging other errors but does not generate any code. > > The second question is what entity detects a policy with unsupported > conditions and actions? And at what point in the policy lifecycle it > is/needs to be detected? > 1) policy definition language to LDAP translator detects it (needs to know > what policy engine is used) > 2) at load time of policies from a database into the execution engine > 3) at run-time, execution engine fails evaluating a condition or performing > an action, because it is not known. > My answer is 1 and 2 above. The Policy Management Tool may have an opportunity to interact with the rule author but if it can't make sense of the rule, then it shouldn't generate the policy. The PDP should reject policies that contain syntax and/or semantics that it does not understand and the PEP should do likewise. To do otherwise is to make assumptions about the intent of the policy and if we could do that we wouldn't need the rule author at all. Run-time errors should be confined as best as possible to errors caused by network state rather than by faulty rules. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Fri Apr 20 11:59:36 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13613 for ; Fri, 20 Apr 2001 11:59:35 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24744; Fri, 20 Apr 2001 11:53:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA27522; Fri, 20 Apr 2001 11:53:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA87158; Fri, 20 Apr 2001 11:20:06 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27702; Fri, 20 Apr 2001 11:20:00 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA36972 for ; Fri, 20 Apr 2001 11:20:02 -0400 Received: from mail01.san.yahoo.com (mail01.san.yahoo.com [209.132.1.35]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA31312 for ; Fri, 20 Apr 2001 11:19:57 -0400 Received: from ntearb4s22b666 (62.0.183.185) by mail01.san.yahoo.com (5.1.062) id 3ADB8D3C0052E4CF for policy@raleigh.ibm.com; Fri, 20 Apr 2001 08:13:13 -0700 From: "Ron Cohen" To: "POLICY \(IETF\)" Subject: QoS Policy Info Model - 03 Date: Fri, 20 Apr 2001 17:24:48 +0200 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) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ron Cohen" Content-Transfer-Encoding: 7bit We have sent a new version of the QoS Policy Information model to the IETF repository a week ago. Since I haven't seen it yet on the repository, you can download it from http://www.geocities.com/ron_cohen2000/draft-ietf-policy-qos-info-model-03.t xt for the time being. Remarks appreciated From majordomo@raleigh.ibm.com Fri Apr 20 13:16:59 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14788 for ; Fri, 20 Apr 2001 13:16:58 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA09044; Fri, 20 Apr 2001 13:07:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA34332; Fri, 20 Apr 2001 13:07:41 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA107976; Fri, 20 Apr 2001 12:37:06 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA74162; Fri, 20 Apr 2001 12:37:02 -0400 Received: from lmr (dyn9-37-48-225.raleigh.ibm.com [9.37.48.225]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA27630 for ; Fri, 20 Apr 2001 12:37:06 -0400 Message-Id: <005901c0c9b7$b676a1c0$e1302509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <4241344467.987788855@[192.168.102.79]> Subject: Re: criticality of extended conditions and actions Date: Fri, 20 Apr 2001 12:34:03 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Yes, I understand that there are other cases than the optional case where a policy component may not understand a condition or action. My assertions are meant to be general and not restricted to just the case where this thread began. As for your example of IPSP and RSVP semantics getting mixed together, I believe this example helps makes my case. Either the roles or the rules or both were misdefined and the policy should not (MUST NOT, IMO) be enforced. Like many technologies, policy has potential for both good and bad outcomes. Even when policy is well-formed, it has potential for unanticipated (bad) results; putting brakes in to prevent bad results from poorly-formed policies is a good thing. Cheers. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com ----- Original Message ----- From: "Marcus Brunner" To: "Lee Rafalow" ; "IETF Policy" Sent: Friday, April 20, 2001 11:47 AM Subject: Re: criticality of extended conditions and actions > Lee, > > The problems are not optional conditions, but conditions, which are not > supported in the execution engine. Think of the IPSP engine executing a > RSVP-condition (the example may be odd) > > Marcus > > --On Friday, April 20, 2001 9:06 AM -0400 Lee Rafalow > wrote: > > > Marcus, > > > >> I am not happy with the proposed solution, nevertheless we need to deal > >> with the problem of "unsupported" or "optional" elements in a policy > >> rule. > >> > >> What does exclude a condition mean (Lees first handling)? replace it by > >> FALSE, by TRUE? or skip it? > > > > What I meant by "exclude it" is that if a policy author intends a > > condition to be "optional" then the author should just exclude the > > condition (because I don't understand an optional condition). I do not > > think that there is ANY machine interpretation for a condition for which > > there is no syntax or semantics. It's the same as telling a compiler > > that you want it generate code for a nonexistant language element. The > > compiler generates an error, continues to parse as best it can flagging > > other errors but does not generate any code. > > > >> > >> The second question is what entity detects a policy with unsupported > >> conditions and actions? And at what point in the policy lifecycle it > >> is/needs to be detected? > >> 1) policy definition language to LDAP translator detects it (needs to > >> know what policy engine is used) > >> 2) at load time of policies from a database into the execution engine > >> 3) at run-time, execution engine fails evaluating a condition or > > performing > >> an action, because it is not known. > >> > > > > My answer is 1 and 2 above. The Policy Management Tool may have an > > opportunity to interact with the rule author but if it can't make sense of > > the rule, then it shouldn't generate the policy. The PDP should reject > > policies that contain syntax and/or semantics that it does not understand > > and the PEP should do likewise. To do otherwise is to make assumptions > > about the intent of the policy and if we could do that we wouldn't need > > the rule author at all. Run-time errors should be confined as best as > > possible to errors caused by network state rather than by faulty rules. > > > > > > Lee M. Rafalow > > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > > IBM Internet Technology Management > > IBM Corporation > > P.O. Box 12195, BRQA/502 > > RTP, NC 27709 USA > > Alternate email: rafalow@us.ibm.com > > Home email: rafalow@mindspring.com > > > > > > -------------------------------------- > 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 Apr 20 13:35:22 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15136 for ; Fri, 20 Apr 2001 13:35:21 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA24310; Fri, 20 Apr 2001 13:25:50 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA34458; Fri, 20 Apr 2001 13:25:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57902; Fri, 20 Apr 2001 11:42:14 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45094; Fri, 20 Apr 2001 11:42:11 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA25500 for ; Fri, 20 Apr 2001 11:42:15 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA19510 for ; Fri, 20 Apr 2001 11:42:10 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3KFgae20069; Fri, 20 Apr 2001 17:42:36 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id D5960C095; Fri, 20 Apr 2001 18:49:07 +0200 (CEST) Date: Fri, 20 Apr 2001 17:45:06 +0200 From: Marcus Brunner To: Michael See Cc: IETF Policy Subject: Re: criticality of extended conditions and actions Message-Id: <4241195583.987788706@[192.168.102.79]> In-Reply-To: <3AE03C69.AEEE7C0A@ind.alcatel.com> X-Mailer: Mulberry/2.0.6 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Michael, I think in PCIMe we covered the case of failing Action by the ExecutionStrategy in CompoundActions (do until sucess, do until failure). So dealing with a unsupported action could be regarded an action failure. Marcus --On Friday, April 20, 2001 9:40 AM -0400 Michael See wrote: > > > Marcus Brunner wrote: > >> Lee, Mircea, >> >> I am not happy with the proposed solution, nevertheless we need to deal >> with the problem of "unsupported" or "optional" elements in a policy >> rule. >> >> What does exclude a condition mean (Lees first handling)? replace it by >> FALSE, by TRUE? or skip it? >> >> The second question is what entity detects a policy with unsupported >> conditions and actions? And at what point in the policy lifecycle it >> is/needs to be detected? >> 1) policy definition language to LDAP translator detects it (needs to >> know what policy engine is used) >> 2) at load time of policies from a database into the execution engine >> 3) at run-time, execution engine fails evaluating a condition or >> performing an action, because it is not known. >> > > There is also the case where the execution of a rule fails because the > action defined in the rule cannot be implemented. > -------------------------------------- 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 Apr 20 14:26:01 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15905 for ; Fri, 20 Apr 2001 14:26:00 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA06664; Fri, 20 Apr 2001 14:17:44 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA04000; Fri, 20 Apr 2001 14:17:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48624; Fri, 20 Apr 2001 11:44:14 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45280; Fri, 20 Apr 2001 11:44:11 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA30168; Fri, 20 Apr 2001 11:44:14 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA26018; Fri, 20 Apr 2001 11:44:10 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3KFj4e20145; Fri, 20 Apr 2001 17:45:04 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id B936DC095; Fri, 20 Apr 2001 18:51:36 +0200 (CEST) Date: Fri, 20 Apr 2001 17:47:35 +0200 From: Marcus Brunner To: Lee Rafalow , IETF Policy Subject: Re: criticality of extended conditions and actions Message-Id: <4241344467.987788855@[192.168.102.79]> In-Reply-To: <003e01c0c99a$aa26f400$e1302509@raleigh.ibm.com> X-Mailer: Mulberry/2.0.6 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Lee, The problems are not optional conditions, but conditions, which are not supported in the execution engine. Think of the IPSP engine executing a RSVP-condition (the example may be odd) Marcus --On Friday, April 20, 2001 9:06 AM -0400 Lee Rafalow wrote: > Marcus, > >> I am not happy with the proposed solution, nevertheless we need to deal >> with the problem of "unsupported" or "optional" elements in a policy >> rule. >> >> What does exclude a condition mean (Lees first handling)? replace it by >> FALSE, by TRUE? or skip it? > > What I meant by "exclude it" is that if a policy author intends a > condition to be "optional" then the author should just exclude the > condition (because I don't understand an optional condition). I do not > think that there is ANY machine interpretation for a condition for which > there is no syntax or semantics. It's the same as telling a compiler > that you want it generate code for a nonexistant language element. The > compiler generates an error, continues to parse as best it can flagging > other errors but does not generate any code. > >> >> The second question is what entity detects a policy with unsupported >> conditions and actions? And at what point in the policy lifecycle it >> is/needs to be detected? >> 1) policy definition language to LDAP translator detects it (needs to >> know what policy engine is used) >> 2) at load time of policies from a database into the execution engine >> 3) at run-time, execution engine fails evaluating a condition or > performing >> an action, because it is not known. >> > > My answer is 1 and 2 above. The Policy Management Tool may have an > opportunity to interact with the rule author but if it can't make sense of > the rule, then it shouldn't generate the policy. The PDP should reject > policies that contain syntax and/or semantics that it does not understand > and the PEP should do likewise. To do otherwise is to make assumptions > about the intent of the policy and if we could do that we wouldn't need > the rule author at all. Run-time errors should be confined as best as > possible to errors caused by network state rather than by faulty rules. > > > Lee M. Rafalow > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > IBM Internet Technology Management > IBM Corporation > P.O. Box 12195, BRQA/502 > RTP, NC 27709 USA > Alternate email: rafalow@us.ibm.com > Home email: rafalow@mindspring.com > -------------------------------------- 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 Apr 20 18:47:19 2001 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19370 for ; Fri, 20 Apr 2001 18:47:19 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA32784; Fri, 20 Apr 2001 18:38:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA20780; Fri, 20 Apr 2001 18:38:49 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA99180; Fri, 20 Apr 2001 18:04:01 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA123162; Fri, 20 Apr 2001 18:03:52 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA29988 for ; Fri, 20 Apr 2001 18:03:56 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id SAA32008 for ; Fri, 20 Apr 2001 18:03:53 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9. (SMI-8.6/SMI-SVR4) id SAA06291; Fri, 20 Apr 2001 18:03:21 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 20 Apr 2001 18:03:06 -0400 Received: from zcard04n.ca.nortel.com (ZCARD04N [47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JKLJM47P; Fri, 20 Apr 2001 18:03:06 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVRB8YA4; Fri, 20 Apr 2001 18:03:06 -0400 Message-Id: <3AE0B190.B3AC0F9@americasm01.nt.com> Date: Fri, 20 Apr 2001 18:00:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: <4241195583.987788706@[192.168.102.79]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Marcus, in a previous message you suggested that in case of unsupported components (conditions, actions) "the loading of the whole rule fails". In the message below you suggest that "a unsupported action could be regarded an action failure" which is different from the first one. Please excuse me if I got it wrong! In case of a set of actions aggregated in a rule, if an action is unsupported on the PDP or PEP, then which one of the following cases is the right one? 1. the entire rule fails to load on the PDP or to be communicated to the PEP 2. the unsupported action is ignored and the others are executed in conformance with the execution strategy. 3. the unsupported action is considered failed and depending on the execution strategy, the other actions may be executed Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP relative to unsupported extensions. Regards, Mircea. Marcus Brunner wrote: > > Michael, > > I think in PCIMe we covered the case of failing Action by the > ExecutionStrategy in CompoundActions (do until sucess, do until failure). > So dealing with a unsupported action could be regarded an action failure. > > Marcus > > --On Friday, April 20, 2001 9:40 AM -0400 Michael See > wrote: > > > > > > > Marcus Brunner wrote: > > > >> Lee, Mircea, > >> > >> I am not happy with the proposed solution, nevertheless we need to deal > >> with the problem of "unsupported" or "optional" elements in a policy > >> rule. > >> > >> What does exclude a condition mean (Lees first handling)? replace it by > >> FALSE, by TRUE? or skip it? > >> > >> The second question is what entity detects a policy with unsupported > >> conditions and actions? And at what point in the policy lifecycle it > >> is/needs to be detected? > >> 1) policy definition language to LDAP translator detects it (needs to > >> know what policy engine is used) > >> 2) at load time of policies from a database into the execution engine > >> 3) at run-time, execution engine fails evaluating a condition or > >> performing an action, because it is not known. > >> > > > > There is also the case where the execution of a rule fails because the > > action defined in the rule cannot be implemented. > > > > -------------------------------------- > 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 Apr 23 09:17:33 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04180 for ; Mon, 23 Apr 2001 09:17:33 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA30692; Mon, 23 Apr 2001 09:10:25 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA31818; Mon, 23 Apr 2001 09:10:23 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24644; Mon, 23 Apr 2001 04:17:12 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23730; Mon, 23 Apr 2001 04:16:33 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA32886 for ; Mon, 23 Apr 2001 04:16:22 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA08242 for ; Mon, 23 Apr 2001 04:15:17 -0400 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3N8F0e46387; Mon, 23 Apr 2001 10:15:00 +0200 (CEST) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 11987C059; Mon, 23 Apr 2001 11:21:27 +0200 (CEST) Date: Mon, 23 Apr 2001 10:17:31 +0200 From: Marcus Brunner To: Mircea Pana , IETF Policy Subject: Re: criticality of extended conditions and actions Message-Id: <178573105.988021051@[192.168.102.79]> In-Reply-To: <3AE0B190.B3AC0F9@americasm01.nt.com> X-Mailer: Mulberry/2.0.6 (Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit I aggree with Lee, that the whole rule should fail to load (your proposal number 1). He convinced me, that otherwise really bad things may happen in the network. The question remains, what is the entity of loading, probably even the whole entity may fail to load (the entity of loading may be very implementation dependent). If a rule fails to load, it may be wise to disable the whole group the rule is in. Marcus --On Friday, April 20, 2001 6:00 PM -0400 Mircea Pana wrote: > Marcus, in a previous message you suggested that in case of unsupported > components (conditions, actions) "the loading of the whole rule fails". > In the message below you suggest that "a unsupported action could be > regarded an action failure" which is different from the first one. > Please excuse me if I got it wrong! > > In case of a set of actions aggregated in a rule, if an action is > unsupported on the PDP or PEP, then which one of the following cases is > the right one? > > 1. the entire rule fails to load on the PDP or to be communicated to the > PEP > 2. the unsupported action is ignored and the others are executed in > conformance with the execution strategy. > 3. the unsupported action is considered failed and depending on the > execution strategy, the other actions may be executed > > Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP > relative to unsupported extensions. > > Regards, > Mircea. > > > Marcus Brunner wrote: >> >> Michael, >> >> I think in PCIMe we covered the case of failing Action by the >> ExecutionStrategy in CompoundActions (do until sucess, do until failure). >> So dealing with a unsupported action could be regarded an action failure. >> >> Marcus >> >> --On Friday, April 20, 2001 9:40 AM -0400 Michael See >> wrote: >> >> > >> > >> > Marcus Brunner wrote: >> > >> >> Lee, Mircea, >> >> >> >> I am not happy with the proposed solution, nevertheless we need to >> >> deal with the problem of "unsupported" or "optional" elements in a >> >> policy rule. >> >> >> >> What does exclude a condition mean (Lees first handling)? replace it >> >> by FALSE, by TRUE? or skip it? >> >> >> >> The second question is what entity detects a policy with unsupported >> >> conditions and actions? And at what point in the policy lifecycle it >> >> is/needs to be detected? >> >> 1) policy definition language to LDAP translator detects it (needs to >> >> know what policy engine is used) >> >> 2) at load time of policies from a database into the execution engine >> >> 3) at run-time, execution engine fails evaluating a condition or >> >> performing an action, because it is not known. >> >> >> > >> > There is also the case where the execution of a rule fails because the >> > action defined in the rule cannot be implemented. >> > >> >> -------------------------------------- >> 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 > -------------------------------------- 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 Apr 23 10:48:45 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05032 for ; Mon, 23 Apr 2001 10:48:45 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA29658; Mon, 23 Apr 2001 10:39:00 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA28938; Mon, 23 Apr 2001 10:38:56 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27562; Mon, 23 Apr 2001 08:43:56 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43146; Mon, 23 Apr 2001 08:08:42 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA27980 for ; Mon, 23 Apr 2001 08:08:42 -0400 Received: from d04mc200mc300.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3NC8fq36476; Mon, 23 Apr 2001 08:08:41 -0400 Importance: Normal Subject: Re: criticality of extended conditions and actions To: "Mircea Pana" Cc: IETF Policy X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 23 Apr 2001 08:17:07 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/23/2001 08:08:41 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Mircea, There's another alternative, which, given your numbering scheme, would most appropriately be numbered 0: 0. the entire aggregation tree of Policy Groups and Policy Rules containing the rule in question fails to load on the PDP or to be communicated to the PEP The motivation for this alternative would be concern about unpredictable (and potentially undesirable) results if *anything* about the entire "policy" (which I'm interpreting as the entire aggregation tree, complete with its priorities and execution strategies) is unrecognized / unsupported. This may result in a whole lot of cases where policies don't load at all, because some component or other of them is unrecognized / unsupported. But if your overriding goal (maybe "overriding constraint" is a better way to say it) with policy-based management is "no surprises," then this is exactly how you'd want it to work. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Mircea Pana" @raleigh.ibm.com on 04/20/2001 06:00:48 PM Please respond to "Mircea Pana" Sent by: policy-owner@raleigh.ibm.com To: IETF Policy cc: Subject: Re: criticality of extended conditions and actions Marcus, in a previous message you suggested that in case of unsupported components (conditions, actions) "the loading of the whole rule fails". In the message below you suggest that "a unsupported action could be regarded an action failure" which is different from the first one. Please excuse me if I got it wrong! In case of a set of actions aggregated in a rule, if an action is unsupported on the PDP or PEP, then which one of the following cases is the right one? 1. the entire rule fails to load on the PDP or to be communicated to the PEP 2. the unsupported action is ignored and the others are executed in conformance with the execution strategy. 3. the unsupported action is considered failed and depending on the execution strategy, the other actions may be executed Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP relative to unsupported extensions. Regards, Mircea. Marcus Brunner wrote: > > Michael, > > I think in PCIMe we covered the case of failing Action by the > ExecutionStrategy in CompoundActions (do until sucess, do until failure). > So dealing with a unsupported action could be regarded an action failure. > > Marcus > > --On Friday, April 20, 2001 9:40 AM -0400 Michael See > wrote: > > > > > > > Marcus Brunner wrote: > > > >> Lee, Mircea, > >> > >> I am not happy with the proposed solution, nevertheless we need to deal > >> with the problem of "unsupported" or "optional" elements in a policy > >> rule. > >> > >> What does exclude a condition mean (Lees first handling)? replace it by > >> FALSE, by TRUE? or skip it? > >> > >> The second question is what entity detects a policy with unsupported > >> conditions and actions? And at what point in the policy lifecycle it > >> is/needs to be detected? > >> 1) policy definition language to LDAP translator detects it (needs to > >> know what policy engine is used) > >> 2) at load time of policies from a database into the execution engine > >> 3) at run-time, execution engine fails evaluating a condition or > >> performing an action, because it is not known. > >> > > > > There is also the case where the execution of a rule fails because the > > action defined in the rule cannot be implemented. > > > > -------------------------------------- > 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 Apr 23 11:43:58 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05842 for ; Mon, 23 Apr 2001 11:43:56 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25636; Mon, 23 Apr 2001 11:38:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA32004; Mon, 23 Apr 2001 11:38:02 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54312; Mon, 23 Apr 2001 11:04:19 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53280; Mon, 23 Apr 2001 11:04:16 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA32502 for ; Mon, 23 Apr 2001 11:04:18 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id LAA23652 for ; Mon, 23 Apr 2001 11:04:15 -0400 Received: from zcars04e.nortelnetworks.com by zcars0m9. (SMI-8.6/SMI-SVR4) id LAA15251; Mon, 23 Apr 2001 11:03:43 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 23 Apr 2001 11:03:39 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTG9S6; Mon, 23 Apr 2001 11:03:37 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J33TYSCA; Mon, 23 Apr 2001 11:03:38 -0400 Message-Id: <3AE443B9.F9EA19AD@americasm01.nt.com> Date: Mon, 23 Apr 2001 11:01:13 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I have to agree that in most cases the Policy Model already has mechanisms for expressing the optional aspect of various components. I did try very hard (at Bob's suggestion ;-) but only came up with impractical use cases where "criticality" would be the only way out. This isn't worth the WG's attention at this point - may have been a "red herring". Regards, Mircea P.S. Whether or not unsupported components should be acceptable in policyRules, is a different question. I'll address it in an other message. Robert Moore wrote: > [snip] > Now if we tried very hard, we *might* be able to construct > a case where we'd like our PolicyRules to work this way. > But I can't do this for Policy nearly as easily I can for > the CMIP Actions and EventReports. Hence my assessment > that this is a complication we should not be adding to > our PCIM / PCIMe model. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > "Lee Rafalow" @raleigh.ibm.com on 04/20/2001 > 09:06:07 AM > > Please respond to "Lee Rafalow" > > Sent by: policy-owner@raleigh.ibm.com > > To: "IETF Policy" > cc: > Subject: Re: criticality of extended conditions and actions > > Marcus, > > > I am not happy with the proposed solution, nevertheless we need to deal > > with the problem of "unsupported" or "optional" elements in a policy > rule. > > > > What does exclude a condition mean (Lees first handling)? replace it by > > FALSE, by TRUE? or skip it? > > What I meant by "exclude it" is that if a policy author intends a condition > to be "optional" then the author should just exclude the condition (because > I don't understand an optional condition). I do not think that there is > ANY > machine interpretation for a condition for which there is no syntax or > semantics. It's the same as telling a compiler that you want it generate > code for a nonexistant language element. The compiler generates an error, > continues to parse as best it can flagging other errors but does not > generate any code. > > > > > The second question is what entity detects a policy with unsupported > > conditions and actions? And at what point in the policy lifecycle it > > is/needs to be detected? > > 1) policy definition language to LDAP translator detects it (needs to > know > > what policy engine is used) > > 2) at load time of policies from a database into the execution engine > > 3) at run-time, execution engine fails evaluating a condition or > performing > > an action, because it is not known. > > > > My answer is 1 and 2 above. The Policy Management Tool may have an > opportunity to interact with the rule author but if it can't make sense of > the rule, then it shouldn't generate the policy. The PDP should reject > policies that contain syntax and/or semantics that it does not understand > and the PEP should do likewise. To do otherwise is to make assumptions > about the intent of the policy and if we could do that we wouldn't need the > rule author at all. Run-time errors should be confined as best as possible > to errors caused by network state rather than by faulty rules. > > Lee M. Rafalow > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > IBM Internet Technology Management > IBM Corporation > P.O. Box 12195, BRQA/502 > RTP, NC 27709 USA > Alternate email: rafalow@us.ibm.com > Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Mon Apr 23 15:15:23 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10812 for ; Mon, 23 Apr 2001 15:15:19 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA26260; Mon, 23 Apr 2001 15:07:23 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA31204; Mon, 23 Apr 2001 15:07:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53848; Mon, 23 Apr 2001 14:35:47 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53838; Mon, 23 Apr 2001 14:35:44 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA31536 for ; Mon, 23 Apr 2001 14:35:47 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id OAA08292 for ; Mon, 23 Apr 2001 14:35:43 -0400 Received: from zcars04e.nortelnetworks.com by zcars0m9. (SMI-8.6/SMI-SVR4) id OAA11644; Mon, 23 Apr 2001 14:35:12 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 23 Apr 2001 14:35:07 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTH6WW; Mon, 23 Apr 2001 14:35:04 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J33TYSPA; Mon, 23 Apr 2001 14:34:57 -0400 Message-Id: <3AE47540.6A0CF253@americasm01.nt.com> Date: Mon, 23 Apr 2001 14:32:32 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit In order to illustrate the advantages of the options 2. and 3. compared with 0. and 1., please consider the following case: An administration runs a policy based QoS product (PDPs and PEPs) "QP". This product supports actions of type "qpAction" (subclass of policyAction). Most probably the administrators have created complex aggregations that represent their business and network objectives. For example: qpGroup1 (policyGroup) qpGroup2 (policyGroup) qp... qpPolicy1 (policyRule) qp... qpPolicy2 (policyRule) qpCondition1 (qpCondition) qpAction1 (policyCompoundAction) qpAction11 (qpAction) qpAction12 (qpAction) qpAction2 (qpAction) Subsequently, the administration decides to deploy a new policy based QoS product (PDPs and PEPs) "QPplus" by selectively replacing some of the old "QP" systems (PDPs and PEPs). Let's say, for example, that the "QPplus" supports all the features of "QP" and, in addition, a new type of action: "qpLoging" (subclass of policyAction). Let's say that this action type is non critical to the delivery of business value but rather is useful for network engineering, utilization data collection for statistics etc. In case of the options 0. and 1. since "QP" does not understand the new action type, the aggregation trees are cloned and the clones upgraded with instances of "qpLoging". Also, the clones will receive different/additional policyRoles/policyKeywords in order to be distinguished from the originals. The cloned and upgraded aggregation tree for "QPPlus" might be: qpPlusGroup1 (policyGroup) qpPlusGroup2 (policyGroup) qpPlus... qpPlusPolicy1 (policyRule) qpPlus... qpPlusPolicy2 (policyRule) qpCondition1 (qpCondition) -- can be shared with "QP" qpPlusAction1 (policyCompoundAction) qpPlusAction11: strategy=all (policyCompoundAction) qpAction11 (qpAction) -- can be shared with "QP" qpPlusLog11 (qpLogging) qpPlusAction12: strategy=all (policyCompoundAction) qpAction12 (qpAction) -- can be shared with "QP" qpPlusLog12 (qpLogging) qpPlusAction2: strategy=all (policyCompoundAction) qpAction2 (qpAction) -- can be shared with "QP" qpPlusLog2 (qpLogging) Note that most of the instances are cloned and renamed "qpPlus*" while very few instances are shared. Since in this situation, two separate sets of aggregation trees have to be maintained, scaleability and manageability issues will occur sooner or later. In case of options 2. and 3. since it is acceptable to have unknown action types aggregated together with the supported ones, the existing aggregation tree is upgraded and shared among the "QP" and "QPPlus" systems. Therefore, the arguments in favor of the latter options (2. and/or 3.) derive from the ability to share more data structures across functional domains: especially the scaleability and manageability in an environment with several policy based functional domains. IMO options 0. and 1. lead to data partitioning by PDP (vendor)type and (vendor)version which may be unacceptable in large scale a deployment of policy based products. Regards, Mircea. Robert Moore wrote: > > Mircea, > > There's another alternative, which, given your > numbering scheme, would most appropriately be > numbered 0: > > 0. the entire aggregation tree of Policy Groups > and Policy Rules containing the rule in > question fails to load on the PDP or to be > communicated to the PEP > > The motivation for this alternative would be > concern about unpredictable (and potentially > undesirable) results if *anything* about the > entire "policy" (which I'm interpreting as the > entire aggregation tree, complete with its > priorities and execution strategies) is > unrecognized / unsupported. > > This may result in a whole lot of cases where > policies don't load at all, because some > component or other of them is unrecognized / > unsupported. But if your overriding goal > (maybe "overriding constraint" is a better way > to say it) with policy-based management is > "no surprises," then this is exactly how you'd > want it to work. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > "Mircea Pana" @raleigh.ibm.com on 04/20/2001 > 06:00:48 PM > > Please respond to "Mircea Pana" > > Sent by: policy-owner@raleigh.ibm.com > > To: IETF Policy > cc: > Subject: Re: criticality of extended conditions and actions > > Marcus, in a previous message you suggested that in case of unsupported > components (conditions, actions) "the loading of the whole rule fails". > In the message below you suggest that "a unsupported action could be > regarded an action failure" which is different from the first one. > Please excuse me if I got it wrong! > > In case of a set of actions aggregated in a rule, if an action is > unsupported on the PDP or PEP, then which one of the following cases is > the right one? > > 1. the entire rule fails to load on the PDP or to be communicated to the > PEP > 2. the unsupported action is ignored and the others are executed in > conformance with the execution strategy. > 3. the unsupported action is considered failed and depending on the > execution strategy, the other actions may be executed > > Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP > relative to unsupported extensions. > > Regards, > Mircea. > > Marcus Brunner wrote: > > > > Michael, > > > > I think in PCIMe we covered the case of failing Action by the > > ExecutionStrategy in CompoundActions (do until sucess, do until failure). > > So dealing with a unsupported action could be regarded an action failure. > > > > Marcus > > > > --On Friday, April 20, 2001 9:40 AM -0400 Michael See > > wrote: > > > > > > > > > > > Marcus Brunner wrote: > > > > > >> Lee, Mircea, > > >> > > >> I am not happy with the proposed solution, nevertheless we need to > deal > > >> with the problem of "unsupported" or "optional" elements in a policy > > >> rule. > > >> > > >> What does exclude a condition mean (Lees first handling)? replace it > by > > >> FALSE, by TRUE? or skip it? > > >> > > >> The second question is what entity detects a policy with unsupported > > >> conditions and actions? And at what point in the policy lifecycle it > > >> is/needs to be detected? > > >> 1) policy definition language to LDAP translator detects it (needs to > > >> know what policy engine is used) > > >> 2) at load time of policies from a database into the execution engine > > >> 3) at run-time, execution engine fails evaluating a condition or > > >> performing an action, because it is not known. > > >> > > > > > > There is also the case where the execution of a rule fails because the > > > action defined in the rule cannot be implemented. > > > > > > > -------------------------------------- > > 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 Apr 23 15:29:53 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11111 for ; Mon, 23 Apr 2001 15:29:52 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA29348; Mon, 23 Apr 2001 15:20:56 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA23588; Mon, 23 Apr 2001 15:20:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50132; Mon, 23 Apr 2001 08:09:08 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43146; Mon, 23 Apr 2001 08:08:42 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA27980 for ; Mon, 23 Apr 2001 08:08:42 -0400 Received: from d04mc200mc300.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f3NC8fq36476; Mon, 23 Apr 2001 08:08:41 -0400 Importance: Normal Subject: Re: criticality of extended conditions and actions To: "Mircea Pana" Cc: IETF Policy X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Mon, 23 Apr 2001 08:17:07 -0400 X-Mimetrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/23/2001 08:08:41 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" Mircea, There's another alternative, which, given your numbering scheme, would most appropriately be numbered 0: 0. the entire aggregation tree of Policy Groups and Policy Rules containing the rule in question fails to load on the PDP or to be communicated to the PEP The motivation for this alternative would be concern about unpredictable (and potentially undesirable) results if *anything* about the entire "policy" (which I'm interpreting as the entire aggregation tree, complete with its priorities and execution strategies) is unrecognized / unsupported. This may result in a whole lot of cases where policies don't load at all, because some component or other of them is unrecognized / unsupported. But if your overriding goal (maybe "overriding constraint" is a better way to say it) with policy-based management is "no surprises," then this is exactly how you'd want it to work. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Mircea Pana" @raleigh.ibm.com on 04/20/2001 06:00:48 PM Please respond to "Mircea Pana" Sent by: policy-owner@raleigh.ibm.com To: IETF Policy cc: Subject: Re: criticality of extended conditions and actions Marcus, in a previous message you suggested that in case of unsupported components (conditions, actions) "the loading of the whole rule fails". In the message below you suggest that "a unsupported action could be regarded an action failure" which is different from the first one. Please excuse me if I got it wrong! In case of a set of actions aggregated in a rule, if an action is unsupported on the PDP or PEP, then which one of the following cases is the right one? 1. the entire rule fails to load on the PDP or to be communicated to the PEP 2. the unsupported action is ignored and the others are executed in conformance with the execution strategy. 3. the unsupported action is considered failed and depending on the execution strategy, the other actions may be executed Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP relative to unsupported extensions. Regards, Mircea. Marcus Brunner wrote: > > Michael, > > I think in PCIMe we covered the case of failing Action by the > ExecutionStrategy in CompoundActions (do until sucess, do until failure). > So dealing with a unsupported action could be regarded an action failure. > > Marcus > > --On Friday, April 20, 2001 9:40 AM -0400 Michael See > wrote: > > > > > > > Marcus Brunner wrote: > > > >> Lee, Mircea, > >> > >> I am not happy with the proposed solution, nevertheless we need to deal > >> with the problem of "unsupported" or "optional" elements in a policy > >> rule. > >> > >> What does exclude a condition mean (Lees first handling)? replace it by > >> FALSE, by TRUE? or skip it? > >> > >> The second question is what entity detects a policy with unsupported > >> conditions and actions? And at what point in the policy lifecycle it > >> is/needs to be detected? > >> 1) policy definition language to LDAP translator detects it (needs to > >> know what policy engine is used) > >> 2) at load time of policies from a database into the execution engine > >> 3) at run-time, execution engine fails evaluating a condition or > >> performing an action, because it is not known. > >> > > > > There is also the case where the execution of a rule fails because the > > action defined in the rule cannot be implemented. > > > > -------------------------------------- > 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 Apr 23 18:00:11 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13635 for ; Mon, 23 Apr 2001 18:00:10 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA22276; Mon, 23 Apr 2001 17:53:09 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA32200; Mon, 23 Apr 2001 17:53:07 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55744; Mon, 23 Apr 2001 16:26:30 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40376; Mon, 23 Apr 2001 16:26:27 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA30038 for ; Mon, 23 Apr 2001 16:26:31 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id QAA22912 for ; Mon, 23 Apr 2001 16:26:27 -0400 Received: from zcars04e.nortelnetworks.com by zcars0m9. (SMI-8.6/SMI-SVR4) id QAA23614; Mon, 23 Apr 2001 16:25:29 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Mon, 23 Apr 2001 16:25:11 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHT2M85; Mon, 23 Apr 2001 16:25:10 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J33TYSWG; Mon, 23 Apr 2001 16:25:13 -0400 Message-Id: <3AE48F16.FF171888@americasm01.nt.com> Date: Mon, 23 Apr 2001 16:22:46 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Result of the compoundPolicyAction Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit (on a different thread:) The result of the execution of a compoundPolicyAction (success or failure) is important for the execution strategy of the aggregating policyRules or compoundPolicyAction. To avoid ambiguity, it may be good to add a clarification to the next release of PCIMe. A suggestion might be: 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: The compoundPolicyAction is successful if an aggregated policyAction is successful. If all the aggregated policyActions fail, then the aggregating compoundPolicyAction is considered failed. 2. For compoundPolicyAction.executionStrategy=Do_All: The compoundPolicyAction is successful if all the aggregated policyActions are successful. If one or more aggregated policyActions fail, then the aggregating compoundPolicyAction is considered failed. (2bis. An alternative to 2 might be: The compoundPolicyAction is successful if one or more aggregated policyActions are successful. If all the aggregated policyActions fail, then the aggregating compoundPolicyAction is considered failed. If both 2. and 2bis are applicable in various situations then it may be useful to add a "Do_Any" execution strategy?) 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: The compoundPolicyAction is successful if one or more aggregated policyActions are successful. If the first attempt to execute an aggregated policyAction fails, then the aggregating compoundPolicyAction is considered failed. Regards, Mircea. P.S. BTW in PCIMe-01, the example at the end of the paragraph "4.7.2 Compound Policy Actions" uses the retired "Mandatory Do All" decision strategy. For consistency with the rest of the document, this should be corrected. From majordomo@raleigh.ibm.com Tue Apr 24 14:55:19 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12646 for ; Tue, 24 Apr 2001 14:55:18 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA31822; Tue, 24 Apr 2001 14:38:30 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA20326; Tue, 24 Apr 2001 13:46:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA62410; Tue, 24 Apr 2001 09:55:18 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44994; Tue, 24 Apr 2001 09:55:15 -0400 Received: from lmr (dyn9-37-48-102.raleigh.ibm.com [9.37.48.102]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA31544 for ; Tue, 24 Apr 2001 09:55:17 -0400 Message-Id: <007501c0ccc5$c4f52e40$66302509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <3AE47540.6A0CF253@americasm01.nt.com> Subject: Re: criticality of extended conditions and actions Date: Tue, 24 Apr 2001 09:52:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Mircea, Let's break this down into it's component parts: rule compilation unit of failure and optional rule components. It's difficult for me to imagine that there are sets of rules that can have a rule removed and still somehow reflect the intent of the administrator. So I think that the unit of failure should be the whole aggregated set of rules. Your example does, however, raise a good point about extending sets of actions. (I still don't see this extending to conditions, however.) It seems reasonable to me that we could define a boolean in PolicyAction that indicates that a recognition failure for a given action instance does not constitute a compilation failure. (Actually, this should really be a class variable, but we don't have class variables in our model. CIM has qualifiers that can serve as class variables but they're a clumsy substitute.) How's this? NAME MayIgnoreAction DESCRIPTION This boolean may be set to indicate that an action instance may be ignored by rule engine. Actions that may be ignored extend the actions of a rule but, if not supported, may be ignored and do not cause the set of rules to be rejected by the PDP or PEP. SYNTAX boolean DEFAULT false Implementations MAY support the property. If not supported and an action is not recognized by the implementation, the aggregation of rules (we need a name for this thing) is rejected as in other rule parsing errors. This would permit the extensibility you describe in your example without compromising the integrity of the policy. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Tue Apr 24 15:10:15 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12884 for ; Tue, 24 Apr 2001 15:10:15 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA06964; Tue, 24 Apr 2001 15:03:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA33136; Tue, 24 Apr 2001 15:02:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41198; Tue, 24 Apr 2001 10:37:22 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28632; Tue, 24 Apr 2001 10:37:19 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA30604 for ; Tue, 24 Apr 2001 10:37:21 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id KAA22892 for ; Tue, 24 Apr 2001 10:37:19 -0400 Received: from zcars04e.nortelnetworks.com by zcars0m9. (SMI-8.6/SMI-SVR4) id KAA08997; Tue, 24 Apr 2001 10:36:47 -0400 Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com; Tue, 24 Apr 2001 10:36:43 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTLZFW; Tue, 24 Apr 2001 10:36:42 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSCYF6C9; Tue, 24 Apr 2001 10:36:44 -0400 Message-Id: <3AE58EE9.4D3BEF5D@americasm01.nt.com> Date: Tue, 24 Apr 2001 10:34:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: Result of the compoundPolicyAction References: <3AE48F16.FF171888@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I'm re-posting this message because I believe that it did not make it to the list. Sorry for the inconvenience. Thanks, Mircea. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > (on a different thread:) > > The result of the execution of a compoundPolicyAction (success or > failure) is important for the execution strategy of the aggregating > policyRules or compoundPolicyAction. To avoid ambiguity, it may be good > to add a clarification to the next release of PCIMe. > > A suggestion might be: > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: > The compoundPolicyAction is successful if an aggregated policyAction is > successful. If all the aggregated policyActions fail, then the > aggregating compoundPolicyAction is considered failed. > > 2. For compoundPolicyAction.executionStrategy=Do_All: > The compoundPolicyAction is successful if all the aggregated > policyActions are successful. If one or more aggregated policyActions > fail, then the aggregating compoundPolicyAction is considered failed. > > (2bis. An alternative to 2 might be: > The compoundPolicyAction is successful if one or more aggregated > policyActions are successful. If all the aggregated policyActions fail, > then the aggregating compoundPolicyAction is considered failed. > If both 2. and 2bis are applicable in various situations then it may be > useful to add a "Do_Any" execution strategy?) > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: > The compoundPolicyAction is successful if one or more aggregated > policyActions are successful. If the first attempt to execute an > aggregated policyAction fails, then the aggregating compoundPolicyAction > is considered failed. > > Regards, > Mircea. > > P.S. BTW in PCIMe-01, the example at the end of the paragraph "4.7.2 > Compound Policy Actions" uses the retired "Mandatory Do All" decision > strategy. For consistency with the rest of the document, this should be > corrected. From majordomo@raleigh.ibm.com Tue Apr 24 15:15:09 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13032 for ; Tue, 24 Apr 2001 15:15:08 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA30180; Tue, 24 Apr 2001 15:08:36 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA35820; Tue, 24 Apr 2001 15:08:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56536; Tue, 24 Apr 2001 11:54:51 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46278; Tue, 24 Apr 2001 11:54:38 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA30152 for ; Tue, 24 Apr 2001 11:54:41 -0400 Received: from [199.203.189.130] (jr130.phasecom.co.il [199.203.189.130]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24746 for ; Tue, 24 Apr 2001 11:54:37 -0400 Received: from WNTS4EXCH.vyyo.co.il (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 24 Apr 2001 18:55:44 +0200 Received: by WNTS4EXCH.vyyo.co.il with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 18:53:25 +0200 Message-Id: From: Arie Nimkovsky To: policy@raleigh.ibm.com Subject: Using COPS for VoIP call initiation Date: Tue, 24 Apr 2001 18:53:24 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Arie Nimkovsky Hello, Our system uses a layer-2 (bridge) entity through which VoIP calls flow. This bridge should supply resources relevant to VoIP. A Call Agent which manages the call signaling will inform the bridge about the required resources for each call, and the bridge will reply the Call Agent whether it has the requested resources. If it has not - the call request be dropped by the Call Agent. My question: Is COPS suitable for such message exchange? Who is the client and who is the server in this case? It seems to me that the client/server roles are reversed here - the entity that knows about the call in progress is the Call Agent so it is the candidate for the client (PEP) role, however the actual admission will make the bridge, so from this aspect IT should be the policy enforcing point. Can someone to enlighten me on this? If not COPS - may be there is some other more suitable protocol for the stated purposes? Thanks, Arie Nimkovsky ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error (whether inadvertently addressed to you, or if forwarded to you by a recipient), please contact the sender and delete the material from any computer. This footnote also confirms that this email message has been swept by VYYO's Virus Scan Systems for the presence of computer viruses. ********************************************************************** From majordomo@raleigh.ibm.com Tue Apr 24 15:20:03 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13337 for ; Tue, 24 Apr 2001 15:20:02 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA06470; Tue, 24 Apr 2001 15:05:50 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA23714; Tue, 24 Apr 2001 15:03:06 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25262; Tue, 24 Apr 2001 10:36:39 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28582; Tue, 24 Apr 2001 10:36:26 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA23544 for ; Tue, 24 Apr 2001 10:36:28 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id KAA30230 for ; Tue, 24 Apr 2001 10:36:26 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9. (SMI-8.6/SMI-SVR4) id KAA08842; Tue, 24 Apr 2001 10:35:51 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 24 Apr 2001 10:35:31 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTLZAK; Tue, 24 Apr 2001 10:35:30 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSCYF6C6; Tue, 24 Apr 2001 10:35:32 -0400 Message-Id: <3AE58EA1.EEA17EC3@americasm01.nt.com> Date: Tue, 24 Apr 2001 10:33:05 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: <3AE47540.6A0CF253@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I'm re-posting this message because I believe that it did not make it to the list. Sorry for the inconvenience. Thanks, Mircea. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > In order to illustrate the advantages of the options 2. and 3. compared > with 0. and 1., please consider the following case: > > An administration runs a policy based QoS product (PDPs and PEPs) "QP". > This product supports actions of type "qpAction" (subclass of > policyAction). Most probably the administrators have created complex > aggregations that represent their business and network objectives. For > example: > qpGroup1 (policyGroup) > qpGroup2 (policyGroup) > qp... > qpPolicy1 (policyRule) > qp... > qpPolicy2 (policyRule) > qpCondition1 (qpCondition) > qpAction1 (policyCompoundAction) > qpAction11 (qpAction) > qpAction12 (qpAction) > qpAction2 (qpAction) > > Subsequently, the administration decides to deploy a new policy based > QoS product (PDPs and PEPs) "QPplus" by selectively replacing some of > the old "QP" systems (PDPs and PEPs). > Let's say, for example, that the "QPplus" supports all the features of > "QP" and, in addition, a new type of action: "qpLoging" (subclass of > policyAction). Let's say that this action type is non critical to the > delivery of business value but rather is useful for network engineering, > utilization data collection for statistics etc. > > In case of the options 0. and 1. since "QP" does not understand the new > action type, the aggregation trees are cloned and the clones upgraded > with instances of "qpLoging". Also, the clones will receive > different/additional policyRoles/policyKeywords in order to be > distinguished from the originals. > The cloned and upgraded aggregation tree for "QPPlus" might be: > qpPlusGroup1 (policyGroup) > qpPlusGroup2 (policyGroup) > qpPlus... > qpPlusPolicy1 (policyRule) > qpPlus... > qpPlusPolicy2 (policyRule) > qpCondition1 (qpCondition) -- can be shared with "QP" > qpPlusAction1 (policyCompoundAction) > qpPlusAction11: strategy=all (policyCompoundAction) > qpAction11 (qpAction) -- can be shared with "QP" > qpPlusLog11 (qpLogging) > qpPlusAction12: strategy=all (policyCompoundAction) > qpAction12 (qpAction) -- can be shared with "QP" > qpPlusLog12 (qpLogging) > qpPlusAction2: strategy=all (policyCompoundAction) > qpAction2 (qpAction) -- can be shared with "QP" > qpPlusLog2 (qpLogging) > > Note that most of the instances are cloned and renamed "qpPlus*" while > very few instances are shared. Since in this situation, two separate > sets of aggregation trees have to be maintained, scaleability and > manageability issues will occur sooner or later. > > In case of options 2. and 3. since it is acceptable to have unknown > action types aggregated together with the supported ones, the existing > aggregation tree is upgraded and shared among the "QP" and "QPPlus" > systems. > > Therefore, the arguments in favor of the latter options (2. and/or 3.) > derive from the ability to share more data structures across functional > domains: especially the scaleability and manageability in an environment > with several policy based functional domains. > > IMO options 0. and 1. lead to data partitioning by PDP (vendor)type and > (vendor)version which may be unacceptable in large scale a deployment of > policy based products. > > Regards, > Mircea. > > Robert Moore wrote: > > > > Mircea, > > > > There's another alternative, which, given your > > numbering scheme, would most appropriately be > > numbered 0: > > > > 0. the entire aggregation tree of Policy Groups > > and Policy Rules containing the rule in > > question fails to load on the PDP or to be > > communicated to the PEP > > > > The motivation for this alternative would be > > concern about unpredictable (and potentially > > undesirable) results if *anything* about the > > entire "policy" (which I'm interpreting as the > > entire aggregation tree, complete with its > > priorities and execution strategies) is > > unrecognized / unsupported. > > > > This may result in a whole lot of cases where > > policies don't load at all, because some > > component or other of them is unrecognized / > > unsupported. But if your overriding goal > > (maybe "overriding constraint" is a better way > > to say it) with policy-based management is > > "no surprises," then this is exactly how you'd > > want it to work. > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > > > "Mircea Pana" @raleigh.ibm.com on 04/20/2001 > > 06:00:48 PM > > > > Please respond to "Mircea Pana" > > > > Sent by: policy-owner@raleigh.ibm.com > > > > To: IETF Policy > > cc: > > Subject: Re: criticality of extended conditions and actions > > > > Marcus, in a previous message you suggested that in case of unsupported > > components (conditions, actions) "the loading of the whole rule fails". > > In the message below you suggest that "a unsupported action could be > > regarded an action failure" which is different from the first one. > > Please excuse me if I got it wrong! > > > > In case of a set of actions aggregated in a rule, if an action is > > unsupported on the PDP or PEP, then which one of the following cases is > > the right one? > > > > 1. the entire rule fails to load on the PDP or to be communicated to the > > PEP > > 2. the unsupported action is ignored and the others are executed in > > conformance with the execution strategy. > > 3. the unsupported action is considered failed and depending on the > > execution strategy, the other actions may be executed > > > > Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP > > relative to unsupported extensions. > > > > Regards, > > Mircea. > > [snip] From majordomo@raleigh.ibm.com Tue Apr 24 15:29:55 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13545 for ; Tue, 24 Apr 2001 15:29:53 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA28900; Tue, 24 Apr 2001 15:13:03 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA09204; Tue, 24 Apr 2001 15:08:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61788; Tue, 24 Apr 2001 12:08:42 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28582; Tue, 24 Apr 2001 10:36:26 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA23544 for ; Tue, 24 Apr 2001 10:36:28 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id KAA30230 for ; Tue, 24 Apr 2001 10:36:26 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9. (SMI-8.6/SMI-SVR4) id KAA08842; Tue, 24 Apr 2001 10:35:51 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 24 Apr 2001 10:35:31 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTLZAK; Tue, 24 Apr 2001 10:35:30 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSCYF6C6; Tue, 24 Apr 2001 10:35:32 -0400 Message-Id: <3AE58EA1.EEA17EC3@americasm01.nt.com> Date: Tue, 24 Apr 2001 10:33:05 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: criticality of extended conditions and actions References: <3AE47540.6A0CF253@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit I'm re-posting this message because I believe that it did not make it to the list. Sorry for the inconvenience. Thanks, Mircea. "Pana, Mircea [CAR:5E20:EXCH]" wrote: > > In order to illustrate the advantages of the options 2. and 3. compared > with 0. and 1., please consider the following case: > > An administration runs a policy based QoS product (PDPs and PEPs) "QP". > This product supports actions of type "qpAction" (subclass of > policyAction). Most probably the administrators have created complex > aggregations that represent their business and network objectives. For > example: > qpGroup1 (policyGroup) > qpGroup2 (policyGroup) > qp... > qpPolicy1 (policyRule) > qp... > qpPolicy2 (policyRule) > qpCondition1 (qpCondition) > qpAction1 (policyCompoundAction) > qpAction11 (qpAction) > qpAction12 (qpAction) > qpAction2 (qpAction) > > Subsequently, the administration decides to deploy a new policy based > QoS product (PDPs and PEPs) "QPplus" by selectively replacing some of > the old "QP" systems (PDPs and PEPs). > Let's say, for example, that the "QPplus" supports all the features of > "QP" and, in addition, a new type of action: "qpLoging" (subclass of > policyAction). Let's say that this action type is non critical to the > delivery of business value but rather is useful for network engineering, > utilization data collection for statistics etc. > > In case of the options 0. and 1. since "QP" does not understand the new > action type, the aggregation trees are cloned and the clones upgraded > with instances of "qpLoging". Also, the clones will receive > different/additional policyRoles/policyKeywords in order to be > distinguished from the originals. > The cloned and upgraded aggregation tree for "QPPlus" might be: > qpPlusGroup1 (policyGroup) > qpPlusGroup2 (policyGroup) > qpPlus... > qpPlusPolicy1 (policyRule) > qpPlus... > qpPlusPolicy2 (policyRule) > qpCondition1 (qpCondition) -- can be shared with "QP" > qpPlusAction1 (policyCompoundAction) > qpPlusAction11: strategy=all (policyCompoundAction) > qpAction11 (qpAction) -- can be shared with "QP" > qpPlusLog11 (qpLogging) > qpPlusAction12: strategy=all (policyCompoundAction) > qpAction12 (qpAction) -- can be shared with "QP" > qpPlusLog12 (qpLogging) > qpPlusAction2: strategy=all (policyCompoundAction) > qpAction2 (qpAction) -- can be shared with "QP" > qpPlusLog2 (qpLogging) > > Note that most of the instances are cloned and renamed "qpPlus*" while > very few instances are shared. Since in this situation, two separate > sets of aggregation trees have to be maintained, scaleability and > manageability issues will occur sooner or later. > > In case of options 2. and 3. since it is acceptable to have unknown > action types aggregated together with the supported ones, the existing > aggregation tree is upgraded and shared among the "QP" and "QPPlus" > systems. > > Therefore, the arguments in favor of the latter options (2. and/or 3.) > derive from the ability to share more data structures across functional > domains: especially the scaleability and manageability in an environment > with several policy based functional domains. > > IMO options 0. and 1. lead to data partitioning by PDP (vendor)type and > (vendor)version which may be unacceptable in large scale a deployment of > policy based products. > > Regards, > Mircea. > > Robert Moore wrote: > > > > Mircea, > > > > There's another alternative, which, given your > > numbering scheme, would most appropriately be > > numbered 0: > > > > 0. the entire aggregation tree of Policy Groups > > and Policy Rules containing the rule in > > question fails to load on the PDP or to be > > communicated to the PEP > > > > The motivation for this alternative would be > > concern about unpredictable (and potentially > > undesirable) results if *anything* about the > > entire "policy" (which I'm interpreting as the > > entire aggregation tree, complete with its > > priorities and execution strategies) is > > unrecognized / unsupported. > > > > This may result in a whole lot of cases where > > policies don't load at all, because some > > component or other of them is unrecognized / > > unsupported. But if your overriding goal > > (maybe "overriding constraint" is a better way > > to say it) with policy-based management is > > "no surprises," then this is exactly how you'd > > want it to work. > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > > > "Mircea Pana" @raleigh.ibm.com on 04/20/2001 > > 06:00:48 PM > > > > Please respond to "Mircea Pana" > > > > Sent by: policy-owner@raleigh.ibm.com > > > > To: IETF Policy > > cc: > > Subject: Re: criticality of extended conditions and actions > > > > Marcus, in a previous message you suggested that in case of unsupported > > components (conditions, actions) "the loading of the whole rule fails". > > In the message below you suggest that "a unsupported action could be > > regarded an action failure" which is different from the first one. > > Please excuse me if I got it wrong! > > > > In case of a set of actions aggregated in a rule, if an action is > > unsupported on the PDP or PEP, then which one of the following cases is > > the right one? > > > > 1. the entire rule fails to load on the PDP or to be communicated to the > > PEP > > 2. the unsupported action is ignored and the others are executed in > > conformance with the execution strategy. > > 3. the unsupported action is considered failed and depending on the > > execution strategy, the other actions may be executed > > > > Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP > > relative to unsupported extensions. > > > > Regards, > > Mircea. > > [snip] From majordomo@raleigh.ibm.com Tue Apr 24 15:59:31 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14063 for ; Tue, 24 Apr 2001 15:59:30 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA27480; Tue, 24 Apr 2001 15:53:10 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA25412; Tue, 24 Apr 2001 15:13:20 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41948; Tue, 24 Apr 2001 13:07:34 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44994; Tue, 24 Apr 2001 09:55:15 -0400 Received: from lmr (dyn9-37-48-102.raleigh.ibm.com [9.37.48.102]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA31544 for ; Tue, 24 Apr 2001 09:55:17 -0400 Message-Id: <007501c0ccc5$c4f52e40$66302509@raleigh.ibm.com> From: "Lee Rafalow" To: "IETF Policy" References: <3AE47540.6A0CF253@americasm01.nt.com> Subject: Re: criticality of extended conditions and actions Date: Tue, 24 Apr 2001 09:52:14 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Mircea, Let's break this down into it's component parts: rule compilation unit of failure and optional rule components. It's difficult for me to imagine that there are sets of rules that can have a rule removed and still somehow reflect the intent of the administrator. So I think that the unit of failure should be the whole aggregated set of rules. Your example does, however, raise a good point about extending sets of actions. (I still don't see this extending to conditions, however.) It seems reasonable to me that we could define a boolean in PolicyAction that indicates that a recognition failure for a given action instance does not constitute a compilation failure. (Actually, this should really be a class variable, but we don't have class variables in our model. CIM has qualifiers that can serve as class variables but they're a clumsy substitute.) How's this? NAME MayIgnoreAction DESCRIPTION This boolean may be set to indicate that an action instance may be ignored by rule engine. Actions that may be ignored extend the actions of a rule but, if not supported, may be ignored and do not cause the set of rules to be rejected by the PDP or PEP. SYNTAX boolean DEFAULT false Implementations MAY support the property. If not supported and an action is not recognized by the implementation, the aggregation of rules (we need a name for this thing) is rejected as in other rule parsing errors. This would permit the extensibility you describe in your example without compromising the integrity of the policy. Lee M. Rafalow Voice: 1-919-254-4455; Fax: 1-919-254-6243 IBM Internet Technology Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709 USA Alternate email: rafalow@us.ibm.com Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Tue Apr 24 20:43:41 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18750 for ; Tue, 24 Apr 2001 20:43:41 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA39366; Tue, 24 Apr 2001 20:26:38 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id UAA26038; Tue, 24 Apr 2001 20:19:27 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54386; Tue, 24 Apr 2001 14:54:22 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29532; Tue, 24 Apr 2001 14:54:19 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA09180 for ; Tue, 24 Apr 2001 14:54:23 -0400 Received: from zcars0m9. (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id OAA33430 for ; Tue, 24 Apr 2001 14:53:40 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9. (SMI-8.6/SMI-SVR4) id OAA10062; Tue, 24 Apr 2001 14:52:48 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 24 Apr 2001 14:52:34 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTM6HC; Tue, 24 Apr 2001 14:52:33 -0400 Received: from americasm01.nt.com (MPANA-1 [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSCYF6SF; Tue, 24 Apr 2001 14:52:36 -0400 Message-Id: <3AE5CAE0.E4F30817@americasm01.nt.com> Date: Tue, 24 Apr 2001 14:50:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: ABS vs. AUX Condition and Action was: WG Last Call on draft-ietf-policy-core-schema-10.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit The policyCondition and policyAction are modeled as auxiliary object classes. Therefore it seems to be valid to attach them without specialization to entries of various structural classes. Should this be allowed? For example: LDAP allows the attachment of a policyConditionAuxClass class to a policyInstance entry without attaching any of the policyConditionAuxClass subclasses. IMO: If this is acceptable then a clarification should be added to PCLS to describe the evaluation / execution semantics? If this is not acceptable then additional constraints should be added as text or the class types should be changed from AUXILIARY to ABSTRACT. Regards, Mircea. From majordomo@raleigh.ibm.com Wed Apr 25 15:57:53 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29221 for ; Wed, 25 Apr 2001 15:57:52 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA23644; Wed, 25 Apr 2001 15:47:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA29646; Wed, 25 Apr 2001 15:47:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61504; Wed, 25 Apr 2001 15:17:18 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56632; Wed, 25 Apr 2001 15:17:15 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA29974; Wed, 25 Apr 2001 15:17:19 -0400 Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id PAA39748; Wed, 25 Apr 2001 15:17:15 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id PAA03427; Wed, 25 Apr 2001 15:14:16 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 25 Apr 2001 15:14:07 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JNHTRNTW; Wed, 25 Apr 2001 15:14:07 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JSCYF7ZD; Wed, 25 Apr 2001 15:14:09 -0400 Message-Id: <3AE72169.CB56DD6C@americasm01.nt.com> Date: Wed, 25 Apr 2001 15:11:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Lee Rafalow Cc: IETF Policy Subject: Re: criticality of extended conditions and actions References: <3AE47540.6A0CF253@americasm01.nt.com> <007501c0ccc5$c4f52e40$66302509@raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Lee, Your proposal sounds good. I've added a few comments in-line and marked them . Thanks, Mircea. Lee Rafalow wrote: > > Mircea, > > Let's break this down into it's component parts: rule compilation unit of > failure and optional rule components. > > It's difficult for me to imagine that there are sets of rules that can have > a rule removed and still somehow reflect the intent of the administrator. The policyGroup can be used to group together other policyGroups and/or policyRules under the same administrative role. If the components of the group serve different functional domains, the policyGroup itself can be thought as a policy bundle. Let's consider an example: An organization has edge devices serving connections with its (1)customers and (2)providers. These devices implement different functions: (1) firewall, (2) QoS, (3) encryption. One way of bundling the policies may be: Group1: role=customer Rule1: if TrafficToInternetExceptSomeSites then Firewall-Allow Rule2: if Mon-Fri AND 08:00-17:00 then QoS-HighPriority Rule3: if TrafficToOrFromBank then VPN-Encrypt Group2: role=provider etc. Therefore, Group1 is applicable to all the firewalls, QoS interfaces, VPN gateways that serve the role "customer". There may be different PDPs per functionality and/or PDPs combining some or all functions. The fact that the QoS PDP/PEP does not support Rule1 and Rule3 should not stop it from enforcing Rule2. However, if the policyGroup is not suitable for such use, then may be we should define a separate policyBundle that is allowed to span across functional domains. Is this in scope for the Policy WG? > So I think that the unit of failure should be the whole aggregated set of > rules. I understand the reason behind this but I'm not comfortable with its potential impact on the network. There should be an easy way to evaluate the impact * before * it happens. > > Your example does, however, raise a good point about extending sets of > actions. (I still don't see this extending to conditions, however.) It How about a condition like this: (SourceOSIAddress = X25Value) OR (SourceIPAddress = IPv4Value) OR (SourceIPAddress = IPv6Value) loaded/evaluated by a device with no X25 support. Should the rule (or the entire aggreg.) fail? How about a device that only implements IPv4 (no IPv6)? > seems reasonable to me that we could define a boolean in PolicyAction that > indicates that a recognition failure for a given action instance does not > constitute a compilation failure. (Actually, this should really be a class > variable, but we don't have class variables in our model. CIM has > qualifiers that can serve as class variables but they're a clumsy > substitute.) I'm happy with the instance variable, it gives more control to the administrator. > > How's this? > > NAME MayIgnoreAction > DESCRIPTION This boolean may be set to indicate that an > action instance may be ignored by rule engine. > Actions that may be ignored extend the actions of > a rule but, if not supported, may be ignored and > do not cause the set of rules to be rejected by > the PDP or PEP. > SYNTAX boolean > DEFAULT false > > Implementations MAY support the property. If not supported and an action is Sounds good but... What if we make it: "implementations SHOULD". The reason is that implementations that do not support this flag can hardly share data with other similar ones. > not recognized by the implementation, the aggregation of rules (we need a > name for this thing) is rejected as in other rule parsing errors. > > This would permit the extensibility you describe in your example without > compromising the integrity of the policy. > > Lee M. Rafalow > Voice: 1-919-254-4455; Fax: 1-919-254-6243 > IBM Internet Technology Management > IBM Corporation > P.O. Box 12195, BRQA/502 > RTP, NC 27709 USA > Alternate email: rafalow@us.ibm.com > Home email: rafalow@mindspring.com From majordomo@raleigh.ibm.com Wed Apr 25 21:06:48 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05201 for ; Wed, 25 Apr 2001 21:06:48 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA31580; Wed, 25 Apr 2001 20:47:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA25460; Wed, 25 Apr 2001 19:15:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28724; Wed, 25 Apr 2001 18:50:38 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57644; Wed, 25 Apr 2001 18:50:35 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA43342 for ; Wed, 25 Apr 2001 18:50:40 -0400 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 SAA30968 for ; Wed, 25 Apr 2001 18:50:36 -0400 Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn2.cisco.com [171.68.12.75]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA12647; Wed, 25 Apr 2001 15:48:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425172638.033ebdd0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Apr 2001 17:30:59 -0400 To: "Mircea Pana" From: John Schnizlein Subject: Re: criticality of extended conditions and actions Cc: IETF Policy In-Reply-To: <3AE72169.CB56DD6C@americasm01.nt.com> References: <3AE47540.6A0CF253@americasm01.nt.com> <007501c0ccc5$c4f52e40$66302509@raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein Mircea, Yes, the strategy of distributing policies and hoping they work (with some conflict detection late in the process) has been broken for a long time. I appreciate your raising this problem again. John At 03:11 PM 4/25/2001, Mircea Pana wrote: >Lee Rafalow wrote: > >> So I think that the unit of failure should be the whole >> aggregated set of rules. > > >I understand the reason behind this but I'm not comfortable >with its potential impact on the network. There should be an >easy way to evaluate the impact * before * it happens. > From majordomo@raleigh.ibm.com Fri Apr 27 16:56:00 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15749 for ; Fri, 27 Apr 2001 16:55:59 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA36838; Fri, 27 Apr 2001 16:48:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA55598; Fri, 27 Apr 2001 16:44:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52976; Fri, 27 Apr 2001 16:10:15 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AB36790; Fri, 27 Apr 2001 16:10:06 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA60692 for ; Fri, 27 Apr 2001 16:10:11 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA27268 for ; Fri, 27 Apr 2001 16:10:07 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 16:07:33 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Cc: "'Joel M. Halpern'" Subject: WG Last Call on Terminology Draft, draft-ietf-policy-terminology- 03.txt Date: Fri, 27 Apr 2001 16:07:33 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson The latest revision of the Terminology Draft is in the I-D repository. This revision reflects all known issues and comments. This note commences a two week working group last call, intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document for informational status. This last call ends at CoB on Fri, May 10. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Thank you, Ed Ellesson w/ Joel M. Halpern From majordomo@raleigh.ibm.com Fri Apr 27 17:17:01 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16428 for ; Fri, 27 Apr 2001 17:17:00 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA28434; Fri, 27 Apr 2001 17:09:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA23988; Fri, 27 Apr 2001 17:09:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA63758; Fri, 27 Apr 2001 16:41:58 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49158; Fri, 27 Apr 2001 16:41:55 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA55674 for ; Fri, 27 Apr 2001 16:42:01 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA37302 for ; Fri, 27 Apr 2001 16:41:58 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 16:39:24 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: Revised: WG Last Call on Terminology, draft-ietf-policy-terminol ogy-03.txt Date: Fri, 27 Apr 2001 16:39:23 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson Oops! Fri is May 11, not May 10. I also modified the words for how we submit the draft for publication. The latest revision of the Terminology Draft is in the I-D repository. This revision reflects all known issues and comments. This note commences a two week working group last call, intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. This last call ends at CoB on Fri, May 11. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Thank you, Ed Ellesson w/ Joel M. Halpern From majordomo@raleigh.ibm.com Fri Apr 27 22:01:50 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22933 for ; Fri, 27 Apr 2001 22:01:49 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA20364; Fri, 27 Apr 2001 21:54:23 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA66544; Fri, 27 Apr 2001 21:50:51 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33960; Fri, 27 Apr 2001 18:30:24 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33936; Fri, 27 Apr 2001 18:30:19 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA09056 for ; Fri, 27 Apr 2001 18:30:19 -0400 From: moats@tconl.com Received: from hermes.tconl.com (mail.tconl.com [204.26.80.9]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA21192 for ; Fri, 27 Apr 2001 18:30:16 -0400 Received: from 10.9.200.11 ([10.100.0.124]) by hermes.tconl.com (8.11.0/TeleChoice) with SMTP id f3RMNNg11075; Fri, 27 Apr 2001 17:23:23 -0500 Message-Id: <200104272223.f3RMNNg11075@hermes.tconl.com> To: "Mircea Pana" , policy@raleigh.ibm.com Cc: Ed Ellesson , "Joel M. Halpern" Subject: re: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt Date: 27 Apr 2001 17:22:53 -0600 X-Mailer: NeoPlanet Version: 5.2.0.1702 X-Id: CFC0538004D911D5A37A0080AD732513 X-Brand: NeoPlanet X-Build: 1702 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: moats@tconl.com Mircea- What we are trying to capture is that you can attach subclasses of policyConditionAuxClass and policyActionAuxClass. Attaching those classes is (in my view) a null action, because they don't define anything. We are bound by the LDAP syntax rules because if we mark them as ABSTRACT, then we cannot use them in any content rules and the content rules should be as general as possible so that future updates don't require an update of this document. This (I think) is clarified by the following changes: Add the following sentence to the second paragraph of Section 5: If your implementation does not support auxiliary class inheritance and supports content rules, you will have to list auxiliary classes in content rules explicitly. Replace the first paragraph of 5.7 with The purpose of a policy condition is to determine whether or not the set of actions (contained in the policyRule that the condition applies to) should be executed or not. Subclasses of this auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When a subclass of this class is attached to an instance of policyRuleConditionAssociation, or to an instance of policyRule, it represents a rule-specific policy condition. When a subclass of this class is attached to an instance of policyInstance, it represents a reusable policy condition. and replace the first paragraph of 5.10 with The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc. in order to achieve a desired policy state. Subclasses of this auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When a subclass of this class is attached to an instance of policyRuleActionAssociation, or to an instance of policyRule, it represents a rule-specific policy action. When a subclass of this class is attached to an instance of policyInstance, it represents a reusable policy action. Ryan > ** Original Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt > ** Original Sender: "Mircea Pana" > ** Original Date: Fri, 27 Apr 2001 09:22:16 -0500 > ** Original Message follows... > > I would greatly appreciate if the authors could address this issue > before the end of the "last call" (CoB Mon., April 30). > > Thanks, > Mircea. > > > "Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote: > > > > The policyCondition and policyAction are modeled as auxiliary object > > classes. Therefore it seems to be valid to attach them without > > specialization to entries of various structural classes. Should this be > > allowed? For example: LDAP allows the attachment of a > > policyConditionAuxClass class to a policyInstance entry without > > attaching any of the policyConditionAuxClass subclasses. > > > > IMO: If this is acceptable then a clarification should be added to PCLS > > to describe the evaluation / execution semantics? If this is not > > acceptable then additional constraints should be added as text or the > > class types should be changed from AUXILIARY to ABSTRACT. > > > > Regards, > > Mircea. > > Ed Ellesson wrote: > > > > The latest revision of the Policy Framework LDAP Core Schema is in the I-D > > repository. This revision reflects all known issues and comments. > > This note commences a two week working group last call, intended to bring > > forth any last issues. After such issues are resolved according to the > > working group consensus, we will be submitting this document to the IESG > > for approval as a proposed standard. > > > > This last call ends at CoB on Mon, April 30. > > > > Thank you, > > Joel M. Halpern > > w/ Ed Ellesson >** --------- End Original Message ----------- ** > From majordomo@raleigh.ibm.com Mon Apr 30 20:00:33 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28660 for ; Mon, 30 Apr 2001 20:00:32 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAB20742; Mon, 30 Apr 2001 19:53:29 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id TAA27436; Mon, 30 Apr 2001 19:53:27 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54374; Mon, 30 Apr 2001 13:14:23 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50780; Mon, 30 Apr 2001 13:14:19 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA25414 for ; Mon, 30 Apr 2001 13:14:21 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA28608 for ; Mon, 30 Apr 2001 13:14:18 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3UHEHj18037 for ; Mon, 30 Apr 2001 13:14:17 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f3UHEGs17969 for ; Mon, 30 Apr 2001 13:14:16 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 19:14:06 +0200 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0C28AEA2@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Policy Framework WG Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt Date: Mon, 30 Apr 2001 19:14:03 +0200 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)" I think Randy has a point here! Bert > ---------- > From: Randy Bush[SMTP:randy@psg.com] > Sent: Thursday, April 26, 2001 6:21 PM > To: Bert Wijnen > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > perhaps the title of this draft could be narrowed a bit. > > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Cc: policy@raleigh.ibm.com > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Policy Framework Working Group of the > IETF. > > Title : Terminology > Author(s) : A. Westerinen et al. > Filename : draft-ietf-policy-terminology-03.txt > Pages : 20 > Date : 25-Apr-01 > > This document is a glossary of policy-related terms. It > provides abbreviations, explanations, and recommendations for > use of these terms. The document takes the approach and format > of RFC2828 [R2828], which defines an Internet Security Glossary. > The intent is to improve the comprehensibility and consistency > of writing that deals with network policy, particularly Internet > Standards documents (ISDs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-policy-terminology-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20010425143032.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-policy-terminology-03.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20010425143032.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > ------- end of forwarded message ------- >