From majordomo@raleigh.ibm.com Mon Apr 3 20:35:49 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29131 for ; Mon, 3 Apr 2000 20:35:48 -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 UAA19194; Mon, 3 Apr 2000 20:31:51 -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 UAA29838; Mon, 3 Apr 2000 20:31:53 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53294; Mon, 3 Apr 2000 20:02:41 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23278; Mon, 3 Apr 2000 20:02:35 -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 UAA28052 for ; Mon, 3 Apr 2000 20:02:39 -0400 Received: from mail.webstream.net ([63.77.144.9]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA26962 for ; Mon, 3 Apr 2000 20:02:34 -0400 Received: from shiva ([205.179.45.172]) by mail.webstream.net (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id net for ; Mon, 3 Apr 2000 20:04:02 -0400 Message-Id: <006f01bf9dc7$bf176f20$ac2db3cd@deterministicnetworks.com> From: daljit@DeterministicNetworks.com (Daljit Singh) To: Subject: COPS Implementation And Compatibility Date: Mon, 3 Apr 2000 16:52:57 -0700 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01BF9D8D.10D35C60" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: daljit@DeterministicNetworks.com (Daljit Singh) This is a multi-part message in MIME format. ------=_NextPart_000_006C_01BF9D8D.10D35C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Last week, in response to Mr. Dhiman's inquiry about COPS = Implementation, many companies, including HP, Cisco, Intel and IPHighway responded with their = implementation. Many provides SDK to write policy clients for their servers. I presume, = policy client using SDK from one company should work with the servers from the others. Can = someone confirm the compatibility between policy clients and servers from different = companies? Daljit -------------------------------------------------------------------------= ---------------------- Daljit Singh email: daljit@DeterministicNetworks.com Tel: (831) 421-0388 X21 Fax: (831) 421-0394 -------------------------------------------------------------------------= ----------------------- ------=_NextPart_000_006C_01BF9D8D.10D35C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
    Last week, in = response to Mr.=20 Dhiman's inquiry about COPS Implementation, many
companies, including HP, Cisco, Intel = and IPHighway=20 responded with their implementation.
Many provides SDK to write policy = clients for their=20 servers. I presume, policy client using
SDK from one company should work with = the servers=20 from the others. Can someone confirm
the compatibility between policy = clients and=20 servers from different companies?
 
Daljit
----------------------------------------------------------------= -------------------------------
Daljit=20 Singh
email: daljit@DeterministicNetw= orks.com
Tel:   =20 (831) 421-0388 X21
Fax:   (831)=20 421-0394
-------------------------------------------------------------= -----------------------------------
------=_NextPart_000_006C_01BF9D8D.10D35C60-- From majordomo@raleigh.ibm.com Mon Apr 3 22:02:12 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02124 for ; Mon, 3 Apr 2000 22:02:12 -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 VAA19140; Mon, 3 Apr 2000 21:58:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA30082; Mon, 3 Apr 2000 21:58:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA62356; Mon, 3 Apr 2000 21:33:02 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59108; Mon, 3 Apr 2000 21:32:50 -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 VAA32850 for ; Mon, 3 Apr 2000 21:32:54 -0400 Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA07050 for ; Mon, 3 Apr 2000 21:32:49 -0400 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Mon, 3 Apr 2000 21:18:42 -0400 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2BCS4NGH; Mon, 3 Apr 2000 21:18:41 -0400 Received: from cr734636a (CR734636-A [132.245.139.194]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HR1A0T7V; Mon, 3 Apr 2000 21:18:39 -0400 Message-Id: <00c701bf9dd3$20d2a800$04000005@flfrd1.on.wave.home.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rajiv Dighe" To: Daljit Singh , POLICY References: <006f01bf9dc7$bf176f20$ac2db3cd@deterministicnetworks.com> Subject: Re: COPS Implementation And Compatibility Date: Mon, 3 Apr 2000 21:14:29 -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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Rajiv Dighe" Content-Transfer-Encoding: 7bit Daljit, It's in the interest of all the vendors to make sure that server & client implementations from them interoperate with implementations from others. Infact few days ago we even had an interoperability testing for COPS-PR server & client implementations. It is planned that such interoperability event will be repeated at regular intervals to ensure that all clients & servers talk to each other nicely. Hope that answers your question. Regards, --Rajiv --------------------- Nortel Networks NetID group 613-798-4914 --------------------- ----- Original Message ----- From: "Daljit Singh" To: "POLICY" Sent: Monday, April 03, 2000 7:52 PM Subject: COPS Implementation And Compatibility Hi, Last week, in response to Mr. Dhiman's inquiry about COPS Implementation, many companies, including HP, Cisco, Intel and IPHighway responded with their implementation. Many provides SDK to write policy clients for their servers. I presume, policy client using SDK from one company should work with the servers from the others. Can someone confirm the compatibility between policy clients and servers from different companies? Daljit ------------------------------------------------------------------------ ----------------------- Daljit Singh email: daljit@DeterministicNetworks.com Tel: (831) 421-0388 X21 Fax: (831) 421-0394 ------------------------------------------------------------------------ ------------------------ From majordomo@raleigh.ibm.com Tue Apr 4 01:19:20 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10155 for ; Tue, 4 Apr 2000 01:19:19 -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 BAA24658; Tue, 4 Apr 2000 01:15:32 -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 BAA27942; Tue, 4 Apr 2000 01:15:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51084; Tue, 4 Apr 2000 00:48:54 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24154; Tue, 4 Apr 2000 00:48:49 -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 AAA31310 for ; Tue, 4 Apr 2000 00:48:53 -0400 Received: from mail.webstream.net ([63.77.144.9]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA26838 for ; Tue, 4 Apr 2000 00:48:49 -0400 Received: from prince ([209.239.198.52]) by mail.webstream.net (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id net; Tue, 4 Apr 2000 00:50:20 -0400 Message-Id: <001201bf9df0$2a477060$34c6efd1@InReach.com> From: daljit@DeterministicNetworks.com (Daljit Singh) To: "Rajiv Dighe" , "POLICY" References: <006f01bf9dc7$bf176f20$ac2db3cd@deterministicnetworks.com> <00c701bf9dd3$20d2a800$04000005@flfrd1.on.wave.home.com> Subject: Re: COPS Implementation And Compatibility Date: Mon, 3 Apr 2000 21:42:19 -0700 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.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: daljit@DeterministicNetworks.com (Daljit Singh) Content-Transfer-Encoding: 7bit Rajiv, Can you provide a list of all the vendors involved in this interoperability testing? Do we have the results of these tests available? Thanks. Daljit ---------------------------------------------------------------------------- ------------ Daljit Singh Deterministic Networks, Inc. Tel: 831-421-0388 x21 ---------------------------------------------------------------------------- ------- > Daljit, > > It's in the interest of all the vendors to make sure that server & > client implementations from them interoperate with implementations from > others. Infact few days ago we even had an interoperability testing for > COPS-PR server & client implementations. It is planned that such > interoperability event will be repeated at regular intervals to ensure that > all clients & servers talk to each other nicely. Hope that answers your > question. > > Regards, > > --Rajiv > --------------------- > Nortel Networks > NetID group > 613-798-4914 > --------------------- > > ----- Original Message ----- > From: "Daljit Singh" > To: "POLICY" > Sent: Monday, April 03, 2000 7:52 PM > Subject: COPS Implementation And Compatibility > > > Hi, > > Last week, in response to Mr. Dhiman's inquiry about COPS > Implementation, many > companies, including HP, Cisco, Intel and IPHighway responded with their > implementation. > Many provides SDK to write policy clients for their servers. I presume, > policy client using > SDK from one company should work with the servers from the others. Can > someone confirm > the compatibility between policy clients and servers from different > companies? > > Daljit > ------------------------------------------------------------------------ > ----------------------- > Daljit Singh > email: daljit@DeterministicNetworks.com > > Tel: (831) 421-0388 X21 > Fax: (831) 421-0394 > ------------------------------------------------------------------------ > ------------------------ > > > From majordomo@raleigh.ibm.com Tue Apr 4 08:43:14 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01241 for ; Tue, 4 Apr 2000 08:43:14 -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 IAA18968; Tue, 4 Apr 2000 08:36:27 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA30110; Tue, 4 Apr 2000 08:36:27 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54622; Tue, 4 Apr 2000 08:10:22 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26120; Tue, 4 Apr 2000 08:09:50 -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 IAA24862 for ; Tue, 4 Apr 2000 08:09:50 -0400 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA28470 for ; Tue, 4 Apr 2000 08:09:48 -0400 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Tue, 4 Apr 2000 07:09:01 -0500 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2HZJXR28; Tue, 4 Apr 2000 08:08:57 -0400 Received: from cr734636a (CR734636-A [132.245.139.171]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HR1A0T8J; Tue, 4 Apr 2000 08:08:55 -0400 Message-Id: <018f01bf9e2d$f141c700$04000005@flfrd1.on.wave.home.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rajiv Dighe" To: Daljit Singh , POLICY References: <006f01bf9dc7$bf176f20$ac2db3cd@deterministicnetworks.com> <00c701bf9dd3$20d2a800$04000005@flfrd1.on.wave.home.com> <001201bf9df0$2a477060$34c6efd1@InReach.com> Subject: Re: COPS Implementation And Compatibility Date: Tue, 4 Apr 2000 08:04:33 -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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Rajiv Dighe" Content-Transfer-Encoding: 7bit Daljit, Please give me till tomorrow. I am checking my e-mail from work for today. as soon as I reach home, I will forward relevant press release that was jointly released by all companies involved. that press release has all the details...unless offcourse someone else beats me to it. --Rajiv ----- Original Message ----- From: "Daljit Singh" To: "Dighe, Rajiv (R.) [EXCHANGE:CANOI:IO47]" ; "POLICY" Sent: Tuesday, April 04, 2000 12:42 AM Subject: Re: COPS Implementation And Compatibility > Rajiv, > > Can you provide a list of all the vendors involved in this > interoperability testing? > Do we have the results of these tests available? > > Thanks. > > Daljit > > -------------------------------------------------------------------------- -- > ------------ > Daljit Singh > Deterministic Networks, Inc. > Tel: 831-421-0388 x21 > -------------------------------------------------------------------------- -- > ------- > > > Daljit, > > > > It's in the interest of all the vendors to make sure that server & > > client implementations from them interoperate with implementations from > > others. Infact few days ago we even had an interoperability testing for > > COPS-PR server & client implementations. It is planned that such > > interoperability event will be repeated at regular intervals to ensure > that > > all clients & servers talk to each other nicely. Hope that answers your > > question. > > > > Regards, > > > > --Rajiv > > --------------------- > > Nortel Networks > > NetID group > > 613-798-4914 > > --------------------- > > > > ----- Original Message ----- > > From: "Daljit Singh" > > To: "POLICY" > > Sent: Monday, April 03, 2000 7:52 PM > > Subject: COPS Implementation And Compatibility > > > > > > Hi, > > > > Last week, in response to Mr. Dhiman's inquiry about COPS > > Implementation, many > > companies, including HP, Cisco, Intel and IPHighway responded with their > > implementation. > > Many provides SDK to write policy clients for their servers. I presume, > > policy client using > > SDK from one company should work with the servers from the others. Can > > someone confirm > > the compatibility between policy clients and servers from different > > companies? > > > > Daljit > > ------------------------------------------------------------------------ > > ----------------------- > > Daljit Singh > > email: daljit@DeterministicNetworks.com > > > > Tel: (831) 421-0388 X21 > > Fax: (831) 421-0394 > > ------------------------------------------------------------------------ > > ------------------------ > > > > > > > From majordomo@raleigh.ibm.com Tue Apr 4 09:10:48 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02137 for ; Tue, 4 Apr 2000 09:10:48 -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 JAA28924; Tue, 4 Apr 2000 09:05:32 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA22760; Tue, 4 Apr 2000 09:05:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA59018; Tue, 4 Apr 2000 08:41:34 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56118; Tue, 4 Apr 2000 08:41:24 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA34108 for ; Tue, 4 Apr 2000 08:41:25 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA24800 for ; Tue, 4 Apr 2000 08:41:23 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA01941 for ; Tue, 4 Apr 2000 08:41:23 -0400 (EDT) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA01935 for ; Tue, 4 Apr 2000 08:41:23 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Apr 2000 08:41:23 -0400 Message-Id: <10632F7077C0D11190B900805F6F851C0507B261@nj7460exch002u.ho.lucent.com> From: "Macri, Philip P (Philip)" To: "'POLICY'" Subject: Implementation of services employing COPS Date: Tue, 4 Apr 2000 08:41:22 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Macri, Philip P (Philip)" Hi; I am new to Policy based management. Can anyone tell me or point me to the services which have been implemented emplying the COPS protocol? For example: RSVP. Thanks Phil Philip Macri Lucent Technologies, Inc HCP 21A 2139 Highway 35 Holmdel, N.J 07733 Phone: (732)-332-2407 Fax: (732)-332-2464 e-mail: pmacri@lucent.com (732)-224-0113 (Home) pmacri@home.com (Home) From majordomo@raleigh.ibm.com Thu Apr 6 12:33:56 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10840 for ; Thu, 6 Apr 2000 12:33:56 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA31554; Thu, 6 Apr 2000 12:28:41 -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 MAA31756; Thu, 6 Apr 2000 12:28:41 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA62534; Thu, 6 Apr 2000 11:57:21 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29496; Thu, 6 Apr 2000 11:57:17 -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 LAA27958 for ; Thu, 6 Apr 2000 11:57:20 -0400 Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA22326 for ; Thu, 6 Apr 2000 11:57:19 -0400 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Thu, 6 Apr 2000 11:57:07 -0400 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2L4S5NSS; Thu, 6 Apr 2000 11:57:05 -0400 Received: from netrdighe (NET-RDIGHE [141.251.80.76]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HR1A0V5S; Thu, 6 Apr 2000 11:57:05 -0400 Message-Id: <008e01bf9fe1$30dd7120$4c50fb8d@corpnorth.baynetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rajiv Dighe" To: Daljit Singh , POLICY References: <006f01bf9dc7$bf176f20$ac2db3cd@deterministicnetworks.com> <00c701bf9dd3$20d2a800$04000005@flfrd1.on.wave.home.com> <001201bf9df0$2a477060$34c6efd1@InReach.com> Subject: Re: COPS Implementation And Compatibility Date: Thu, 6 Apr 2000 12:00:12 -0400 Organization: Nortel Networks 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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Rajiv Dighe" Content-Transfer-Encoding: 7bit Daljit, I apologize for delay in providing you with the press release regarding interop testing. Here is the URL for the press release. it is possible that mailer may wrap this around & you will have to paste complete URL in your browser. http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/04-03 -2000/0001180065&EDATE= Regards, --Rajiv ----- Original Message ----- From: "Daljit Singh" To: "Dighe, Rajiv (R.) [EXCHANGE:CANOI:IO47]" ; "POLICY" Sent: Tuesday, April 04, 2000 12:42 AM Subject: Re: COPS Implementation And Compatibility > Rajiv, > > Can you provide a list of all the vendors involved in this > interoperability testing? > Do we have the results of these tests available? > > Thanks. > > Daljit > > -------------------------------------------------------------------------- -- > ------------ > Daljit Singh > Deterministic Networks, Inc. > Tel: 831-421-0388 x21 > -------------------------------------------------------------------------- -- > ------- > > > Daljit, > > > > It's in the interest of all the vendors to make sure that server & > > client implementations from them interoperate with implementations from > > others. Infact few days ago we even had an interoperability testing for > > COPS-PR server & client implementations. It is planned that such > > interoperability event will be repeated at regular intervals to ensure > that > > all clients & servers talk to each other nicely. Hope that answers your > > question. > > > > Regards, > > > > --Rajiv > > --------------------- > > Nortel Networks > > NetID group > > 613-798-4914 > > --------------------- > > > > ----- Original Message ----- > > From: "Daljit Singh" > > To: "POLICY" > > Sent: Monday, April 03, 2000 7:52 PM > > Subject: COPS Implementation And Compatibility > > > > > > Hi, > > > > Last week, in response to Mr. Dhiman's inquiry about COPS > > Implementation, many > > companies, including HP, Cisco, Intel and IPHighway responded with their > > implementation. > > Many provides SDK to write policy clients for their servers. I presume, > > policy client using > > SDK from one company should work with the servers from the others. Can > > someone confirm > > the compatibility between policy clients and servers from different > > companies? > > > > Daljit > > ------------------------------------------------------------------------ > > ----------------------- > > Daljit Singh > > email: daljit@DeterministicNetworks.com > > > > Tel: (831) 421-0388 X21 > > Fax: (831) 421-0394 > > ------------------------------------------------------------------------ > > ------------------------ > > > > > > > From majordomo@raleigh.ibm.com Thu Apr 6 22:12:43 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19223 for ; Thu, 6 Apr 2000 22:12:42 -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 WAA30062; Thu, 6 Apr 2000 22:05:46 -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 WAA29780; Thu, 6 Apr 2000 22:05:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26336; Thu, 6 Apr 2000 21:35:17 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27516; Thu, 6 Apr 2000 21:35:07 -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 VAA30818 for ; Thu, 6 Apr 2000 21:35:06 -0400 Received: from aiex09.ainet.oki.co.jp (aiex09.ainet.oki.co.jp [202.226.91.68]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA30456 for ; Thu, 6 Apr 2000 21:35:02 -0400 Received: from mmdhcp11 (mmdhcp11.mtc.telcom.oki.co.jp [172.18.128.97]) by aiex09.ainet.oki.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FZNJKK32; Fri, 7 Apr 2000 10:35:25 +0900 Message-Id: <01cf01bfa032$6f95f210$618012ac@mtc.telcom.oki.co.jp> From: "Kei Kato" To: "Yoram Ramberg" , "Dhiman Barman" , References: <4.3.1.2.20000327011540.00aecc30@209.3.6.76><4.3.1.2.20000327011540.00aecc30@209.3.6.76> <4.2.0.58.20000327174309.00bb65e0@csi-admin1.cisco.com> Subject: Re: COPS Implementation Date: Fri, 7 Apr 2000 10:41:46 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Kei Kato" Content-Transfer-Encoding: 7bit to what extent does the QPM comply with PIB draft? ( draft-ietf-diffserv-pib-00.txt and draft-ietf-rap-frameworkpib-00.txt) > Cisco is about to ship an early release of its COPS-QPM 1.0, a COPS based > QoS policy manager. You can probably find some info on the Cisco WEB site > (or at least find an address to send questions). I don't think this is the > only offering out there, but I hear it is the one closest to being a real > commercial product. Note that only a small set of devices now supports > COPS. It is expected to proliferate in the coming months and years. > > *Yoram > > At 03:11 PM 3/27/00 +0530, Dhiman Barman wrote: > >Hi, > > May I know if any one has looked into COPS implementation in practice. > >Any pointers will be of great help ? Thanks. > > > >-- > >Cheers > >Dhiman > > > >Man who sleep in cathouse by day, sleep in doghouse by night. From majordomo@raleigh.ibm.com Thu Apr 6 22:43:45 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20398 for ; Thu, 6 Apr 2000 22:43: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 WAA21944; Thu, 6 Apr 2000 22:36: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 WAB33250; Thu, 6 Apr 2000 22:36:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46672; Thu, 6 Apr 2000 22:11:04 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53112; Thu, 6 Apr 2000 22:10:40 -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 WAA26108 for ; Thu, 6 Apr 2000 22:10:38 -0400 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA24816 for ; Thu, 6 Apr 2000 22:10:34 -0400 Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA06008 for ; Thu, 6 Apr 2000 19:07:15 -0700 (PDT) Received: from netscape.com ([208.12.63.30]) by dredd.mcom.com (Netscape Messaging Server 4.1) with ESMTP id FSMJCS00.E1E for ; Thu, 6 Apr 2000 19:10:04 -0700 Message-Id: <38ED42F9.9B9C8ABD@netscape.com> Date: Thu, 06 Apr 2000 19:07:53 -0700 From: prasanta@netscape.com (Prasanta Behera) Organization: Netscape X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: policy@raleigh.ibm.com Subject: unsuscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: prasanta@netscape.com (Prasanta Behera) Content-Transfer-Encoding: 7bit unsuscribe From majordomo@raleigh.ibm.com Fri Apr 7 00:37:26 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21800 for ; Fri, 7 Apr 2000 00:37:25 -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 AAA24640; Fri, 7 Apr 2000 00:31:42 -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 AAA26226; Fri, 7 Apr 2000 00:31:43 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53880; Fri, 7 Apr 2000 00:08:09 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26992; Fri, 7 Apr 2000 00:08:02 -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 AAA25788 for ; Fri, 7 Apr 2000 00:08:03 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id AAA19966 for ; Fri, 7 Apr 2000 00:07:59 -0400 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Apr 7 00:06:54 EDT 2000 Received: from dnrc.bell-labs.com ([202.246.11.135]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA11766; Fri, 7 Apr 2000 00:06:48 -0400 (EDT) Message-Id: <38ED5E5B.E661F6A7@dnrc.bell-labs.com> Date: Fri, 07 Apr 2000 13:04:43 +0900 From: Kiyoshi Kodama X-Mailer: Mozilla 4.7 [ja] (WinNT; I) X-Accept-Language: ja Mime-Version: 1.0 To: policy@raleigh.ibm.com Subject: unsuscribe References: <38ED42F9.9B9C8ABD@netscape.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Kiyoshi Kodama Content-Transfer-Encoding: 7bit unsuscribe kkodama@dnrc.bell-labs.com From majordomo@raleigh.ibm.com Fri Apr 7 09:41:14 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08059 for ; Fri, 7 Apr 2000 09:41:13 -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 JAA21800; Fri, 7 Apr 2000 09:35: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 JAA30990; Fri, 7 Apr 2000 09:35:07 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52326; Fri, 7 Apr 2000 09:10:11 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54900; Fri, 7 Apr 2000 08:45:48 -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 IAA23328 for ; Fri, 7 Apr 2000 08:45:52 -0400 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA23738 for ; Fri, 7 Apr 2000 08:45:47 -0400 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprich.nortel.com; Fri, 7 Apr 2000 07:45:21 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2K7TY0HT>; Fri, 7 Apr 2000 08:44:20 -0400 Message-Id: <13E2EF604DE5D111B2E50000F80824E8035B6654@zwdld001.ca.nortel.com> From: "Hamid Syed" To: policy@raleigh.ibm.com Subject: RE: unsuscribe Date: Fri, 7 Apr 2000 08:44:16 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA08E.FE8FE3CA" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Hamid Syed" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA08E.FE8FE3CA Content-Type: text/plain unsubscribe Hamid Mahmood Syed Software Engineer Ph: (613) 763-6553 Advanced Wireless Technology Lab Fax:(613) 763-2686 Nortel Networks Email:hmsyed@nortelnetworks.com *** The contents of this email are Nortel Networks confidential*** > -----Original Message----- > From: prasanta@netscape.com [SMTP:prasanta@netscape.com] > Sent: Thursday, April 06, 2000 10:08 PM > To: policy@raleigh.ibm.com > Subject: unsuscribe > > unsuscribe > ------_=_NextPart_001_01BFA08E.FE8FE3CA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: unsuscribe

unsubscribe

Hamid Mahmood = Syed      =         =        =20
Software = Engineer       =         =         =         =         Ph: (613) 763-6553
Advanced = Wireless Technology Lab        =         =         =         Fax:(613) 763-2686
Nortel Networks =         =         =         =         =         Email:hmsyed@nortelnetworks.com

          &n= bsp;        *** The contents of = this email are Nortel Networks confidential***

    -----Original Message-----
    From:   prasanta@netscape.com = [SMTP:prasanta@netscape.com]
    Sent:   Thursday, April 06, 2000 10:08 PM
    To:     policy@raleigh.ibm.com
    Subject:       = unsuscribe

    unsuscribe

------_=_NextPart_001_01BFA08E.FE8FE3CA-- From majordomo@raleigh.ibm.com Fri Apr 7 10:12:52 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08576 for ; Fri, 7 Apr 2000 10:12:51 -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 KAA32672; Fri, 7 Apr 2000 10:03:42 -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 KAA29374; Fri, 7 Apr 2000 10:03:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39116; Fri, 7 Apr 2000 09:35:02 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54906; Fri, 7 Apr 2000 08:45:52 -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 IAA32052 for ; Fri, 7 Apr 2000 08:45:55 -0400 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA24770 for ; Fri, 7 Apr 2000 08:45:51 -0400 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprich.nortel.com; Fri, 7 Apr 2000 07:45:56 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2K7TY02Q>; Fri, 7 Apr 2000 08:44:55 -0400 Message-Id: <13E2EF604DE5D111B2E50000F80824E8035B6655@zwdld001.ca.nortel.com> From: "Hamid Syed" To: policy@raleigh.ibm.com Subject: RE: unsuscribe Date: Fri, 7 Apr 2000 08:44:50 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA08F.125321CE" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Hamid Syed" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFA08F.125321CE Content-Type: text/plain unsuscribe Hamid Mahmood Syed Software Engineer Ph: (613) 763-6553 Advanced Wireless Technology Lab Fax:(613) 763-2686 Nortel Networks Email:hmsyed@nortelnetworks.com *** The contents of this email are Nortel Networks confidential*** > -----Original Message----- > From: prasanta@netscape.com [SMTP:prasanta@netscape.com] > Sent: Thursday, April 06, 2000 10:08 PM > To: policy@raleigh.ibm.com > Subject: unsuscribe > > unsuscribe > ------_=_NextPart_001_01BFA08F.125321CE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: unsuscribe

unsuscribe

Hamid Mahmood = Syed      =         =        =20
Software = Engineer       =         =         =         =         Ph: (613) 763-6553
Advanced = Wireless Technology Lab        =         =         =         Fax:(613) 763-2686
Nortel Networks =         =         =         =         =         Email:hmsyed@nortelnetworks.com

          &n= bsp;        *** The contents of = this email are Nortel Networks confidential***

    -----Original Message-----
    From:   prasanta@netscape.com = [SMTP:prasanta@netscape.com]
    Sent:   Thursday, April 06, 2000 10:08 PM
    To:     policy@raleigh.ibm.com
    Subject:       = unsuscribe

    unsuscribe

------_=_NextPart_001_01BFA08F.125321CE-- From majordomo@raleigh.ibm.com Fri Apr 7 16:12:28 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17269 for ; Fri, 7 Apr 2000 16:12:27 -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 QAA28564; Fri, 7 Apr 2000 16:05:40 -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 QAA29352; Fri, 7 Apr 2000 16:05:37 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56598; Fri, 7 Apr 2000 15:38:19 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56588; Fri, 7 Apr 2000 15:38:15 -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 PAA28828 for ; Fri, 7 Apr 2000 15:38:20 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA21962 for ; Fri, 7 Apr 2000 15:38:19 -0400 Received: from cisco.com ([144.254.95.26]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id VAA22804; Fri, 7 Apr 2000 21:37:16 +0200 (IST) Message-Id: <38EE2A9A.34635B83@cisco.com> Date: Fri, 07 Apr 2000 21:36:11 +0300 From: Yoram Ramberg Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: Kei Kato Cc: Dhiman Barman , policy@raleigh.ibm.com Subject: Re: COPS Implementation References: <4.3.1.2.20000327011540.00aecc30@209.3.6.76><4.3.1.2.20000327011540.00aecc30@209.3.6.76> <4.2.0.58.20000327174309.00bb65e0@csi-admin1.cisco.com> <01cf01bfa032$6f95f210$618012ac@mtc.telcom.oki.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg Content-Transfer-Encoding: 7bit Note: I'm not authorized to give official Cisco product information. Please refer to the Cisco WEB site (www.cisco.com) where you can either find answers or contacts for answers. The following response is based on personal knowledge and does not commit Cisco. The IETF PIB is still at a draft state. QPM supports Cisco's devices that implement Cisco's PIB which is similar but not identical to the IETF PIB. It should be expected that once the IETF PIB becomes a standard Cisco's devices will support it and QPM will too. However, to the best of my understanding Cisco has not yet committed to such support. *Yoram Kei Kato wrote: > to what extent does the QPM comply with PIB draft? > ( draft-ietf-diffserv-pib-00.txt and draft-ietf-rap-frameworkpib-00.txt) > > > Cisco is about to ship an early release of its COPS-QPM 1.0, a COPS based > > QoS policy manager. You can probably find some info on the Cisco WEB site > > (or at least find an address to send questions). I don't think this is the > > only offering out there, but I hear it is the one closest to being a real > > commercial product. Note that only a small set of devices now supports > > COPS. It is expected to proliferate in the coming months and years. > > > > *Yoram > > > > At 03:11 PM 3/27/00 +0530, Dhiman Barman wrote: > > >Hi, > > > May I know if any one has looked into COPS implementation in > practice. > > >Any pointers will be of great help ? Thanks. > > > > > >-- > > >Cheers > > >Dhiman > > > > > >Man who sleep in cathouse by day, sleep in doghouse by night. From majordomo@raleigh.ibm.com Fri Apr 7 19:55:57 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21283 for ; Fri, 7 Apr 2000 19:55:57 -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 TAA24062; Fri, 7 Apr 2000 19:47:51 -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 TAA26348; Fri, 7 Apr 2000 19:47:51 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55892; Fri, 7 Apr 2000 19:22:41 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42820; Fri, 7 Apr 2000 19:22:37 -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 TAA28066 for ; Fri, 7 Apr 2000 19:22:44 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA11890 for ; Fri, 7 Apr 2000 19:22:42 -0400 Received: from jstrassnlap ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA12962; Fri, 7 Apr 2000 16:21:35 -0700 (PDT) Message-Id: <008701bfa0e8$251f7a60$826c45ab@cisco.com> From: "John Strassner" To: "Yoram Ramberg" , "Kei Kato" Cc: "Dhiman Barman" , References: <4.3.1.2.20000327011540.00aecc30@209.3.6.76><4.3.1.2.20000327011540.00aecc30@209.3.6.76> <4.2.0.58.20000327174309.00bb65e0@csi-admin1.cisco.com> <01cf01bfa032$6f95f210$618012ac@mtc.telcom.oki.co.jp> <38EE2A9A.34635B83@cisco.com> Subject: Re: COPS Implementation Date: Fri, 7 Apr 2000 16:22:29 -0700 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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit Hi everyone, this is your friendly working group co-chair. Could we please keep product-related questions off of this list? Thanks in advance for your cooperation. regards, John ----- Original Message ----- From: "Yoram Ramberg" To: "Kei Kato" Cc: "Dhiman Barman" ; Sent: Friday, April 07, 2000 11:36 AM Subject: Re: COPS Implementation > Note: I'm not authorized to give official Cisco product information. Please > refer to the Cisco WEB site (www.cisco.com) where you can either find answers or > contacts for answers. The following response is based on personal knowledge and > does not commit Cisco. > > The IETF PIB is still at a draft state. QPM supports Cisco's devices that > implement Cisco's PIB which is similar but not identical to the IETF PIB. It > should be expected that once the IETF PIB becomes a standard Cisco's devices > will support it and QPM will too. However, to the best of my understanding > Cisco has not yet committed to such support. > > *Yoram > > Kei Kato wrote: > > > to what extent does the QPM comply with PIB draft? > > ( draft-ietf-diffserv-pib-00.txt and draft-ietf-rap-frameworkpib-00.txt) > > > > > Cisco is about to ship an early release of its COPS-QPM 1.0, a COPS based > > > QoS policy manager. You can probably find some info on the Cisco WEB site > > > (or at least find an address to send questions). I don't think this is the > > > only offering out there, but I hear it is the one closest to being a real > > > commercial product. Note that only a small set of devices now supports > > > COPS. It is expected to proliferate in the coming months and years. > > > > > > *Yoram > > > > > > At 03:11 PM 3/27/00 +0530, Dhiman Barman wrote: > > > >Hi, > > > > May I know if any one has looked into COPS implementation in > > practice. > > > >Any pointers will be of great help ? Thanks. > > > > > > > >-- > > > >Cheers > > > >Dhiman > > > > > > > >Man who sleep in cathouse by day, sleep in doghouse by night. > > > From majordomo@raleigh.ibm.com Mon Apr 10 06:20:54 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04343 for ; Mon, 10 Apr 2000 06:20:53 -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 GAA21674; Mon, 10 Apr 2000 06:17:34 -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 GAA06488; Mon, 10 Apr 2000 06:17:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31856; Mon, 10 Apr 2000 05:44:50 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32872; Mon, 10 Apr 2000 05:44:46 -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 FAA06536 for ; Mon, 10 Apr 2000 05:44:46 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA28190 for ; Mon, 10 Apr 2000 05:44:44 -0400 Received: from jstrassnlap (sj-dial-4-22.cisco.com [171.68.181.151]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id CAA28701; Mon, 10 Apr 2000 02:43:56 -0700 (PDT) Message-Id: <018f01bfa2d1$6d4842a0$97b544ab@cisco.com> From: "John Strassner" To: Cc: , "Ed Ellesson" , "Randy Bush" , "Wijnen, Bert \(Bert\)" Subject: Draft Policy Framework WG minutes Date: Mon, 10 Apr 2000 02:21:55 -0700 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0089_01BFA293.8A9E0FD0" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" This is a multi-part message in MIME format. ------=_NextPart_000_0089_01BFA293.8A9E0FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Policy Enthusiasts, please review the attached minutes, and send all comments and corrections to me asap (COB next Thursday, 13 April). This will ensure that these minutes and proceedings are included in the official proceedings. Thanks and kind regards, John Strassner ------=_NextPart_000_0089_01BFA293.8A9E0FD0 Content-Type: text/plain; name="IETF-47-Notes.txt" Content-Disposition: attachment; filename="IETF-47-Notes.txt" Content-Transfer-Encoding: quoted-printable Day One, Policy Framework WG Minutes recorded by John Strassner The agenda was discussed. No changes were made. For your=20 reference, the agenda was: 1st Session, 1300-1500 Mon, 27 March =20 Agenda Bashing - Ed (5) Status Update - Ed/John (15) PCIM - WG Last Call Results - Bob (15) PCIM - Final Draft Review - Bob (25) file: draft-ietf-policy-core-info-model-04.txt PCS (Policy Core Schema) Review - Bob (10) file: draft-ietf-policy-core-schema-06.txt Polterm Requirements Doc - Fran (15) file: draft-reichmeyer-polterm-terminology-00.txt Policy Framework Status - Mark (15) file: draft-ietf-policy-framework-00.txt Policy Monitoring - Bob/Ken (15) (postponed to Wed.) no draft, just general thoughts; draft is pending Wrapup - Ed (5) 2nd Session, 1300-1500 Wed, 29 March =20 Policy Monitoring - Bob/Ken (10) (resched) no draft, just thoughts QoS Policy Extensions - John to give an intro (5) QoS Policy Info Model (new draft) - John (22) file: draft-ietf-policy-qos-info-model-00.txt QoS Policy Schema (revision) - John (20) file: draft-ietf-policy-qos-schema-00.txt QoS PHB Specifications - John (5) file: draft-ietf-policy-qos-schema-00.txt QoS Device Info Model Update - Walter (22) file: draft-ietf-policy-qos-device-info-model-00.txt (will be available by 3/20/00, note name change) Requirements and Use Case - Hugh (23) file: draft-ietf-policy-req-02.txt Policy Scalability - Hugh (08) file: draft-owens-policy-scalability-00.txt Wrapup - Ed (5) (Note: due to a long discussion about whether and when a=20 second working group last call should start, the Policy=20 Monitoring draft was moved to the second session and the=20 draft discussion in that session were compressed to=20 accommodate the change) Status - John Strassner John gave a brief overview of the overall status. The bad news=20 is that we=92re behind our charter goals. The good news is that=20 we=92ve had a lot of activity this last round. Every draft listed=20 above in the agenda is either a new draft or an update to an=20 existing draft. The exceptions are the framework draft, which=20 has been waiting for consensus to build in other affected=20 working groups, and the core schema, which is waiting until=20 the core information model gets out of working group last call. Q: Are we doing another call for the core information model? A: This ended up being a somewhat lengthy discussion.=20 Here=92s a summary. There are two outstanding issues in the core model. The first is=20 representation of time, which Bob will talk about shortly. We=20 have an answer, so this will be resolved. The second was=20 clarification for roles, which we added. All other last call=20 comments have been addressed in the document. Now, we want to strike a balance between doing the right=20 thing (having another formal working group last call) and=20 trying to get the document issues as soon as possible. The=20 argument against having another working group last call is it=20 will cause at least another week and a half delay (repository=20 doesn=92t open till April 7) and there really isn=92t anything more=20 to discuss. ;-) Argument for another working group last call is=20 that is how the procedure should take place, and since this is=20 for Proposed Standard, we shouldn=92t take any short cuts. After=20 further discussion, we decided to go the formal route and have=20 a last call start as soon as the draft was placed in the=20 repository. Q: And when is last call for core schema? A: The core schema will go to last call when the IETF Last=20 call completes of the core information model. Q: Can=92t we move this up a bit? A: Bert agreed. It was decided that we update and send into=20 last call another revision of the core schema, approximately 2=20 weeks (sooner if possible) after the core information model=20 completes its second last call. This would make it available=20 roughly in mid-May. Core Info Model - Bob Moore File: draft-ietf-policy-core-info-model-04.txt Several editorial comments were raised, and addressed in the 04 version of this draft. One issue was raised, and resolution=20 will be discussed below. This is the time issue, and will cause=20 the version of the Policy Core Information Model (PCIM) to=20 be revised to 05, and will be the main focus of attention for=20 the second WG last call. The main issues talked about during the change from 03 to=20 04 in the first working group last call were: - declarative vs. procedural model (wording clarified) - discussion of roles (wording clarified) - new PolicyRoles property added to policyRule - UCS-2 encoding for CIM strings explained more fully - Changed encodings of PolicyTimePeriodCondition mask=20 properties from strings to octet strings - Clarified encoding of OIDs for ConstraintEncoding and=20 ActionEncoding properties - Expanded the names for several of the association=20 classes and their reference properties - Updated Security Section - Updated Acknowledgments and References sections,=20 along with minor editorial fixes We then had a discussion about roles in the meeting. There=20 was concern voiced that the roles definition was still not as=20 clear as it could be. For example, what happens, specifically,=20 when it is desired to retrieve all policies that are defined for=20 the role-combination BGP+RIP? It is assumed that this will=20 cause all policies for BGP, all policies for RIP, and all policies=20 that deal with both BGP and RIP to be downloaded to the=20 PDP. However, this is not explicitly spelled out. There was a=20 request for additional clarification to state explicitly that all of=20 these policies get downloaded to the PDP. It is then up to the=20 PDP to either filter only the BGP+RIP policies and send those=20 policies to the PEP, or to ship additional policies to the PDP=20 and have the PDP decide what to act on. This text will be=20 added as part of the 05 draft. This action item is assigned to=20 John. Time issue. The basic issue was that the semantics and syntax=20 for the time-range properties in the policyTimePeriodCondition class should match those specified in RFC 2445 (iCalendar document). This RFC already has a convention for representing time intervals, and the suggestion was that we use that convention instead of our own. Proposed resolution: - when both ends of the time period are specified, use the=20 convention in RFC 2445 - when there is an open ended time period (from some=20 time before till or from now till forever), RFC 2445 doesn=92t have this capability. So we=92ll solve=20 this by glueing together the specification of each end according to RFC 2445. - For timeOfDayMask property, change the representation=20 to conform to RFC2445 by starting the time with a T and=20 replacing our delimiter (a colon) with the RFC 2445=20 delimiter (a slash). As an example, we could have:=20 Thhmmss/Thhmmss. So far, so good. However, once we started talking to the=20 iCalendar people, we realized that there was yet another=20 problem with the representation of time zones. This affects the=20 ApplicableTimeZone property . We use a static offset from=20 UTC time, as does almost everyone else. But this is wrong,=20 because for example, countries that have daylight time change=20 their offsets twice a year. We observe that we are just as good=20 (or bad) as SNMP, LDAP, and many other protocols in this=20 area, and therefore we should change when the other protocols=20 change. Bert and Marcus Leech are investigating and will get=20 back to us.=20 The action item for updating the first two items with respect to=20 time definition is assigned to Bob. Next steps. We need another two-week last call. After some=20 discussion, we decided that we will wait to have a working=20 group last call start Monday 10 April, since that is the first=20 date that people may be able to get the document from the=20 repository. John or Ed will ensure that the document is=20 updated and posted to the repository as soon as it opens up (7=20 April). =20 Core LDAP Schema - Bob Moore File: draft-ietf-policy-core-schema-06.txt We need to incorporate recent work done in the DMTF plus=20 work that Ryan Moats has done in mapping information=20 models to the LDAP schema. Then, we will be ready to issue=20 another revision of this document. Q: what about definitions such as port and protocol? These=20 objects have added semantics that should be captured in the=20 Core information model and schema, instead of remaining in=20 the QoS models. A: There are some problems associated with this, such as=20 coordinating this work with other working groups that want to=20 use these. Q: But there are a number of IETF-specific constants (for=20 example, protocol and port) that are IP-specific. A: But moving this to the Core information model and schema=20 means that other working groups, such as IPSP, must use it.=20 Furthermore, it means that working groups that don=92t need a=20 concept of port or protocol would be saddled with it. A: IPSP wanted to differentiate between distribution and=20 configuration of policies. So the current IPSP draft isn=92t really=20 tied into the Policy model; rather, it is trying to model lower- level information that can be controlled by higher-level policy=20 (similar to the division in the QoS models in Policy). Bert thinks that if it is indeed general, then we should consider=20 moving this information into the Core Info Model and=20 Schema. This then raised a discussion as to (1) its feasibility=20 and (2) its practicality. Feasibility is the actual mechanics of=20 moving the information; practicality is when, and how that=20 will affect the schedule. One additional possibility is to have a third document - information model proposed common concepts (and of course,=20 a companion LDAP mapping document). This is the subject=20 for further discussion on the list. The chairs recommend that=20 we wait until the Policy QoS and Device QoS models are re- published, along with the IPSP model, to see if these are=20 indeed general concepts. Action Item: Bob Moore to coordinate the updating of the=20 Policy Core Schema draft. This should wait until the working=20 group last call of the PCIM has finished, just to make sure that=20 nothing changes. The goal will be to issue a new revision as=20 close to two weeks from a successful working group last call=20 close of the PCIM. Policy Terminology - Francis Reichmeyer File: draft-reichmeyer-polterm-terminology-00.txt Approach. Several working groups are working on policy=20 networking terminology. The list includes (at least) RAP,=20 Policy, DiffServ, and IPSP. Others are being added (e.g.,=20 MPLS). The result is a lot of policy terms and definitions, with=20 some conflicts occurring. The focus of this document is to=20 resolve those conflicts and to put these terms in one place. Goal: identify relevant common terms that all working groups=20 can use. Non-goal: common policy architecture Q: Does this draft introduce new terms? A: No Approaches to Policy. This section talks about Policy,=20 management and administration of policy, the notion of policy=20 domains, and meta-policy. These latter two were new to some=20 people. A policy domain is a collection of objects that have=20 been explicitly grouped together so that they can share the=20 same policies. There is an implied common administration that=20 happens. Domains can be nested, in order to reflect=20 hierarchical semantics. A meta-policy is a policy that defines=20 how policies are constructed. Another way of thinking about=20 this is that it defines how to build other policies. Policy Management Models. Three are defined: outsourcing,=20 provisioning, and interactive (though there is a question as to=20 whether this one is needed or not). An outsourced policy=20 model directs certain components of the policy framework to=20 rely upon other components of that same framework in order=20 to perform policy-related decisions. A provisioned policy=20 model implements policy by first configuring devices that will=20 execute policy decisions prior to the events that will prompt=20 those decisions. No real-time interaction is done here - this=20 model consists of configuring a device so that it will do the=20 right thing sometime later. An interactive policy model=20 implements policy by installing policy expressions within=20 appropriate components of the policy framework. This means=20 that policies are complete, self-contained expressions, and that=20 there are a set of rules that define the interaction between a=20 process that requires policy decisions to be made and the=20 constituent components of the policy framework that enforce=20 those decisions through executing a set of actions. Q: Are these three terms reflective of work being done in an=20 architecture, or is it something that was invented as part of this=20 work? If it was invented, then we should not use it. (In other=20 words, the purpose of this draft is to document terms, not=20 invent new ones). A: Good feedback, the authors will discuss this again. A: The purpose of this document is to be a "living" document=20 that grows as the working groups that are using it gain more=20 experience and form tighter definitions of policy. Q: Outsourcing and provisioning reflect a COPS legacy,=20 where interactive reflects a policy legacy. Policy is all about a=20 condition-action pair, and controlling the interaction between=20 a PDP and a PEP. A: Provisioning is pure configuration. Outsourcing is asking=20 for help. Interactive is describing capabilities. The chairs appealed for volunteers to write up and comment=20 on text. Shai to argue against interactive, and Walter to argue=20 for interactive. Everyone else is free to join in the discussion.=20 ;-) Abstraction and Scoping. Four key concepts are defined in this=20 section: Administrator-defined, device-independent, device- dependent, and roles. Roles are used to help define scoping. Q: what about network-wide policies? A: not explicitly identified as such, but this term should be=20 added to the next revision of the document. Q: Also, don=92t like "administrator-defined". This should=20 instead be bound to a specific scope, such as administrator for=20 a network, etc. A: Authors to discuss and either incorporate or add additional=20 clarifying text. Q: Are there multiple definitions of roles? In other words, is=20 this definition synchronized with the definition in the PCIM? A: The intent is most assuredly to NOT have multiple=20 definitions. Unfortunately, the definitions are not currently=20 synchronized with the PCIM, but they will be in the next=20 revision. Q: Concern that by defining the functions of a policy system,=20 there is a strong chance of these terms conflicting with other=20 documents. A: Good point. So if this document is a "passive" document=20 (i.e., no new terms are defined), then if there needs to be a new=20 term, the authors of this document should contact the=20 appropriate architecture or framework document and get them=20 updated. This last question led to a general discussion of which=20 working group should own this document. It was offered that=20 Policy owns this, and RAP agreed. Need to check with IPSP=20 and DiffServ. (Editor=92s note: subsequently, IPSP and DiffServ=20 responded, saying it was OK. Thus, this document needs to be=20 added to the Policy Framework working group charter. Action=20 item: John/Ed to do this). Framework document - Mark Stevens File: draft-ietf-policy-framework-00.txt Document hasn=92t received much attention, due to other=20 pressing matters that this draft depends on. The authors are=20 going to be revising this and hope to get a new revision out in=20 April (May at the latest). Feedback is encouraged. Wrapup of First Day (Ed). 1. New version of PCIM (-05) will be completed by the end=20 of this week (pending discussion of moving constants=20 from QoS model to PCIM 2. Time period changes will also be incorporated by next=20 week. 3. John to update roles section by next week. 4. Bert to check with Marcus on time zone handling. 5. Monitoring to be moved onto Wednesday session. 6. Which working group should own policy terminology?=20 Tentatively Policy, but need to check with IPSP and=20 DiffServ, and also need to ensure that it is a working=20 document that incorporates needs of the other working=20 group 7. Shai and Walter to suggest text describing use of=20 interactive. Policy, Day Two Policy Monitoring - Bob Moore (No draft yet) Why monitoring (i.e., what are the requirements that we are=20 trying to address)? Administrators need to know which policies (active and=20 inactive) are present at a PDP, and whether these policies are=20 meeting their objectives and being properly enforced. There=20 needs to be a "core" policy MIB to tie all of the individual=20 policy-related MIBs together. It is proposed that a new draft be written that addresses these=20 issues. Note that the scope is monitoring only -- we have other=20 mechanisms for configuring policies. The next question is what to monitor. There are two broad=20 categories of items that need monitoring - the policy=20 framework itself, and whether polices are acting correctly and=20 being enforced or not. This is more complicated that it initially=20 appears to be. There can be several protocols (e.g., a policy=20 repository protocol, like LDAP, as well as policy protocols=20 themselves (e.g., COPS and SNMP). In addition, there are=20 issues with respect to instrumenting different domains (e.g.,=20 QoS and IPSec will have different needs). There are a set of nine possible instrumentation points=20 envisioned. These divide into the ingress, inside and egress of=20 the Policy repository and PDP (6), the ingress and inside of=20 the PEP (2), and the policy-managed resource itself (1). All=20 except this latter one use the policy framework. More=20 specifically, they are: 1 - PM tool to repository 2 - inside the repository 3 - repository to PDP 4 - PDP to repository 5 - Instrumented inside the PDP 6 - PDP looking at PEP 7 - implemented at a policy-aware PEP, policy flows from the PEP to the PDP 8 - the MIB that instruments the function that is policy-controlled 9 - the PEP itself There are a set of MIBs that exist. The question is, how do we=20 proceed to harmonize/rationalize these MIBS and relate them=20 to the Policy Framework working group? This draft will help=20 define this relationship. Policy QoS Information Model - John Strassner File: draft-ietf-policy-qos-info-model-00.txt This draft was built by abstracting the concepts in the QoS=20 Policy schema. It is acknowledged that not all of the=20 "LDAPisms" have been successfully purged from this=20 document, and that it should be further generalized. This will=20 happen in the next revision. The purpose of this draft is to extend the generic concepts of=20 policies to a form that is more suitable for representing=20 policies that control DiffServ and IntServ. It fits as the middle=20 layer of policies, refining on generic concepts (for=20 interoperability) and using specific mechanisms as defined in=20 the QoS Device Information Model (to be discussed later). For=20 example, it defines the concept of a policer. This is not a=20 generic extension (e.g., DHCP doesn=92t require one); it is a=20 concept that is needed by DiffServ and IntServ. Status This draft is actually the third major revision - it is a 00 draft=20 because it has just moved from the individual namespace to=20 the working group namespace. The following changes were=20 made during this revision: - Added a lot of detail to QoS actions (both DiffServ and=20 IntServ) - Added functionality, yet simplified, repository usage - Added granularity to representing constants and=20 variables - Added changes to match the latest version of the PCIM - Added examples - Minor editorial changes as suggested per working group=20 comments There were also some extensions to the PCIM. The most=20 important of these were to extend the decision process to=20 allow rule nesting and rule-group interaction, and to support=20 the concept of nested rules and sub-rules. Objectives of this draft. The specific goals of this draft is to extend the generic notion=20 of policy, as expressed in the PCIM, to better represent the=20 needs of DiffServ and IntServ. This takes several forms: - to refine the concepts of repositories, conditions and=20 actions for expressing QoS policy rules - to ensure that a simple way is available to build=20 hierarchical namespaces for administration and scoping=20 of policy rules - to build a framework of classes that help ensure that=20 devices of different capabilities interpret QoS=20 mechanisms the same way - to provide for rule-specific as well as reusable policy=20 rules, conditions and actions; and to be able to define at a=20 high-, a device-independent, or a device-dependent level,=20 DiffServ and IntServ policies.=20 This draft can=92t do the last two bullets by itself. But it can be=20 one of the tools that, combined with other work, can=20 accomplish these together. Policy Layers. As stated previously, this draft is one of several that work=20 together to define a continuum of policies. A chart was=20 displayed that provided three different abstractions. The=20 highest was administrator-defined. This level is device-,=20 technology- (e.g., DiffServ) and mechanism- (e.g., WFQ)=20 independent. An example is: IF User is subscribed to Gold Service, THEN allow use of NetMeeting and=20 provide premium data services The next lower layer is characterized by device- and=20 mechanism-independent, but technology-specific, policy rules.=20 These policies translate the higher-level administratively- defined policy rules to a form that can be more easily=20 translated to a device. An example is: IF sourceIPAddress =3D=3D 172.3.128.0/15, THEN mark voice with EF and mark data with AF The third layer is characterized by a device-independent,=20 technology- and mechanism-dependent policy. This type of=20 policy is used to do the following three types of configuration: - configure a component so it can be used to condition=20 forwarded traffic - configure a component so that it can act on received=20 traffic directly - trigger an action based on a network or a system event=20 (e.g., link failure) These configuration actions take the form of performing a set=20 of device-independent actions (e.g., configure a classifier, then=20 configure a filter and bind it to the classifier, etc.). This draft=20 serves as the integration point for binding high-level QoS=20 policies to low-level QoS policies. The concept of reusable repositories was discussed. This is an=20 extension of the repository concept that is present in the=20 PCIM. Repositories in the QoS Policy model serve the=20 following three purposes: - containers for reusable objects - maintenance mechanism for ensuring the integrity and proper updating of reusable objects - provide a hierarchical namespace and context for reusable objects The repository implementation has been simplified. The=20 policyRepository class of the PCIM is used, and additional=20 semantics are provided by subclassing the policyGroup class.=20 Basically, the policyRepository class is used to define the root=20 of the policy repository. The qosPolicyDomain class is used to=20 define the roots of various administrative domains that reside=20 in the policy repository. Within each qosPolicyDomain, one or=20 more qosNamedPolicyContainers can be used to define=20 policies that are specific to a particular group of objects. Several examples were given. One illustrated the above=20 process, showing how policy rules could be grouped first by=20 container, then by domain. Another illustrated the more=20 granular decision-making process that the QoS Policy Schema=20 supports. Several examples were also provided of showing=20 how QoS policy rules could be constructed. QoS action extensions were then covered. DiffServ actions=20 include classification, and then the ability to mark, police,=20 and/or shape to a specified traffic profile. IntServ actions=20 included controlling RSVP, as well as signaling and install=20 actions. Note that it is expected that the QoS Device=20 Information Model will supply the specific parameters that are=20 controlled and manipulated by these actions. A good analogy=20 is that the QoS Device Information Model represents the=20 DiffServ and IntServ mechanisms of the device, while the=20 QoS Policy Information Model shows how to configure and=20 manage these mechanisms. There is one main open issue, which is whether to move the=20 variables and constants that are defined in this draft up to the=20 core information model or not. This will be taken to the list. John will revise this draft within 2-3 weeks. QoS Policy Schema - John Strassner File: draft-ietf-policy-qos-schema-00.txt This draft appears as a 00 draft because it has just moved=20 from the individual namespace to the working group=20 namespace. It has had 3 major iterations previously. It is acknowledged that another revision needs to be made.=20 First, in separating out concepts that were generic that were=20 used to build the QoS Policy Information Model, not all of the=20 generic concepts have been extracted. Second, it needs to be=20 revised to include a formal ABNF, and to synchronize again=20 against the core information model (simple) and schema (a=20 little bit more work). Status This draft has received a lot of previous attention. It was the=20 original source for the concept of policy repositories, and=20 contributed this and other concepts to the PCIM and Core=20 Schema documents. This revision has had the following=20 changes: - generalization and simplification of the containment=20 model - generalization and simplification of the implementation=20 of reusable object repositories - qosPolicyRule class removed, now using policyRule - QoS domains and policyGroups can be arbitrarily nested - Action classes for DiffServ and IntServ created - PHB modeling added as separate drafts - Variable binding definition and pre-defined constants=20 revised and made more granular Discussion. Containment is now based on association classes. This hides=20 the difference between attachment and reference. The reusable=20 objects were generalized so that they could reside in any=20 repository. The model was inverted, so that now multiple=20 domains can reside in a repository, with multiple containers in=20 each domain. This is a more flexible and efficient mapping. The qosPolicyRule class was removed. Instead, the policyRule=20 class defined in the core model was used, and semantics were=20 moved into the condition and action subclasses defined in this=20 draft. An example was provided that illustrates how a QoS Domain=20 could be instantiated. It stressed the use of DIT containment,=20 and the ability to treat policyRule and=20 qosNamedPolicyContainer objects as siblings. The policyRule=20 priority attribute, along with the qosPolicyRuleMatchMethod=20 attribute, were used to fine-tune the decision-making process=20 that is represented in the QoS domain. A similar example was=20 provided that illustrates the difference between using=20 attachment and reference to form a QoS policy rule. The open action items are to incorporate some additional=20 minor editorial comments, to finish the ABNF, and to decide=20 on where variables and constants belong. John will revise this=20 draft within 2-3 weeks. PHB Sets and Mapping - John Strassner Files: draft-ronc-domain-phb-set-specification-00.txt and draft-ronc-domain-phb-set-ldap-rep-00.txt We don=92t really have time to go into any real detail on these,=20 please read the drafts and comment. The purpose is to extend=20 the core and QoS policy information models and associated=20 schemata by representing a set of PHBs enforced on a QoS=20 domain. This manages the scheduling and resource allocation=20 that is shared between the set of PHBs that are enforced=20 together on a QoS domain. Device QoS Information Model - Walter Weiss File: draft-ietf-policy-qos-device-info-model-00.txt This is a 00 draft, but represents a major restructuring and=20 refinement of the previous draft. It focuses on creating data=20 structures for configuring and managing QoS mechanisms that=20 are "in" a device. The first slide talks about the same three levels of policy.=20 Again, there is a continuum of policies that start by being=20 defined administratively, then get translated to a device- and=20 mechanism-independent form, and then get translated again=20 into a device-independent but mechanism-dependent form. Mechanism-independent policies talk about ports and DSCP=20 values. Mechanism-dependent policies talk about classifiers,=20 markers, and other elements that affect the forwarding of=20 traffic in the data path of a router. There is an important implication here. One of the problems of=20 the mechanism-independent approach is that it can=92t guarantee=20 interoperability between different devices. That is, consider a=20 single policy server. If it controls two different devices that=20 each have different implementations of the same QoS=20 mechanism (e.g., a dropper or queue), then these devices will=20 interpret the policy differently UNLESS there is a common=20 device information model. Similarly, mechanism-independent policies do not guarantee=20 interoperability between policy servers. If you have multiple=20 policy servers from different vendors, then you have a=20 different set of problems: each policy server defines its own=20 mapping to control devices, but you have no assurance that the=20 policy servers are doing the same thing. How do we support the different types of mechanisms? Our=20 approach is to use a class hierarchy. This provides a set of=20 abstractions that each can model one or more concepts in=20 detail. This makes the model inherently simpler, more=20 accurate, and more extensible than building a single=20 monolithic model that describes everything. The higher=20 portion of the hierarchy talks about common information, and=20 as you move down the hierarchy, you refine these higher=20 concepts to model mechanism-specific or even device-specific=20 policies. An example from the model that describes droppers=20 was given, where a superclass represents information that is=20 both device-independent and generic. Its immediate subclasses=20 refine this to contain more specific information (RED vs. tail- drop characteristics). Note that this level is still device- independent. A further level can be defined, which subclasses=20 the RED and tail-dropper classes to bind a specific vendor=20 implementation to them.=20 Class Associations are used to specify relationships between=20 QoS mechanisms and services. These take several forms. One=20 example is the construction of a generic QoS service from=20 specific technologies, such as DiffServ or 802.1Q. Note that=20 these technologies are modeled as sub-services that work=20 together to implement a service. Another example is the=20 definition of a TCB (traffic conditioning block) service. This=20 service is made up of various sub-services, such as marking,=20 classifying, metering, etc. A third example, nextTCBElement,=20 is used to control the sequencing of various TCB sub-services. Note that associations are implementation-independent. They=20 can be mapped to a row pointer if using a MIB, or a DN if=20 using a directory. Another idea in the draft is to specify at run-time (or when the=20 policy needs to be processed or interpreted) the characteristics=20 of the device that are applicable, so that the best possible=20 mapping can be done. Sometimes, you run into capacity=20 problems (e.g., device can only support 50 filters) or specific=20 technologies (does this device support DSCP marking?) or=20 specific implementation (does this filter support bit masks and=20 ranges?). These are called capabilities. Capabilities enable us=20 to bind policy to device-specific characteristics. Examples=20 were given that show how capabilities and constraints can be=20 used to achieve a closer model of how the device is operating=20 in the real world. QoS Model. The QoS Model has two parts - description of QoS services,=20 and description of mechanisms in the device. QoSService is an=20 instance of (for example) Gold Service, and its associations=20 enable specific sub-services (e.g., classifiers and markers) to=20 be used to provide this service. Three examples of different types of services were provided.=20 A DiffServService binds DSCPs to TCBs in order to construct=20 the DiffServ service. An 802.1P service binds priority values=20 to TCBs in order to construct the service. Finally, Gold=20 Service can be conceptualized as an instance of QoSService=20 that could use services like the ones above to specify a=20 customized QoS definition. This definition consists in reality=20 of multiple services that are coordinated together (e.g., EF for=20 voice, and AF for data). Q: Don=92t see policies that govern admission control A: This is governed by the TCB components. Q: No, I mean explicit admission control (controlling=20 interaction of devices to limit the number of conversations that=20 can take place A: Nothing in the model precludes modeling this, but we need=20 more work in this area Q: What about modeling voice? A: We support this, it=92s actually similar to the Gold Service=20 example. You=92d create an instance of QoSService Q: how do we use this to configure devices, and how does it=20 relate to the core model? A: the QoS Device info model defines attributes that you can=20 use to configure mechanisms (e.g., RED droppers). The QoS=20 Info model provides the structure that encapsulates this=20 information. It=92s up to you if you want to use policies to=20 control this information or some other means. But the=20 information is defined in both cases by the Device QoS Info=20 Model. Note: this is not a completed model. So, it=92s not that we can=92t=20 or don=92t want to model certain policies, we just haven=92t gotten=20 there yet. Hugh - Policy Requirements Document (now 3 drafts) www.users.uswest.net/~hmahon/ is the common prefix. draft-ietf-policy-req-02.txt draft-mahon-policy-mgmt-00.txt draft-ietf-policy-use-00.txt Changes in Requirements draft. This was split into 3 drafts in=20 response to feedback from the community. The first draft=20 (draft-ietf-policy-req-02.txt) is just the requirements. Draft- mahon-policy-mgmt-00.txt and draft-mahon-policy-use-00.txt=20 talk about how policies are managed and use cases,=20 respectively. Also, tried to remove implementation=20 information and in general tried to cut down the draft size. Content Changes. Discuss situation in which policy would actually be used (e.g.,=20 why are people interested in policy management). Three=20 examples are VoIP, protect certain classes of traffic from other=20 classes of traffic, and to guarantee transfer time. Usage cases. New usage cases are a variation of Olympic=20 service in an ISP environment (customers connecting to an=20 ISP, where the ISP is repsonsible for delivering different=20 classes of service based on who the customer is). Second=20 example is Olympic service in an intranet. This is similar to=20 the first usage case, and both concentrate on how traffic is to=20 be marked and how traffic is deployed. Major issues. Policy information is not the same as a description of service. Need for rapid notification of changes to policy. Despite the=20 fact that policy is relatively static, it is a must that policy=20 information be delivered quickly (e.g., security, fix a broken=20 link, etc.). The point is that ven though policy doesn=92t change=20 very much, when it does change, it usually needs to be=20 deployed quickly. Methods for identifying traffic other than port numbers and IP=20 addresses is mandatory. Better, more complete information about the managed=20 environment needs to be available in a standardized way.=20 Security section of the document is changed to include=20 authorization, as opposed to just authentication, as mandatory=20 requirements. Next Steps Can continue to add more information, but is there a specific=20 direction that people would like the drafts to go? One=20 suggestion is to describe what need to be done by the=20 administrator to manage QoS in the environment, and then=20 describe the requirements to support those activities. Hugh thinks that the requirements and usage cases can help=20 guide the next revision of the Policy Framework document in=20 helping to continue to make the framework more robust and=20 complete. Yoram adds that one specific requirement that has=20 not been addressed in the framework are general signaling=20 requirements. Policy Management Scalability - Hugh Mahon File: draft-owens-policy-scalability-00.txt Topics in this draft are why we=92re concerned about scalability,=20 what types of things we need to think about when build a=20 policy management system, and what are the implications in=20 managing the policy management database. Objectives Need to manage large numbers of nodes at which policy is=20 deployed. But the problem is that nodes exist at numerous=20 locations, across multiple domains (e.g., administrative=20 domains within a company, etc. as well as different types of=20 policies, and who can govern/use which policy). In addition,=20 there is lots of information that needs to be combined to form=20 a policy, as well as different types of information. Organization Need to conside type as well as locality of policies. Using a=20 hierarchy of policies can significantly simplify the=20 management domain. Considerations Topology can be used to restrict the number of resources,=20 entities and/or people that need specific entries in the policy=20 database by using hierarchies of policies and repositories to=20 distribute the information Allocation Need to understand the frequency of access of the repository=20 and its availability, and then design Conclusion Need to create a partitioning of data... Q: You mentioned partitioning, rules, secondary servers, and=20 other similar things. This sounds like fundamental concerns=20 for modeling as well as schema design. Seems like this should=20 be folded back into the requirements draft (at least). Where do=20 you see the work going? A: Good question. Problem is that there is a lot of things to=20 consider. The question is how much of the discussion as to=20 why these are requirements should go back into the=20 requirements draft vs. staying outside. Comment: Seems like this crosses the info model draft as well=20 as the framework Wrapup (Ed) Two things need to be added. One, the operational aspects of=20 the device info model and the QoS info model need to be=20 documented - this seems to belong in the framework doc. The=20 other is how this info model interacts with CIM (for example). ------=_NextPart_000_0089_01BFA293.8A9E0FD0-- From majordomo@raleigh.ibm.com Mon Apr 10 11:27:30 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17839 for ; Mon, 10 Apr 2000 11:27:30 -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 LAA29274; Mon, 10 Apr 2000 11:23:48 -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 LAA24632; Mon, 10 Apr 2000 11:23:49 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39122; Mon, 10 Apr 2000 10:53:53 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37572; Mon, 10 Apr 2000 10:53:49 -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 KAA24974 for ; Mon, 10 Apr 2000 10:53:51 -0400 Received: from bmailnj.iphighway.com ([63.89.157.130]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA16932 for ; Mon, 10 Apr 2000 10:53:48 -0400 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id <2PRFKDAH>; Mon, 10 Apr 2000 10:53:23 -0400 Message-Id: <6399122981E1D211AB490090271E0AA33C9DD5@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'John Strassner'" , policy@raleigh.ibm.com Cc: johns@cisco.com, Ed Ellesson , Randy Bush , "Wijnen, Bert (Bert)" Subject: RE: Draft Policy Framework WG minutes Date: Mon, 10 Apr 2000 10:53:19 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Francis Reichmeyer (IPHighway MA)" Hi, I have a couple questions on references made to the framework draft in the Adelaide minutes. The first one: "...the framework draft, which has been waiting for consensus to build in other affected working groups,..." Not sure what this means. Are we waiting for consensus from other WGs for something or from this WG? What are the issues we are waiting for consensus on? I don't remember the consensus issues being discussed at the meeting (I might have missed it). The other one: "Document hasn't received much attention, due to other pressing matters that this draft depends on." What pressing matters does this draft depend on? Thanks, -Fran > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Monday, April 10, 2000 5:22 AM > To: policy@raleigh.ibm.com > Cc: johns@cisco.com; Ed Ellesson; Randy Bush; Wijnen, Bert (Bert) > Subject: Draft Policy Framework WG minutes > > > Hello Policy Enthusiasts, > > please review the attached minutes, and send all comments > and corrections to me asap (COB next Thursday, 13 April). > This will ensure that these minutes and proceedings are > included in the official proceedings. > > Thanks and kind regards, > John Strassner > From majordomo@raleigh.ibm.com Mon Apr 10 22:01:52 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09698 for ; Mon, 10 Apr 2000 22:01:51 -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 VAA27710; Mon, 10 Apr 2000 21:56: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 VAA32052; Mon, 10 Apr 2000 21:56:01 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39422; Mon, 10 Apr 2000 21:25:01 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30448; Mon, 10 Apr 2000 21:24: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 VAA25828 for ; Mon, 10 Apr 2000 21:24:57 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA20370 for ; Mon, 10 Apr 2000 21:24:53 -0400 Received: from jstrassnlap (sj-dial-4-81.cisco.com [171.68.181.210]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id SAA20608; Mon, 10 Apr 2000 18:24:15 -0700 (PDT) Message-Id: <01ff01bfa354$ca68f640$23b544ab@cisco.com> From: "John Strassner" To: "Francis Reichmeyer \(IPHighway MA\)" , Cc: , "Ed Ellesson" , "Randy Bush" , "Wijnen, Bert \(Bert\)" References: <6399122981E1D211AB490090271E0AA33C9DD5@BMAILNJ> Subject: Re: Draft Policy Framework WG minutes Date: Mon, 10 Apr 2000 17:33:48 -0700 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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit Comments inline. regards, John ----- Original Message ----- From: "Francis Reichmeyer (IPHighway MA)" To: "'John Strassner'" ; Cc: ; "Ed Ellesson" ; "Randy Bush" ; "Wijnen, Bert (Bert)" Sent: Monday, April 10, 2000 7:53 AM Subject: RE: Draft Policy Framework WG minutes > Hi, > > I have a couple questions on references made to the framework > draft in the Adelaide minutes. > > The first one: > "...the framework draft, which > has been waiting for consensus to build in other affected > working groups,..." > Not sure what this means. Are we waiting for consensus from > other WGs for something or from this WG? What are the issues > we are waiting for consensus on? I don't remember the consensus > issues being discussed at the meeting (I might have missed it). The framework draft has been held up on a number of issues. Basic terminology (e.g., Policy Consumer or PDP) is one - you can't define a framework without agreed upon terms. Roles was another (but we have consensus on that now). Description of functionality of the Policy components is a third. > The other one: > "Document hasn't received much attention, due to other > pressing matters that this draft depends on." > What pressing matters does this draft depend on? Most of the pressing matters were getting consensus on terminology and operational descriptions. We don't have complete consensus, but imho we have enough agreement to get started revising this draft. > Thanks, > -Fran > > > > > > > > -----Original Message----- > > From: John Strassner [mailto:jstrassn@cisco.com] > > Sent: Monday, April 10, 2000 5:22 AM > > To: policy@raleigh.ibm.com > > Cc: johns@cisco.com; Ed Ellesson; Randy Bush; Wijnen, Bert (Bert) > > Subject: Draft Policy Framework WG minutes > > > > > > Hello Policy Enthusiasts, > > > > please review the attached minutes, and send all comments > > and corrections to me asap (COB next Thursday, 13 April). > > This will ensure that these minutes and proceedings are > > included in the official proceedings. > > > > Thanks and kind regards, > > John Strassner > > > > From majordomo@raleigh.ibm.com Tue Apr 11 14:04:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15305 for ; Tue, 11 Apr 2000 14:04:23 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA20658; Tue, 11 Apr 2000 14:00:55 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA36686; Tue, 11 Apr 2000 14:00:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42354; Tue, 11 Apr 2000 12:43:39 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45374; Tue, 11 Apr 2000 12:43: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 MAA22812 for ; Tue, 11 Apr 2000 12:43:34 -0400 Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [202.54.44.115]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id MAA35032 for ; Tue, 11 Apr 2000 12:43:01 -0400 Received: (qmail 12394 invoked from network); 11 Apr 2000 16:58:44 -0000 Received: from surya.cse.iitb.ernet.in (144.16.111.14) by mailhost.iitb.ac.in with SMTP; 11 Apr 2000 16:58:44 -0000 Received: from everest.cse.iitb.ernet.in (everest [144.16.111.4]) by surya.cse.iitb.ernet.in (8.8.8/8.8.8) with ESMTP id WAA15255 for ; Tue, 11 Apr 2000 22:11:15 +0530 (IST) Received: (from dhiman@localhost) by everest.cse.iitb.ernet.in (8.9.2/8.9.2) id WAA15547 for policy@raleigh.ibm.com; Tue, 11 Apr 2000 22:08:48 +0530 (GMT) Date: Tue, 11 Apr 2000 22:08:48 +0530 From: Dhiman Barman To: policy@raleigh.ibm.com Subject: docs Message-Id: <20000411220848.A13035@cse.iitb.ernet.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Dhiman Barman Hi, Can anyone suggest, how can I get hold of the following articles. www.tbg.com/content/Overview.asp?DocID=192/ and www.tbg.com/content/Overview.asp?DocID=198/ thanks, db From majordomo@raleigh.ibm.com Tue Apr 11 16:15:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19368 for ; Tue, 11 Apr 2000 16:15:05 -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 QAA29644; Tue, 11 Apr 2000 16:11:24 -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 QAA30986; Tue, 11 Apr 2000 16:07:44 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28008; Tue, 11 Apr 2000 15:41:45 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53596; Tue, 11 Apr 2000 15:41:43 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA12650 for ; Tue, 11 Apr 2000 15:41:46 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id OAA11198; Tue, 11 Apr 2000 14:41:14 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568BE.006C249C ; Tue, 11 Apr 2000 14:41:12 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Cc: johns@cisco.com, bwijnen@lucent.com, randy@psg.com Message-Id: <862568BE.006C2112.00@tivmta4.tivoli.com> Date: Tue, 11 Apr 2000 15:37:03 -0400 Subject: WG Last Call: draft-ietf-policy-core-info-model-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com PURPOSE: The purpose of this message is to re-initiate the Policy Framework WG last call on the "Policy Framework Core Information Model -- Version 1 Specification" document: draft-ietf-policy-core-info-model-05.txt You will find this draft in the IETF repository at: http://www.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-05.txt LAST CALL: Unless there are strong objections, we would like to consider this draft of the document to be the final one, before moving it forward for proposed standard status. Please send any such objections, as well as statements of support, to the mailing list, during the last call period. CHANGES: There were two outstanding issues in the core model, as of the Adelaide meeting. The resolution we reached in the meeting for both of these issues are covered in the -05 draft. The first was the representation of time intervals. The second was clarification for roles. All other comments from the previous last call were addressed in the -04 draft. ISSUE RESOLUTION: Regarding the issue that was discussed in the Adelaide meeting about moving certain "IP-wide" parameters into the core model, and out of the QOS-specific model: Having discussed this issue with a number of people during and after the last session in Adelaide, the resolution we reached was to continue to discuss "IP-wide" common parameters in the context of QOS as well as in the context of IPSP (IP Security Policy), and to document these once we have reached consensus across the appropriate technical domains and Internet protocols, including both IPv4 and IPv6. Rather than delay the core model approval for this continuing discussion, our plan is to document the appropriate common parameters once, in a separate document, once consensus has been reached across the appropriate technical domains and working groups. SCHEDULE: The last call starts today (Tuesday, April 11, 2000) and will last approximately two weeks. It will end on Tuesday, April 25, 2000. Thank you, John Strassner and Ed Ellesson, your co-chairs From majordomo@raleigh.ibm.com Wed Apr 12 13:27:22 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28522 for ; Wed, 12 Apr 2000 13:27:22 -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 NAA24810; Wed, 12 Apr 2000 13:23:01 -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 NAA26688; Wed, 12 Apr 2000 13:22:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44658; Wed, 12 Apr 2000 12:55:25 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51818; Wed, 12 Apr 2000 12:55:22 -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 MAA26202 for ; Wed, 12 Apr 2000 12:55:25 -0400 From: Black_David@emc.com Received: from mxbh4.isus.emc.com (42s0052.isus.emc.com [168.159.208.52] (may be forged)) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA24936 for ; Wed, 12 Apr 2000 12:55:21 -0400 Received: by 42s0052.isus.emc.com with Internet Mail Service (5.5.2448.0) id <2PS8HW1W>; Wed, 12 Apr 2000 12:54:53 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A0707120B@mxclsk.isus.emc.com> To: Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com Cc: johns@cisco.com, bwijnen@lucent.com, randy@psg.com Subject: Core Model Last Call Issue: Execution Semantics Date: Wed, 12 Apr 2000 12:54:48 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com Allow me to renew my objection to the fact that the core information model execution semantics are inherently ambiguous, and hence will lead to implementations that make different policy decisions when given identical policies and inputs. This objection has been raised before, and has been "featurized" rather than addressed in the core info model draft via the following text in Section 2.2: 2. An important decision to make is the semantic style of the representation of the information. The declarative approach that we are describing falls short of being a "true" declarative model. Such a model would also specify the algorithms used to combine the information and policy rules to achieve particular behavior. We avoid specifying algorithms for the same reason that we avoid specifying sets of steps to be followed in a policy rule. However, the design of the information model more closely follows that of a declarative language, and may be easier to understand if such a conceptual model is used. This leads to our third point, acknowledging a lack of "completeness" and instead relying on presenting information that the policy processing entity will work with. "presenting information that the policy processing entity will work with" implies that different entities will work with it in different ways. This will not lead to interoperation among those entities in a fashion that implements a single policy in a consistent fashion. IMHO, this needs to be corrected here, rather than patched over in the policies derived from this model, such as the QoS policy. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Wed Apr 12 18:28:25 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04611 for ; Wed, 12 Apr 2000 18:28:25 -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 SAA32118; Wed, 12 Apr 2000 18:24:57 -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 SAA03844; Wed, 12 Apr 2000 18:25:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60962; Wed, 12 Apr 2000 18:00:17 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56346; Wed, 12 Apr 2000 18:00:14 -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 SAA31022 for ; Wed, 12 Apr 2000 18:00:18 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28632 for ; Wed, 12 Apr 2000 18:00:13 -0400 Received: from jstrassnlap (sj-dial-3-228.cisco.com [171.68.180.229]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA03310; Wed, 12 Apr 2000 14:58:58 -0700 (PDT) Message-Id: <038a01bfa4ca$726df0e0$c5b544ab@cisco.com> From: "John Strassner" To: , , Cc: , , References: <0F31E5C394DAD311B60C00E029101A0707120B@mxclsk.isus.emc.com> Subject: Re: Core Model Last Call Issue: Execution Semantics Date: Wed, 12 Apr 2000 13:22:11 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit Hi David, I'm curious why you didn't mention this during our first last call. At some point, we need to go with the consensus, which is quite happy with the declarative approach. I also think that you need to explicitly state why you think that the "execution semantics are inherently ambiguous, and hence will lead to implementations that make different policy decisions when given identical policies and inputs". I would like an example, because I don't understand your next comment, which is: > "presenting information that the policy processing entity will work with" > implies that different entities will work with it in different ways. This is not implied at all. What is stated is that the design of the information model will present the information in a standard form. Your statement is someone specious, since even if I prescribed all of the steps of an algorithm, a processing entity could still decide that it needed to pre- or post-process those results, or even insert additional steps. I think that one could successfully argue that any of these three alternatives would result in a "divergent" implementation. That is exactly why we tried to avoid specifying all of the nitty gritty detail - it is impossible to cover all uses of a generic policy model by over-definition. > This will not lead to interoperation among those entities in a fashion > that implements a single policy in a consistent fashion. IMHO, this > needs to be corrected here, rather than patched over in the policies > derived from this model, such as the QoS policy. I don't follow at all. What do you mean by "patched" in the QoS policy model? So please, come up with some real, concrete examples as to why this model is broken, or at least suggest some clarifying wording. regards, John ----- Original Message ----- From: To: ; Cc: ; ; Sent: Wednesday, April 12, 2000 9:54 AM Subject: Core Model Last Call Issue: Execution Semantics > Allow me to renew my objection to the fact that the core information > model execution semantics are inherently ambiguous, and hence will lead > to implementations that make different policy decisions when given > identical policies and inputs. This objection has been raised before, > and has been "featurized" rather than addressed in the core info model > draft via the following text in Section 2.2: > > 2. An important decision to make is the semantic style of the > representation of the information. > > The declarative approach that we are describing falls short of > being a "true" declarative model. Such a model would also specify > the algorithms used to combine the information and policy rules to > achieve particular behavior. We avoid specifying algorithms for the > same reason that we avoid specifying sets of steps to be followed > in a policy rule. However, the design of the information model more > closely follows that of a declarative language, and may be easier > to understand if such a conceptual model is used. This leads to our > third point, acknowledging a lack of "completeness" and instead > relying on presenting information that the policy processing entity > will work with. > > "presenting information that the policy processing entity will work with" > implies that different entities will work with it in different ways. > This will not lead to interoperation among those entities in a fashion > that implements a single policy in a consistent fashion. IMHO, this > needs to be corrected here, rather than patched over in the policies > derived from this model, such as the QoS policy. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > black_david@emc.com Cellular: +1 (978) 394-7754 > --------------------------------------------------- > > > From majordomo@raleigh.ibm.com Thu Apr 13 09:07:32 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29669 for ; Thu, 13 Apr 2000 09:07:31 -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 JAA06688; Thu, 13 Apr 2000 09:02:04 -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 JAA12732; Thu, 13 Apr 2000 09:02:05 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56568; Thu, 13 Apr 2000 08:32:46 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35730; Thu, 13 Apr 2000 08:32:38 -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 IAA28670 for ; Thu, 13 Apr 2000 08:32:39 -0400 Received: from x86unx3.comp.nus.edu.sg (root@x86unx3.comp.nus.edu.sg [137.132.90.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA26564 for ; Thu, 13 Apr 2000 08:32:34 -0400 Received: from decunx.comp.nus.edu.sg (sujathan@decunx-m.comp.nus.edu.sg [137.132.90.9]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with ESMTP id UAA17399; Thu, 13 Apr 2000 20:32:17 +0800 (GMT-8) Received: from localhost (sujathan@localhost) by decunx.comp.nus.edu.sg (8.8.5/8.8.5) with ESMTP id UAA01211; Thu, 13 Apr 2000 20:32:16 +0800 (SST) Date: Thu, 13 Apr 2000 20:32:16 +0800 (SST) From: Su To: John Strassner Cc: Black_David@emc.com, Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com, johns@cisco.com, bwijnen@lucent.com, randy@psg.com Subject: Newbie question In-Reply-To: <038a01bfa4ca$726df0e0$c5b544ab@cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Su Hello all. I am new to this list. If I am asking this question in the wrong forum, kindly correct me. After having read through RFC2748, 2749 and 2750, I still don't understand a few things. 1. Does COPS define how administrative domains are to be represented? I don't believe that client-handle is unique for a unique socket. For example, if in an organisation, there were three admin-domain viz. top-management, admin and tech-staff... then, the same socket can be used by people from different domains. And since they are from different domains, the policies pertaining to each of them should be different (intuitively speaking). How does the current COPS version handle this? How can I specify a client-handle? 2. Is Client-SI fully and comprehensively defined? Thank you for taking the time to read this newbie question. Cheers! --Su. ******************************************************************************* Sujatha Natraj National University of Singapore Undergraduate, year 3 Dept. of Computer Engineering SMTP :sujatha@geektown.net HTTP :http://www.comp.nus.edu.sg/~sujathan ******************************************************************************* From majordomo@raleigh.ibm.com Thu Apr 13 11:11:43 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04211 for ; Thu, 13 Apr 2000 11:11:42 -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 LAA20842; Thu, 13 Apr 2000 11:08:37 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA30110; Thu, 13 Apr 2000 11:08:38 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52214; Thu, 13 Apr 2000 10:08:53 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30958; Thu, 13 Apr 2000 10:08:50 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA34662 for ; Thu, 13 Apr 2000 10:08:52 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id JAA22059; Thu, 13 Apr 2000 09:08:17 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568C0.004DA683 ; Thu, 13 Apr 2000 09:08:08 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: Black_David@emc.com Cc: policy@raleigh.ibm.com, johns@cisco.com, bwijnen@lucent.com, randy@psg.com Message-Id: <862568C0.004DA4BB.00@tivmta4.tivoli.com> Date: Thu, 13 Apr 2000 10:03:59 -0400 Subject: Re: Core Model Last Call Issue: Execution Semantics Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com David, I agree with you that your objection has been raised by you a number of times before, on both the mailing list and in policy framework working group meetings at the IETF. On each occasion that you raised this objection, discussion of the issue ensued. After each of those discussions, John and I declared the consensus of the working group to be that your objection was invalid for the purposes of this working group. I should also point out: 1. You missed your opportunity to make this objection in the last "last call" period, which ended on February 3, 2000. We have already made all the changes based on feedback from that period, hence we have now moved to the "final" last call period in which we now find ourselves. 2. The model has been this way (sans algorithms) from the very beginning. 3. You have continued to object, in principle, to this working group's model on this same point (that is, whenever you chose to pay attention to the working group), but I do not recall ever seeing from you a concrete alternative proposal in the form of a changed model, complete with examples of the algorithms you want to see standardized, that would benefit from this different, more precedural approach. As a number of people have pointed out in our past discussions of this point, trying to standardize specific algorithms will fail, because implementors will object to such constraints. Different implementors are working with different hardware, which cannot accomodate a "one-size fits all" algorithm. Based on the above, John and I, with the support of our AD's, do indeed declare that we have (rough) consensus, albeit not unanimous, for declining to incorporate the corrections which you perceive to be needed, but which do not reflect the consensus of the working group, and, in any case, which you have not enumerated. John and Ed Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 Black_David@emc.com on 04/12/2000 12:54:48 PM Please respond to Black_David@emc.com To: Ed Ellesson/Tivoli Systems@Tivoli Systems, policy@raleigh.ibm.com cc: johns@cisco.com, bwijnen@lucent.com, randy@psg.com Subject: Core Model Last Call Issue: Execution Semantics Allow me to renew my objection to the fact that the core information model execution semantics are inherently ambiguous, and hence will lead to implementations that make different policy decisions when given identical policies and inputs. This objection has been raised before, and has been "featurized" rather than addressed in the core info model draft via the following text in Section 2.2: 2. An important decision to make is the semantic style of the representation of the information. The declarative approach that we are describing falls short of being a "true" declarative model. Such a model would also specify the algorithms used to combine the information and policy rules to achieve particular behavior. We avoid specifying algorithms for the same reason that we avoid specifying sets of steps to be followed in a policy rule. However, the design of the information model more closely follows that of a declarative language, and may be easier to understand if such a conceptual model is used. This leads to our third point, acknowledging a lack of "completeness" and instead relying on presenting information that the policy processing entity will work with. "presenting information that the policy processing entity will work with" implies that different entities will work with it in different ways. This will not lead to interoperation among those entities in a fashion that implements a single policy in a consistent fashion. IMHO, this needs to be corrected here, rather than patched over in the policies derived from this model, such as the QoS policy. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Thu Apr 13 17:55:56 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14802 for ; Thu, 13 Apr 2000 17:55:56 -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 RAA21482; Thu, 13 Apr 2000 17:52:58 -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 RAA36802; Thu, 13 Apr 2000 17:52:57 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36222; Thu, 13 Apr 2000 17:25:45 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26984; Thu, 13 Apr 2000 17:25:42 -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 RAA30634 for ; Thu, 13 Apr 2000 17:25:45 -0400 From: Black_David@emc.com Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA29790 for ; Thu, 13 Apr 2000 17:25:41 -0400 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id <25PTG16Y>; Thu, 13 Apr 2000 17:25:12 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A0707121F@mxclsk.isus.emc.com> To: jstrassn@cisco.com, Black_David@emc.com, Ed_Ellesson@tivoli.com, policy@raleigh.ibm.com Cc: johns@cisco.com, bwijnen@lucent.com, randy@psg.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Thu, 13 Apr 2000 17:25:11 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com > At some point, we need to go with the consensus, > which is quite happy with the declarative approach. I'm also quite happy with the declarative approach. I just want to see clearly defined execution semantics so that the results can be determined from a policy and its inputs without having to resort to the words "implementation defined". > I also think that you need to explicitly state why you think > that the "execution semantics are inherently ambiguous, and > hence will lead to implementations that make different > policy decisions when given identical policies and inputs". > I would like an example, From my presentation to the policy WG in Minneapolis in March 1999: Example: Rule 1: Engineers get Bronze service. Rule 2: John gets Gold service. Fact: John is an Engineer. Oops: No rule priority specified When and where does John get Gold service? Might change at 3am for no good reason A year later, the core model and schema still cannot answer the "when and where" question. > even if I prescribed all of the steps of an algorithm, > a processing entity could still decide that it needed to > pre- or post-process those results, or even insert > additional steps. I don't care what algorithm is used. What I care about is that for a given set of inputs (policy + conditions) there is one correct output as far as the model is concerned. Here's some language from RFC 2401 (IPsec architecture) that deals with a similar issue in the IPsec Security Association Database: The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model. > That is exactly why we tried to > avoid specifying all of the nitty gritty detail - it is > impossible to cover all uses of a generic policy model by > over-definition. I agree with the general principle, but would suggest that not being able to specify the outputs is serious under-definition. > What do you mean by "patched" in the QoS policy model? The following sections of the Policy QoS Schema draft: 8.5. Class qosNamedPolicyContainer 21 8.5.1. The Attribute qpPriority 21 8.5.2. The Attribute qpPolicyRuleMatchMethod 21 This is mostly dealing with the inability of the core model to specify whether one or all of the matching rules should be performed. Unfortunately, the priority description matches the core model/schema and hence allows implementation-defined ordering. I had thought that this was more strongly worded in the past. > or at least suggest some clarifying wording. Again, from RFC 2401, here's a worked example of how the problem was solved in applying the IPsec Security Policy Database to outbound traffic. NOTE -- IPsec uses different terminology: An IPsec Security Policy is analogous to a rule in the core schema and model; it contains conditions that identify traffic and actions to indicate how that traffic is to be processed. The IPsec Security Policy Database a collection of such rules. Here's the RFC 2401 text from section 4.4.1: As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5. Note the use of MUST rather than SHOULD. Someone other than me clearly thought that this was important. This particular solution doesn't map into the hierarchical structure of the core model/schema, although I believe that at least one of the efforts to build a policy-based router did follow such a linear ordering approach. A solution I have proposed in the past is to use DN (fully qualified) lexical ordering to break ties when priority does not, but given the additional execution structure (Named Policy Container) that is now present in the QoS schema, some sort of escape wording is needed to allow derived schemas to add additional execution control structures. IMHO, the fact that control structures expressed solely in terms of rules have to be added in the QoS model/schema indicates that the core model/schema has missed something important. Summarizing the issues in Ed's mail: - Should this have been raised in the earlier last call? Probably. Would the results have been any different? Probably not. - Does this require specifying "algorithms"? No, just consistent repeatable behavior. - Has there ever been a concrete alternative proposal? Lexical ordering based on DNs was in my presentation at the 3/99 Minneapolis IETF. It is up to the WG and the chairs as the determiners of "rough consensus" to deal with these issues. I leave this to others on the list to decide whether this is important or not. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Thu Apr 13 19:10:06 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15631 for ; Thu, 13 Apr 2000 19:10: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 TAA06334; Thu, 13 Apr 2000 19:06:58 -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 TAA37118; Thu, 13 Apr 2000 19:07:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38312; Thu, 13 Apr 2000 18:33:16 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31636; Thu, 13 Apr 2000 18:33:13 -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 SAA34666 for ; Thu, 13 Apr 2000 18:33:17 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA15180 for ; Thu, 13 Apr 2000 18:33:15 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRG11H>; Thu, 13 Apr 2000 15:30:38 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC756@SOL> From: Andrew Smith To: policy@raleigh.ibm.com Cc: "'Black_David@emc.com'" Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Thu, 13 Apr 2000 15:30:37 -0700 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: Andrew Smith All of the technology-specific incarnations of QoS policy models that are being worked on at IETF have had to face up to the issue of "rule precedence" issue sooner or later: Diffserv Model/MIB/PIBs, LDAP policy rule schemas, the new device QoS model from Walter/Dave/Andrea/John, not to mention all the device CLIs that I've seen. And it came up again in the SNMPCONF meeting in Adelaide where a whole new crowd of people were seen and heard grappling with comprehending it. So, it seems to me, admittedly not ever actually having read the core model from cover to cover (I've dipped into it many times over the years in attempts to work out how useful stuff is supposed to be derived from it), that this issue is *so* fundamental that it ought to be covered somewhere in a technology-independent fashion. It may be that I don't understand the purpose of the core model draft but it sure seems like an obvious place to give this issue some treatment - and that should include MUSTs as appropriate. Of course, the fact that I haven't ever felt an overwhelming need to dedicate a tree to printing and reading the draft properly might be indicative of the importance to me of fixing it. So, take that as another dissenting voice alongside David's (actually, standing behind him would be more accurate: when volunteers are called for, I won't have the time to provide the fixes). Andrew > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, April 13, 2000 2:25 PM > To: jstrassn@cisco.com; Black_David@emc.com; Ed_Ellesson@tivoli.com; > policy@raleigh.ibm.com > Cc: johns@cisco.com; bwijnen@lucent.com; randy@psg.com > Subject: RE: Core Model Last Call Issue: Execution Semantics ... > It is up to the WG and the chairs as the determiners of > "rough consensus" > to deal with these issues. I leave this to others on the > list to decide > whether this is important or not. > > --David **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** From majordomo@raleigh.ibm.com Fri Apr 14 09:45:45 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07642 for ; Fri, 14 Apr 2000 09:45:44 -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 JAA18056; Fri, 14 Apr 2000 09:38:52 -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 JAA32916; Fri, 14 Apr 2000 09:38:51 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36812; Fri, 14 Apr 2000 09:15:33 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36802; Fri, 14 Apr 2000 09:15:29 -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 JAA06418 for ; Fri, 14 Apr 2000 09:15:31 -0400 From: remoore@us.ibm.com Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id JAA47696; Fri, 14 Apr 2000 09:15:29 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C1.0048D136 ; Fri, 14 Apr 2000 09:15:21 -0400 X-Lotus-Fromdomain: IBMUS To: Andrew Smith Cc: policy@raleigh.ibm.com, "'Black_David@emc.com'" Message-Id: <852568C1.0048CD90.00@d54mta04.raleigh.ibm.com> Date: Fri, 14 Apr 2000 09:08:55 -0400 Subject: RE: Core Model Last Call Issue: Execution Semantics Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Andrew, Thanks for your input. I can't tell from your note, though, whether you're aware of a key feature of David's position, and of the discussion related to it that has gone on for more than a year now: David's concern relates only to predictable behavior among PEPs in the *absence* of rule priorities. The PCIM has always given the policy administrator the ability to tell PEPs how to resolve rule conflicts, by assigning different values to the Priority property. (As I look at the document now, I don't see an explicit statement that a PEP "MUST" respect rule priorities if they're specified. If the WG feels this is needed, we can certainly add a sentence that says it.) David is interested in deterministic behavior in the case where rule priorities are *not* specified -- hence the "Oops: No rule priority specified" in the example he cites. So it's not true in general that the PCIM makes it impossible to specify the outputs when a PEP processes a set of Policy Rules. This is impossible only if the policy administrator fails to avail him/herself of the mechanism included in the PCIM to guarantee predictable results. Now we could have made Priority a mandatory property for a Policy Rule. (This, by the way, is how I read the paragraph from RFC 2401 that David cites: SPD entries must be ordered, and then the entities that "consume" these entries must respect this ordering. To be analogous to David's current position, I think that RFC 2401 would have had to require that even if the SPD entries were *not* ordered, all entities that make use of them would be required to behave in the same way.) But given that we didn't make it mandatory, we've given the policy administrator a way to say "I don't care how these rules are prioritized relative to each other -- however you do it is fine with me." If the policy administrator is uncomfortable with unpredictable results for a set of Policy Rules, he/she(*) can always specify Priority values for the rules. Regards, Bob (*) It doesn't even have to be the policy administrator. If a Policy Management Tool vendor is uneasy about unpredictable behavior, then the tool itself can introduce Priority values if the policy administrator doesn't. The PEP will then respect these Priority values, without knowing or caring where they came from. Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Andrew Smith @raleigh.ibm.com on 04/13/2000 06:30:37 PM Please respond to Andrew Smith Sent by: policy-owner@raleigh.ibm.com To: policy@raleigh.ibm.com cc: "'Black_David@emc.com'" Subject: RE: Core Model Last Call Issue: Execution Semantics All of the technology-specific incarnations of QoS policy models that are being worked on at IETF have had to face up to the issue of "rule precedence" issue sooner or later: Diffserv Model/MIB/PIBs, LDAP policy rule schemas, the new device QoS model from Walter/Dave/Andrea/John, not to mention all the device CLIs that I've seen. And it came up again in the SNMPCONF meeting in Adelaide where a whole new crowd of people were seen and heard grappling with comprehending it. So, it seems to me, admittedly not ever actually having read the core model from cover to cover (I've dipped into it many times over the years in attempts to work out how useful stuff is supposed to be derived from it), that this issue is *so* fundamental that it ought to be covered somewhere in a technology-independent fashion. It may be that I don't understand the purpose of the core model draft but it sure seems like an obvious place to give this issue some treatment - and that should include MUSTs as appropriate. Of course, the fact that I haven't ever felt an overwhelming need to dedicate a tree to printing and reading the draft properly might be indicative of the importance to me of fixing it. So, take that as another dissenting voice alongside David's (actually, standing behind him would be more accurate: when volunteers are called for, I won't have the time to provide the fixes). Andrew > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Thursday, April 13, 2000 2:25 PM > To: jstrassn@cisco.com; Black_David@emc.com; Ed_Ellesson@tivoli.com; > policy@raleigh.ibm.com > Cc: johns@cisco.com; bwijnen@lucent.com; randy@psg.com > Subject: RE: Core Model Last Call Issue: Execution Semantics ... > It is up to the WG and the chairs as the determiners of > "rough consensus" > to deal with these issues. I leave this to others on the > list to decide > whether this is important or not. > > --David **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** From majordomo@raleigh.ibm.com Fri Apr 14 15:29:08 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13313 for ; Fri, 14 Apr 2000 15:29:08 -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 PAA38104; Fri, 14 Apr 2000 15:16:40 -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 PAA33854; Fri, 14 Apr 2000 15:16:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52754; Fri, 14 Apr 2000 14:48:55 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47856; Fri, 14 Apr 2000 14:48:49 -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 OAA29878 for ; Fri, 14 Apr 2000 14:48:53 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA06268 for ; Fri, 14 Apr 2000 14:48:47 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRGJNZ>; Fri, 14 Apr 2000 11:46:13 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC763@SOL> From: Andrew Smith To: "'remoore@us.ibm.com'" Cc: policy@raleigh.ibm.com, "'Black_David@emc.com'" Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Fri, 14 Apr 2000 11:46:12 -0700 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: Andrew Smith OK, but why on earth is the priority attribute optional? It's absence should always be an "oops". I don't see why leaving it out, at the PDP-PEP boundary, is ever helpful - it is trivial to default it in an implementation. Andrew > -----Original Message----- > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] > Sent: Friday, April 14, 2000 6:09 AM > To: Andrew Smith > Cc: policy@raleigh.ibm.com; 'Black_David@emc.com' > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > Andrew, > > Thanks for your input. I can't tell from your note, though, whether > you're aware of a key feature of David's position, and of the > discussion related to it that has gone on for more than a year now: > David's concern relates only to predictable behavior among PEPs in > the *absence* of rule priorities. The PCIM has always given the > policy administrator the ability to tell PEPs how to resolve rule > conflicts, by assigning different values to the Priority property. > (As I look at the document now, I don't see an explicit statement > that a PEP "MUST" respect rule priorities if they're specified. > If the WG feels this is needed, we can certainly add a sentence that > says it.) > > David is interested in deterministic behavior in the case where rule > priorities are *not* specified -- hence the "Oops: No rule priority > specified" in the example he cites. So it's not true in general that > the PCIM makes it impossible to specify the outputs when a PEP > processes a set of Policy Rules. This is impossible only if the > policy administrator fails to avail him/herself of the mechanism > included in the PCIM to guarantee predictable results. > > Now we could have made Priority a mandatory property for a Policy > Rule. (This, by the way, is how I read the paragraph from RFC 2401 > that David cites: SPD entries must be ordered, and then the > entities that "consume" these entries must respect this ordering. > To be analogous to David's current position, I think that RFC 2401 > would have had to require that even if the SPD entries were *not* > ordered, all entities that make use of them would be required to > behave in the same way.) But given that we didn't make it mandatory, > we've given the policy administrator a way to say "I don't care how > these rules are prioritized relative to each other -- however you do > it is fine with me." If the policy administrator is uncomfortable > with unpredictable results for a set of Policy Rules, he/she(*) can > always specify Priority values for the rules. > > Regards, > Bob > > (*) It doesn't even have to be the policy administrator. If a > Policy Management Tool vendor is uneasy about unpredictable > behavior, then the tool itself can introduce Priority values if > the policy administrator doesn't. The PEP will then respect these > Priority values, without knowing or caring where they came from. > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith @raleigh.ibm.com on > 04/13/2000 > 06:30:37 PM > > Please respond to Andrew Smith > > Sent by: policy-owner@raleigh.ibm.com > > > To: policy@raleigh.ibm.com > cc: "'Black_David@emc.com'" > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > All of the technology-specific incarnations of QoS policy > models that are > being worked on at IETF have had to face up to the issue of "rule > precedence" issue sooner or later: Diffserv Model/MIB/PIBs, > LDAP policy > rule > schemas, the new device QoS model from Walter/Dave/Andrea/John, not to > mention all the device CLIs that I've seen. And it came up > again in the > SNMPCONF meeting in Adelaide where a whole new crowd of > people were seen > and > heard grappling with comprehending it. > > So, it seems to me, admittedly not ever actually having read > the core model > from cover to cover (I've dipped into it many times over the years in > attempts to work out how useful stuff is supposed to be > derived from it), > that this issue is *so* fundamental that it ought to be > covered somewhere > in > a technology-independent fashion. It may be that I don't > understand the > purpose of the core model draft but it sure seems like an > obvious place to > give this issue some treatment - and that should include MUSTs as > appropriate. > > Of course, the fact that I haven't ever felt an overwhelming need to > dedicate a tree to printing and reading the draft properly might be > indicative of the importance to me of fixing it. So, take > that as another > dissenting voice alongside David's (actually, standing behind > him would be > more accurate: when volunteers are called for, I won't have > the time to > provide the fixes). > > Andrew > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Thursday, April 13, 2000 2:25 PM > > To: jstrassn@cisco.com; Black_David@emc.com; Ed_Ellesson@tivoli.com; > > policy@raleigh.ibm.com > > Cc: johns@cisco.com; bwijnen@lucent.com; randy@psg.com > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > ... > > > It is up to the WG and the chairs as the determiners of > > "rough consensus" > > to deal with these issues. I leave this to others on the > > list to decide > > whether this is important or not. > > > > --David > > **************************************************************** > Andrew Smith tel: +1 (408) 579-2821 > Extreme Networks fax: +1 (408) 579-3000 > 3585 Monroe St. http://www.extremenetworks.com > Santa Clara CA 95051-1450 em: andrew@extremenetworks.com > **************************************************************** > > > > From majordomo@raleigh.ibm.com Fri Apr 14 16:09:17 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13798 for ; Fri, 14 Apr 2000 16:09:16 -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 QAA27270; Fri, 14 Apr 2000 16:03: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 QAA31880; Fri, 14 Apr 2000 16:03:26 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43514; Fri, 14 Apr 2000 15:37:23 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48882; Fri, 14 Apr 2000 15:37:20 -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 PAA33850 for ; Fri, 14 Apr 2000 15:37:23 -0400 From: Black_David@emc.com Received: from mxbh4.isus.emc.com (42s0052.isus.emc.com [168.159.208.52] (may be forged)) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA28190 for ; Fri, 14 Apr 2000 15:37:22 -0400 Received: by 42s0052.isus.emc.com with Internet Mail Service (5.5.2448.0) id <2PS8J1Y6>; Fri, 14 Apr 2000 15:36:52 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A0707122D@mxclsk.isus.emc.com> To: andrew@extremenetworks.com, remoore@us.ibm.com Cc: policy@raleigh.ibm.com, Black_David@emc.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Fri, 14 Apr 2000 15:36:48 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com > OK, but why on earth is the priority attribute optional? It's absence should > always be an "oops". I don't see why leaving it out, at the PDP-PEP > boundary, is ever helpful - it is trivial to default it in an implementation. Making priority mandatory is at best a step towards addressing the problem in the small. Finishing the job entails requiring that all priorities are unique - the IPsec SPD does this by implicitly associating priority with the entry position in the linear ordering - since no two entries can be in the same position in a linear order, the desired result follows. IMHO, requiring that each rule has a unique priority does not scale up well in the core model. I can see two alternative approaches: (1) Adopt the Container construct from the QoS model, require unique priorities within each Container, and describe how to order nested priorities (it's like ordering words in a dictionary: albatross comes before alpha because b comes before p). (2) Use the corresponding lexical ordering of DNs to resolve ties that aren't resolved by priority. Both of these approaches match the hierarchical structure of the policy model in a fashion similar to linear search matching the linear ordering of the IPsec SPD. I'm disappointed that Bob has mischaracterized RFC 2401. The second piece of text that I quoted from RFC 2401 is an exact match to what I'm advocating, specifically: - Consistent, predictable processing is required in all cases (must). - Linear ordering of the SPD and search in that order has been chosen as the approach to meet that requirement (MUST). To get that RFC 2401 text to match the approach proposed in the core model, one would have to replace its MUSTs with MAYs, and remove the text that requires "consistent, predictable processing". The WG is free to reject that requirement, but should only do so with a full understanding of' why RFC 2401 did something fundamentally different. IMHO, requirements for "consistent, predictable processing" are not unique to security. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Fri Apr 14 16:38:03 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14171 for ; Fri, 14 Apr 2000 16:38: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 QAA20254; Fri, 14 Apr 2000 16:34:49 -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 QAA35692; Fri, 14 Apr 2000 16:34:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15534; Fri, 14 Apr 2000 16:06:23 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15510; Fri, 14 Apr 2000 16:06:18 -0400 Received: from devmail.dev.tivoli.com (devmail.dev.tivoli.com [146.84.30.139]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA27424 for ; Fri, 14 Apr 2000 16:06:19 -0400 From: Ed_Ellesson@tivoli.com Received: from MTA-Austin2.tivoli.com (notes-mta2.tivoli.com [146.84.104.7]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with SMTP id PAA24384; Fri, 14 Apr 2000 15:05:39 -0500 (CDT) Received: by MTA-Austin2.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568C1.006E5D7D ; Fri, 14 Apr 2000 15:05:28 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: Andrew Smith Cc: "'remoore@us.ibm.com'" , policy@raleigh.ibm.com, "'Black_David@emc.com'" Message-Id: <862568C1.006E5BFE.00@MTA-Austin2.tivoli.com> Date: Fri, 14 Apr 2000 16:01:30 -0400 Subject: RE: Core Model Last Call Issue: Execution Semantics Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Andrew, Even if you make the priority mandatory, and the default is some value, let's say "zero", if the administrator doesn't set it, that still doesn't solve David's problem, because he wants default behavior to be deterministic. That is, if all the priorities are set to the same value (the default), he wants a deterministic order of priority of execution. Making the priority mandatory with a default is pretty much equivalent to making it optional, in my opinion, but if that will satisfy the dissenters, I won't object. Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 Andrew Smith on 04/14/2000 02:46:12 PM Please respond to Andrew Smith To: "'remoore@us.ibm.com'" cc: policy@raleigh.ibm.com, "'Black_David@emc.com'" (bcc: Ed Ellesson/Tivoli Systems) Subject: RE: Core Model Last Call Issue: Execution Semantics OK, but why on earth is the priority attribute optional? It's absence should always be an "oops". I don't see why leaving it out, at the PDP-PEP boundary, is ever helpful - it is trivial to default it in an implementation. Andrew > -----Original Message----- > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] > Sent: Friday, April 14, 2000 6:09 AM > To: Andrew Smith > Cc: policy@raleigh.ibm.com; 'Black_David@emc.com' > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > Andrew, > > Thanks for your input. I can't tell from your note, though, whether > you're aware of a key feature of David's position, and of the > discussion related to it that has gone on for more than a year now: > David's concern relates only to predictable behavior among PEPs in > the *absence* of rule priorities. The PCIM has always given the > policy administrator the ability to tell PEPs how to resolve rule > conflicts, by assigning different values to the Priority property. > (As I look at the document now, I don't see an explicit statement > that a PEP "MUST" respect rule priorities if they're specified. > If the WG feels this is needed, we can certainly add a sentence that > says it.) > > David is interested in deterministic behavior in the case where rule > priorities are *not* specified -- hence the "Oops: No rule priority > specified" in the example he cites. So it's not true in general that > the PCIM makes it impossible to specify the outputs when a PEP > processes a set of Policy Rules. This is impossible only if the > policy administrator fails to avail him/herself of the mechanism > included in the PCIM to guarantee predictable results. > > Now we could have made Priority a mandatory property for a Policy > Rule. (This, by the way, is how I read the paragraph from RFC 2401 > that David cites: SPD entries must be ordered, and then the > entities that "consume" these entries must respect this ordering. > To be analogous to David's current position, I think that RFC 2401 > would have had to require that even if the SPD entries were *not* > ordered, all entities that make use of them would be required to > behave in the same way.) But given that we didn't make it mandatory, > we've given the policy administrator a way to say "I don't care how > these rules are prioritized relative to each other -- however you do > it is fine with me." If the policy administrator is uncomfortable > with unpredictable results for a set of Policy Rules, he/she(*) can > always specify Priority values for the rules. > > Regards, > Bob > > (*) It doesn't even have to be the policy administrator. If a > Policy Management Tool vendor is uneasy about unpredictable > behavior, then the tool itself can introduce Priority values if > the policy administrator doesn't. The PEP will then respect these > Priority values, without knowing or caring where they came from. > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > Andrew Smith @raleigh.ibm.com on > 04/13/2000 > 06:30:37 PM > > Please respond to Andrew Smith > > Sent by: policy-owner@raleigh.ibm.com > > > To: policy@raleigh.ibm.com > cc: "'Black_David@emc.com'" > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > All of the technology-specific incarnations of QoS policy > models that are > being worked on at IETF have had to face up to the issue of "rule > precedence" issue sooner or later: Diffserv Model/MIB/PIBs, > LDAP policy > rule > schemas, the new device QoS model from Walter/Dave/Andrea/John, not to > mention all the device CLIs that I've seen. And it came up > again in the > SNMPCONF meeting in Adelaide where a whole new crowd of > people were seen > and > heard grappling with comprehending it. > > So, it seems to me, admittedly not ever actually having read > the core model > from cover to cover (I've dipped into it many times over the years in > attempts to work out how useful stuff is supposed to be > derived from it), > that this issue is *so* fundamental that it ought to be > covered somewhere > in > a technology-independent fashion. It may be that I don't > understand the > purpose of the core model draft but it sure seems like an > obvious place to > give this issue some treatment - and that should include MUSTs as > appropriate. > > Of course, the fact that I haven't ever felt an overwhelming need to > dedicate a tree to printing and reading the draft properly might be > indicative of the importance to me of fixing it. So, take > that as another > dissenting voice alongside David's (actually, standing behind > him would be > more accurate: when volunteers are called for, I won't have > the time to > provide the fixes). > > Andrew > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Thursday, April 13, 2000 2:25 PM > > To: jstrassn@cisco.com; Black_David@emc.com; Ed_Ellesson@tivoli.com; > > policy@raleigh.ibm.com > > Cc: johns@cisco.com; bwijnen@lucent.com; randy@psg.com > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > ... > > > It is up to the WG and the chairs as the determiners of > > "rough consensus" > > to deal with these issues. I leave this to others on the > > list to decide > > whether this is important or not. > > > > --David > > **************************************************************** > Andrew Smith tel: +1 (408) 579-2821 > Extreme Networks fax: +1 (408) 579-3000 > 3585 Monroe St. http://www.extremenetworks.com > Santa Clara CA 95051-1450 em: andrew@extremenetworks.com > **************************************************************** > > > > From majordomo@raleigh.ibm.com Fri Apr 14 16:43:09 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14250 for ; Fri, 14 Apr 2000 16:43:08 -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 QAA25674; Fri, 14 Apr 2000 16:34:46 -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 QAA35680; Fri, 14 Apr 2000 16:34:45 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49726; Fri, 14 Apr 2000 16:10:03 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48690; Fri, 14 Apr 2000 16:10:00 -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 QAA31926 for ; Fri, 14 Apr 2000 16:10:03 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA22658 for ; Fri, 14 Apr 2000 16:10:01 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRGKA4>; Fri, 14 Apr 2000 13:07:23 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC768@SOL> From: Andrew Smith To: "'Ed_Ellesson@tivoli.com'" Cc: policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Fri, 14 Apr 2000 13:07:21 -0700 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: Andrew Smith The difference is that you can then detect the conflict in the PDP before you bother the poor PEP with the problem i.e. the "oops" error message is internal to the PDP and we can treate it as a "don't do that" condition at the PEP-PDP boundary: this is a major win. Andrew > -----Original Message----- > From: Ed_Ellesson@tivoli.com [mailto:Ed_Ellesson@tivoli.com] > Sent: Friday, April 14, 2000 1:02 PM > To: Andrew Smith > Cc: 'remoore@us.ibm.com'; policy@raleigh.ibm.com; > 'Black_David@emc.com' > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > Andrew, > > Even if you make the priority mandatory, and the default is > some value, let's > say "zero", if the administrator doesn't set it, that still > doesn't solve > David's problem, because he wants default behavior to be > deterministic. That > is, if all the priorities are set to the same value (the > default), he wants a > deterministic order of priority of execution. > > Making the priority mandatory with a default is pretty much > equivalent to making > it optional, in my opinion, but if that will satisfy the > dissenters, I won't > object. > > Ed Ellesson > Tivoli Systems > Research Triangle Park, NC > ed_ellesson@tivoli.com > 919-254-4115 > > > Andrew Smith on 04/14/2000 02:46:12 PM > > Please respond to Andrew Smith > > To: "'remoore@us.ibm.com'" > cc: policy@raleigh.ibm.com, "'Black_David@emc.com'" > > (bcc: Ed Ellesson/Tivoli Systems) > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > OK, but why on earth is the priority attribute optional? It's > absence should > always be an "oops". I don't see why leaving it out, at the PDP-PEP > boundary, is ever helpful - it is trivial to default it in an > implementation. > > Andrew > > > -----Original Message----- > > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] > > Sent: Friday, April 14, 2000 6:09 AM > > To: Andrew Smith > > Cc: policy@raleigh.ibm.com; 'Black_David@emc.com' > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > > > > > > Andrew, > > > > Thanks for your input. I can't tell from your note, though, whether > > you're aware of a key feature of David's position, and of the > > discussion related to it that has gone on for more than a year now: > > David's concern relates only to predictable behavior among PEPs in > > the *absence* of rule priorities. The PCIM has always given the > > policy administrator the ability to tell PEPs how to resolve rule > > conflicts, by assigning different values to the Priority property. > > (As I look at the document now, I don't see an explicit statement > > that a PEP "MUST" respect rule priorities if they're specified. > > If the WG feels this is needed, we can certainly add a sentence that > > says it.) > > > > David is interested in deterministic behavior in the case where rule > > priorities are *not* specified -- hence the "Oops: No rule priority > > specified" in the example he cites. So it's not true in > general that > > the PCIM makes it impossible to specify the outputs when a PEP > > processes a set of Policy Rules. This is impossible only if the > > policy administrator fails to avail him/herself of the mechanism > > included in the PCIM to guarantee predictable results. > > > > Now we could have made Priority a mandatory property for a Policy > > Rule. (This, by the way, is how I read the paragraph from RFC 2401 > > that David cites: SPD entries must be ordered, and then the > > entities that "consume" these entries must respect this ordering. > > To be analogous to David's current position, I think that RFC 2401 > > would have had to require that even if the SPD entries were *not* > > ordered, all entities that make use of them would be required to > > behave in the same way.) But given that we didn't make it > mandatory, > > we've given the policy administrator a way to say "I don't care how > > these rules are prioritized relative to each other -- however you do > > it is fine with me." If the policy administrator is uncomfortable > > with unpredictable results for a set of Policy Rules, he/she(*) can > > always specify Priority values for the rules. > > > > Regards, > > Bob > > > > (*) It doesn't even have to be the policy administrator. If a > > Policy Management Tool vendor is uneasy about unpredictable > > behavior, then the tool itself can introduce Priority values if > > the policy administrator doesn't. The PEP will then respect these > > Priority values, without knowing or caring where they came from. > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > > > Andrew Smith @raleigh.ibm.com on > > 04/13/2000 > > 06:30:37 PM > > > > Please respond to Andrew Smith > > > > Sent by: policy-owner@raleigh.ibm.com > > > > > > To: policy@raleigh.ibm.com > > cc: "'Black_David@emc.com'" > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > > > > All of the technology-specific incarnations of QoS policy > > models that are > > being worked on at IETF have had to face up to the issue of "rule > > precedence" issue sooner or later: Diffserv Model/MIB/PIBs, > > LDAP policy > > rule > > schemas, the new device QoS model from > Walter/Dave/Andrea/John, not to > > mention all the device CLIs that I've seen. And it came up > > again in the > > SNMPCONF meeting in Adelaide where a whole new crowd of > > people were seen > > and > > heard grappling with comprehending it. > > > > So, it seems to me, admittedly not ever actually having read > > the core model > > from cover to cover (I've dipped into it many times over > the years in > > attempts to work out how useful stuff is supposed to be > > derived from it), > > that this issue is *so* fundamental that it ought to be > > covered somewhere > > in > > a technology-independent fashion. It may be that I don't > > understand the > > purpose of the core model draft but it sure seems like an > > obvious place to > > give this issue some treatment - and that should include MUSTs as > > appropriate. > > > > Of course, the fact that I haven't ever felt an overwhelming need to > > dedicate a tree to printing and reading the draft properly might be > > indicative of the importance to me of fixing it. So, take > > that as another > > dissenting voice alongside David's (actually, standing behind > > him would be > > more accurate: when volunteers are called for, I won't have > > the time to > > provide the fixes). > > > > Andrew > > > > > -----Original Message----- > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > Sent: Thursday, April 13, 2000 2:25 PM > > > To: jstrassn@cisco.com; Black_David@emc.com; > Ed_Ellesson@tivoli.com; > > > policy@raleigh.ibm.com > > > Cc: johns@cisco.com; bwijnen@lucent.com; randy@psg.com > > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > ... > > > > > It is up to the WG and the chairs as the determiners of > > > "rough consensus" > > > to deal with these issues. I leave this to others on the > > > list to decide > > > whether this is important or not. > > > > > > --David > > > > **************************************************************** > > Andrew Smith tel: +1 (408) 579-2821 > > Extreme Networks fax: +1 (408) 579-3000 > > 3585 Monroe St. http://www.extremenetworks.com > > Santa Clara CA 95051-1450 em: andrew@extremenetworks.com > > **************************************************************** > > > > > > > > > > > From majordomo@raleigh.ibm.com Sat Apr 15 22:40:50 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10259 for ; Sat, 15 Apr 2000 22:40: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 WAA19886; Sat, 15 Apr 2000 22:37:30 -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 WAA35928; Sat, 15 Apr 2000 22:37:30 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61384; Sat, 15 Apr 2000 22:02:11 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21692; Sat, 15 Apr 2000 22:02:06 -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 WAA31858 for ; Sat, 15 Apr 2000 22:02:06 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA25694 for ; Sat, 15 Apr 2000 22:02:04 -0400 Received: from jstrassnlap (sj-dial-4-104.cisco.com [171.68.181.233]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id TAA14421; Sat, 15 Apr 2000 19:00:49 -0700 (PDT) Message-Id: <01b101bfa747$bcb94bc0$ecb544ab@cisco.com> From: "John Strassner" To: , "Andrew Smith" , Cc: , References: <0F31E5C394DAD311B60C00E029101A0707122D@mxclsk.isus.emc.com> Subject: Re: Core Model Last Call Issue: Execution Semantics Date: Sat, 15 Apr 2000 19:00:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit Comments inline. regards, John ----- Original Message ----- From: To: ; Cc: ; Sent: Friday, April 14, 2000 12:36 PM Subject: RE: Core Model Last Call Issue: Execution Semantics ... > Making priority mandatory is at best a step towards > addressing the problem in the small. Finishing the > job entails requiring that all priorities are > unique - the IPsec SPD does this by implicitly > associating priority with the entry > position in the linear ordering... You are comparing the operation of an algorithm with the operation of a system. This is apples and oranges. > IMHO, requiring that each rule has a unique >priority does not scale up well in the core model. I'm confused - it just seems that you just said that what you really want - making all rule priorities unique - doesn't scale. Please help me understand what you do want. As far as your approaches: > I can see two alternative approaches: > (1) Adopt the Container construct from the QoS model, > require unique priorities within each Container, and > describe how to order nested priorities (it's like > ordering words in a dictionary: albatross comes > before alpha because b comes before p). This doesn't solve your problem, because this still allows multiple objects to have the same priority. In fact, we explicitly allow this, because sometimes the semantics "Do this set of rules before this one and after that other one in whatever order is convenient" is important. > (2) Use the corresponding lexical ordering of DNs to > resolve ties that aren't resolved by priority. > Both of these approaches match the hierarchical structure > of the policy model in a fashion similar to linear search > matching the linear ordering of the IPsec SPD. Please remember that we are talking about an information model. An information model is by definition INDEPENDENT of any one particular repository. So any talk of ordered DNs is inappropriate for the core information model, and MUST ;-) be delegated to one of the schema drafts. ... > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > black_david@emc.com Cellular: +1 (978) 394-7754 > --------------------------------------------------- > > > From majordomo@raleigh.ibm.com Sun Apr 16 04:25:55 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05831 for ; Sun, 16 Apr 2000 04:25:55 -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 EAA36264; Sun, 16 Apr 2000 04:23:13 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAB31608; Sun, 16 Apr 2000 04:23:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56068; Sun, 16 Apr 2000 03:48:43 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44990; Sun, 16 Apr 2000 03:48:37 -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 DAA37698 for ; Sun, 16 Apr 2000 03:48:39 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA29722 for ; Sun, 16 Apr 2000 03:48:35 -0400 Received: from ysnir8000 (telaviv3-dhcp34.cisco.com [144.254.93.162]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id KAA02343; Sun, 16 Apr 2000 10:43:34 +0300 (IDT) From: "Yoram Snir" To: "'John Strassner'" , , "'Andrew Smith'" , Cc: Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Sun, 16 Apr 2000 09:41:54 +0200 Message-Id: <000a01bfa777$3c4dc620$a25dfe90@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <01b101bfa747$bcb94bc0$ecb544ab@cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Making the rule priority mandatory solves some of the problems although I think that uniqueness is not required. To complete the picture and have a fully consistent model 2 other things are required; 1. PolicyGroup priority. 2. Nested rules priority. Both were defined as part of the QoS Policy information model. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of John Strassner > Sent: Sunday, April 16, 2000 4:00 AM > To: Black_David@emc.com; Andrew Smith; remoore@us.ibm.com > Cc: policy@raleigh.ibm.com; Black_David@emc.com > Subject: Re: Core Model Last Call Issue: Execution Semantics > > > Comments inline. > > regards, > John > > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Friday, April 14, 2000 12:36 PM > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > ... > > > Making priority mandatory is at best a step towards > > addressing the problem in the small. Finishing the > > job entails requiring that all priorities are > > unique - the IPsec SPD does this by implicitly > > associating priority with the entry > > position in the linear ordering... > > You are comparing the operation of an algorithm with the > operation of a system. This is apples and oranges. > > > IMHO, requiring that each rule has a unique > >priority does not scale up well in the core model. > > I'm confused - it just seems that you just said that what > you really want - making all rule priorities unique - > doesn't scale. Please help me understand what you do want. > As far as your approaches: > > > I can see two alternative approaches: > > (1) Adopt the Container construct from the QoS model, > > require unique priorities within each Container, and > > describe how to order nested priorities (it's like > > ordering words in a dictionary: albatross comes > > before alpha because b comes before p). > > This doesn't solve your problem, because this still allows > multiple objects to have the same priority. In fact, we > explicitly allow this, because sometimes the semantics "Do > this set of rules before this one and after that other one > in whatever order is convenient" is important. > > > (2) Use the corresponding lexical ordering of DNs to > > resolve ties that aren't resolved by priority. > > Both of these approaches match the hierarchical structure > > of the policy model in a fashion similar to linear search > > matching the linear ordering of the IPsec SPD. > > Please remember that we are talking about an information > model. An information model is by definition INDEPENDENT of > any one particular repository. So any talk of ordered DNs is > inappropriate for the core information model, and MUST ;-) > be delegated to one of the schema drafts. > > ... > > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > black_david@emc.com Cellular: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > > > > From majordomo@raleigh.ibm.com Sun Apr 16 21:15:00 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11812 for ; Sun, 16 Apr 2000 21:15:00 -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 VAA31356; Sun, 16 Apr 2000 21:11:53 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA33508; Sun, 16 Apr 2000 21:11:58 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50326; Sun, 16 Apr 2000 20:40:06 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28806; Sun, 16 Apr 2000 20:40:03 -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 UAA33480 for ; Sun, 16 Apr 2000 20:40:04 -0400 From: Black_David@emc.com Received: from mxbh4.isus.emc.com (42s0052.isus.emc.com [168.159.208.52] (may be forged)) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA22454 for ; Sun, 16 Apr 2000 20:40:00 -0400 Received: by 42s0052.isus.emc.com with Internet Mail Service (5.5.2448.0) id <2PS8JMVH>; Sun, 16 Apr 2000 20:39:31 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A070148F7F9@mxclsk.isus.emc.com> To: jstrassn@cisco.com, Black_David@emc.com, andrew@extremenetworks.com, remoore@us.ibm.com Cc: policy@raleigh.ibm.com, Black_David@emc.com Subject: Policy Execution Semantics: New Proposal Date: Sun, 16 Apr 2000 20:39:28 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com Let me take another crack at this and see if I can come up with something that makes everyone happy. Proposal: (1) Add a new mandatory attribute to every Rule, Rule Number, a positive integer. Require that no two Rules in a policy and/or repository have the same Rule Number. Rule Number is used to determine what Rule to perform first when multiple Rules are eligible and all other means, including the Priority attributes (on Rule, Group, Container, etc.) have failed to select a single most eligible Rule. In such a case, the Rule with the larger Rule Number is performed first. (2) Rule Number is intended to be set automatically by a tool, such as a policy authoring tool. The Rule Numbers could also be assigned in cooperation with or solely by a policy repository as part of the operation of inserting each Rule into the repository. Manual/human/administrative control over policy execution should be accomplished via the various Priority attributes, not Rule Number. It is a good idea to preserve the Rule Number when a rule is modified, but there is no absolute requirement to do so. (3) Correct operation of policy clients must not depend on all policy rules having unique numbers, and policy clients should check that all retrieved rules do have unique numbers. This is of particular importance when a single client retrieves rules from more than one policy repository. (4) If a policy is resident in multiple repositories, and consistent predictable operation across the clients of those repositories is required, then the relative order of Rule Numbers should be the same in all of the repositories. Means for doing this need not be specified here, but could include adding or subtracting a fixed offset to/from all the Rule Numbers as part of the insertion operation if a set of rules retrieved from one repository conflicts with Rule Numbers already in use in another. Rationale: This is basically a brute force solution. Returning to the scenario from Minneapolis, and assuming that only one of the two rules is to be performed ... Example: Rule 1: Engineers get Bronze service. Rule 2: John gets Gold service. Fact: John is an Engineer. Oops: No rule priority specified When and where does John get Gold service? ... the answer is "All the time, and everywhere" because Rule 2 has the higher number. The fact that the answer is this simple is a good sign. The detailed rationale for the proposal is: (1) A new attribute is proposed because my attempts to use the existing Priority attribute aren't working. It is clearly intended that multiple objects be allowed to have the same Priority, therefore something else is needed. (2) My concerns about global priority not scaling were based on the use of the existing Priority attribute, which is intended to be set by the policy author. Inserting a rule into a 500+ rule policy and having to change the Priority of several hundred other rules is an example of the scaling problem. By separating the Rule Number attribute from Priority, and making it clear that Rule Number is intended to be set/generated automatically, this scaling problem is eliminated; a program has no problem changing thousands of rule numbers if that's called for. (3) This satisfies Andrew Smith's request that there be a way for a PDP to detect unresolvable conflicts when rules are downloaded. The PDP checks all the rule numbers, and complains if any two match; this seems reasonable to implement, and there are a number of ways of doing so. (4) This is a consequence of having multiple repositories An alternative that would get rid of this concern would be to use 128 bit UUIDs for Rule Numbers, as then one would have a strong guarantee that no two Rules could have the same Rule Number no matter how many repositories are involved. UUIDs would avoid the need to make Rule Numbers visible through the administrative interface for policy repositories, but 128 bits per rule seems excessive to me. What do people think of this? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Mon Apr 17 15:45:09 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08541 for ; Mon, 17 Apr 2000 15:45:07 -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 PAA22230; Mon, 17 Apr 2000 15:41: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 PAA27220; Mon, 17 Apr 2000 15:41:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41670; Mon, 17 Apr 2000 15:09:47 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37820; Mon, 17 Apr 2000 15:09:44 -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 PAA27740 for ; Mon, 17 Apr 2000 15:09:47 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA19012 for ; Mon, 17 Apr 2000 15:09:44 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <29G35NV4>; Mon, 17 Apr 2000 12:07:01 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC780@SOL> From: Andrew Smith To: "'Yoram Snir'" Cc: policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Mon, 17 Apr 2000 12:06:51 -0700 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: Andrew Smith Yoram, Yes, I'm not quite clear on why David is insisting on unique priority for each rule (I do understand his point that, if you insist on this, you need them to be automatically generated/re-generated by any UI tool). If you find 2 rules with the same priority that conflict you just flag the error (somewhere close to the UI hopefully) - that's fine I think. I think I understand "Nested rules priority" but can you explain "PolicyGroup priority" (why does that need to be a separate attribute? Maybe I should re-read the QoS PIM ...)? If these are generally applicable, rather than QoS-specific, they should be "promoted" to the core model [and if people are maintaining that priority is not needed then these need to be removed from the QoS PIM, right?] Are people disputing the need for conflict detection or are they just saying it does not need to be addressed in the information models? Andrew > -----Original Message----- > From: Yoram Snir [mailto:ysnir@cisco.com] > Sent: Sunday, April 16, 2000 12:42 AM > To: 'John Strassner'; Black_David@emc.com; 'Andrew Smith'; > remoore@us.ibm.com > Cc: policy@raleigh.ibm.com > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > Making the rule priority mandatory solves some of the > problems although I > think that uniqueness is not required. > To complete the picture and have a fully consistent model 2 > other things are > required; > 1. PolicyGroup priority. > 2. Nested rules priority. > Both were defined as part of the QoS Policy information model. > > Yoram Snir > Cisco Systems > Tel. 972-9-9700085 > Mobile 972-54-970085 > > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of John Strassner > > Sent: Sunday, April 16, 2000 4:00 AM > > To: Black_David@emc.com; Andrew Smith; remoore@us.ibm.com > > Cc: policy@raleigh.ibm.com; Black_David@emc.com > > Subject: Re: Core Model Last Call Issue: Execution Semantics > > > > > > Comments inline. > > > > regards, > > John > > > > ----- Original Message ----- > > From: > > To: ; > > Cc: ; > > Sent: Friday, April 14, 2000 12:36 PM > > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > > > ... > > > > > Making priority mandatory is at best a step towards > > > addressing the problem in the small. Finishing the > > > job entails requiring that all priorities are > > > unique - the IPsec SPD does this by implicitly > > > associating priority with the entry > > > position in the linear ordering... > > > > You are comparing the operation of an algorithm with the > > operation of a system. This is apples and oranges. > > > > > IMHO, requiring that each rule has a unique > > >priority does not scale up well in the core model. > > > > I'm confused - it just seems that you just said that what > > you really want - making all rule priorities unique - > > doesn't scale. Please help me understand what you do want. > > As far as your approaches: > > > > > I can see two alternative approaches: > > > (1) Adopt the Container construct from the QoS model, > > > require unique priorities within each Container, and > > > describe how to order nested priorities (it's like > > > ordering words in a dictionary: albatross comes > > > before alpha because b comes before p). > > > > This doesn't solve your problem, because this still allows > > multiple objects to have the same priority. In fact, we > > explicitly allow this, because sometimes the semantics "Do > > this set of rules before this one and after that other one > > in whatever order is convenient" is important. > > > > > (2) Use the corresponding lexical ordering of DNs to > > > resolve ties that aren't resolved by priority. > > > Both of these approaches match the hierarchical structure > > > of the policy model in a fashion similar to linear search > > > matching the linear ordering of the IPsec SPD. > > > > Please remember that we are talking about an information > > model. An information model is by definition INDEPENDENT of > > any one particular repository. So any talk of ordered DNs is > > inappropriate for the core information model, and MUST ;-) > > be delegated to one of the schema drafts. > > > > ... > > > > > --David > > > > > > --------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > > > black_david@emc.com Cellular: +1 (978) 394-7754 > > > --------------------------------------------------- > > > > > > > > > > > > > > > > > > From majordomo@raleigh.ibm.com Tue Apr 18 03:30:29 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28861 for ; Tue, 18 Apr 2000 03:30:29 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA27720; Tue, 18 Apr 2000 03:22:15 -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 DAA30244; Tue, 18 Apr 2000 03:22:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24844; Tue, 18 Apr 2000 02:44:48 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24970; Tue, 18 Apr 2000 02:44:40 -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 CAA24090 for ; Tue, 18 Apr 2000 02:44:46 -0400 From: Black_David@emc.com Received: from mxbh4.isus.emc.com (42s0052.isus.emc.com [168.159.208.52] (may be forged)) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA20204 for ; Tue, 18 Apr 2000 02:44:45 -0400 Received: by 42s0052.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 18 Apr 2000 02:44:14 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A070148F800@mxclsk.isus.emc.com> To: andrew@extremenetworks.com, ysnir@cisco.com Cc: policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Tue, 18 Apr 2000 02:44:11 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com > Yes, I'm not quite clear on why David is insisting on unique priority for > each rule (I do understand his point that, if you insist on this, you need > them to be automatically generated/re-generated by any UI tool). If you find > 2 rules with the same priority that conflict you just flag the error > (somewhere close to the UI hopefully) - that's fine I think. The short answer is "If only conflict detection were that simple ..." We are likely to see policies that are complex beasts consisting of parts that interact in subtle ways, complicated by administrative issues and practices. For example, the UI may only be editing a part of the policy that isn't supposed to conflict with any other part, but does due to an implementation restriction in a new device added to the network unbeknownst to this policy administrator (at least the new device addition part happens all the time ...). Another example is that a policy may only exhibit a conflict under network operating conditions that have never been seen before -- leading to policy failure when they do occur, which may be a crucial moment at which policy is most needed. Beyond that, Boolean Satisfiability is NP-Complete, and seems sufficiently similar to detecting potential policy conflicts in advance to make the latter non-trivial and potentially computationally expensive. This doesn't sound like a responsibility that ought to be imposed on every PDP and policy tool. Besides, to err is human ... including errors in the conflict detection software ... For the above reasons, among others, I am highly skeptical of any claim that all policy conflicts can be detected before the policy is put into use. The Rule Number proposal ensures that if an unanticipated conflict does occur, it is resolved in a consistent fashion across all the PDPs involved. An important consequence is that the number of possible policy failure modes is reduced, which should make the policy administrator's life simpler. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Tue Apr 18 05:05:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29465 for ; Tue, 18 Apr 2000 05:05:35 -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 EAA23348; Tue, 18 Apr 2000 04:58: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 EAA24232; Tue, 18 Apr 2000 04:57:58 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61642; Tue, 18 Apr 2000 04:22:51 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33898; Tue, 18 Apr 2000 04:22:45 -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 EAA22706 for ; Tue, 18 Apr 2000 04:22:50 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA32238 for ; Tue, 18 Apr 2000 03:31:01 -0400 Received: from ysnir8000 (telaviv3-dhcp34.cisco.com [144.254.93.162]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id KAA00988; Tue, 18 Apr 2000 10:31:18 +0300 (IDT) From: "Yoram Snir" To: "'Andrew Smith'" Cc: Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Tue, 18 Apr 2000 10:29:19 +0200 Message-Id: <002601bfa910$31be9e10$a25dfe90@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC780@SOL> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Please see inline. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > Sent: Monday, April 17, 2000 9:07 PM > To: 'Yoram Snir' > Cc: policy@raleigh.ibm.com > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > Yoram, > > Yes, I'm not quite clear on why David is insisting on unique > priority for > each rule (I do understand his point that, if you insist on > this, you need > them to be automatically generated/re-generated by any UI > tool). If you find > 2 rules with the same priority that conflict you just flag the error > (somewhere close to the UI hopefully) - that's fine I think. I think more then one rule with the same priority is OK, since any policy decision point would know exactly what to do. > > I think I understand "Nested rules priority" but can you explain > "PolicyGroup priority" (why does that need to be a separate > attribute? Maybe > I should re-read the QoS PIM ...)? If these are generally > applicable, rather > than QoS-specific, they should be "promoted" to the core model [and if > people are maintaining that priority is not needed then these > need to be > removed from the QoS PIM, right?] Maybe, the QoS PIM clearly defines a consistent model of decision making. Quating from the QoS PIM: ( I am sorry for the length of the section but it covers the whole subject and include examples that clear up the relevant issues) -------------- From the QoS PIM --------------- Section 3.2.4: "Each policy container is assigned a "match strategy", which is a name of a method to interpret the order of its rules (see section 1.2.1.5). For example, a FirstMatch strategy means that the rules will be "matched" according to ascending order of their Priority attribute. Decision strategy is explained in section 5." From majordomo@raleigh.ibm.com Tue Apr 18 14:46:42 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09821 for ; Tue, 18 Apr 2000 14:46:41 -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 OAA24970; Tue, 18 Apr 2000 14:41:46 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA34872; Tue, 18 Apr 2000 14:41:46 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21922; Tue, 18 Apr 2000 14:18:22 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21912; Tue, 18 Apr 2000 14:18:18 -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 OAA27370 for ; Tue, 18 Apr 2000 14:18:21 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34490 for ; Tue, 18 Apr 2000 14:18:18 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <29G35ZCY>; Tue, 18 Apr 2000 11:15:34 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC797@SOL> From: Andrew Smith To: policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Tue, 18 Apr 2000 11:15:27 -0700 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: Andrew Smith Right, so that section of the QoS PIM has nothing (or very little) to do with QoS: either this is a general problem (move Yoram's text to the core model) or it is not a problem (remove the text completely and save it for a rainy day when we realise we need it again). Otherwise we have 2 documents that are inconsistent and that just reflect the differing opinions of their authors, rather than an IETF rough consensus (JohnSt - your name is on both docs!). Please fix this inconsistency (this message directed at the WG, not at you Yoram). Andrew > -----Original Message----- > From: Yoram Snir [mailto:ysnir@cisco.com] > Sent: Tuesday, April 18, 2000 1:29 AM > To: 'Andrew Smith' > Cc: policy@raleigh.ibm.com > Subject: RE: Core Model Last Call Issue: Execution Semantics ... > Maybe, the QoS PIM clearly defines a consistent model of > decision making. > Quating from the QoS PIM: ( I am sorry for the length of the > section but it > covers the whole subject and include examples that clear up > the relevant > issues) > > -------------- From the QoS PIM --------------- > Section 3.2.4: > "Each policy container is assigned a "match strategy", which is a name > of a method to interpret the order of its rules (see section 1.2.1.5). > For example, a FirstMatch strategy means that the rules will be > "matched" according to ascending order of their Priority attribute. > Decision strategy is explained in section 5." > From majordomo@raleigh.ibm.com Tue Apr 18 14:48:29 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09913 for ; Tue, 18 Apr 2000 14:48:28 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA22410; Tue, 18 Apr 2000 14:41:47 -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 OAA26184; Tue, 18 Apr 2000 14:41:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07996; Tue, 18 Apr 2000 14:09:22 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21812; Tue, 18 Apr 2000 14:09: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 OAA36964 for ; Tue, 18 Apr 2000 14:09:21 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34868 for ; Tue, 18 Apr 2000 14:09:19 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id <29G35Y0M>; Tue, 18 Apr 2000 11:06:36 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC795@SOL> From: Andrew Smith To: "'Black_David@emc.com'" Cc: policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Tue, 18 Apr 2000 11:06:36 -0700 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: Andrew Smith Agreed: as we've discussed before on this list, you need conflict detection at *all* levels/places in the system and you should try to check as much as possible as high up as possible in the architecture: of course there are conflicts that cannot be detected until you get down to the device level but there a lot that can be and that doesn't make the presence of a "precedence" any less useful. For your example, an accurate reporting of device capabilities is an important part of being able to do conflict detection in the PDP, rather than waiting until "run-time". In my previous message, I was only talking about that point in the architecture between the UI and the PDP/PEP boundary. Andrew > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, April 17, 2000 11:44 PM > To: andrew@extremenetworks.com; ysnir@cisco.com > Cc: policy@raleigh.ibm.com > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > Yes, I'm not quite clear on why David is insisting on > unique priority for > > each rule (I do understand his point that, if you insist on > this, you need > > them to be automatically generated/re-generated by any UI > tool). If you > find > > 2 rules with the same priority that conflict you just flag the error > > (somewhere close to the UI hopefully) - that's fine I think. > > The short answer is "If only conflict detection were that simple ..." > We are likely to see policies that are complex beasts consisting > of parts that interact in subtle ways, complicated by administrative > issues and practices. > > For example, the UI may only be editing a part of the policy that > isn't supposed to conflict with any other part, but does due to > an implementation restriction in a new device added to the network > unbeknownst to this policy administrator (at least the new > device addition part happens all the time ...). Another example > is that a policy may only exhibit a conflict under network > operating conditions that have never been seen before -- > leading to policy failure when they do occur, which may > be a crucial moment at which policy is most needed. > > Beyond that, Boolean Satisfiability is NP-Complete, and seems > sufficiently similar to detecting potential policy conflicts > in advance > to make the latter non-trivial and potentially > computationally expensive. > This doesn't sound like a responsibility that ought to be imposed > on every PDP and policy tool. Besides, to err is human ... > including errors in the conflict detection software ... > > For the above reasons, among others, I am highly skeptical of any > claim that all policy conflicts can be detected before the policy > is put into use. The Rule Number proposal ensures that if > an unanticipated conflict does occur, it is resolved in a consistent > fashion across all the PDPs involved. An important > consequence is that the number of possible policy failure > modes is reduced, which should make the policy > administrator's life simpler. > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 > black_david@emc.com Cellular: +1 (978) 394-7754 > --------------------------------------------------- > From majordomo@raleigh.ibm.com Wed Apr 19 02:36:41 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01122 for ; Wed, 19 Apr 2000 02:36:40 -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 CAA17256; Wed, 19 Apr 2000 02:27:15 -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 CAA34144; Wed, 19 Apr 2000 02:27:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60166; Wed, 19 Apr 2000 01:57:39 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52478; Wed, 19 Apr 2000 01:57:36 -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 BAA30638 for ; Wed, 19 Apr 2000 01:57:42 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA21858 for ; Wed, 19 Apr 2000 01:57:39 -0400 Received: from jstrassnlap (sj-dial-1-53.cisco.com [171.68.179.54]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id WAA03479; Tue, 18 Apr 2000 22:57:06 -0700 (PDT) Message-Id: <015d01bfa9c4$3ea1d2a0$36b344ab@cisco.com> From: "John Strassner" To: "Andrew Smith" , References: <808F64DDB492D3119D3C00508B5D8D733EC797@SOL> Subject: Re: Core Model Last Call Issue: Execution Semantics Date: Tue, 18 Apr 2000 22:58:09 -0700 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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit Hi Andrew, it actually is NOT inconsistent at all. The WG had decided that for the generic policy case, they did NOT want these additional semantics. In fact, some people wanted the ability to say "evaluate this (third) set of policy rules after this (first) set before this other (second) set." So the PCIM strove to be as general as possible. This was NOT suitable for the application-specific constraints of QoS Policies, so we added this information in the QoS PIM. regards, John ----- Original Message ----- From: "Andrew Smith" To: Sent: Tuesday, April 18, 2000 11:15 AM Subject: RE: Core Model Last Call Issue: Execution Semantics > Right, so that section of the QoS PIM has nothing (or very little) to do > with QoS: either this is a general problem (move Yoram's text to the core > model) or it is not a problem (remove the text completely and save it for a > rainy day when we realise we need it again). Otherwise we have 2 documents > that are inconsistent and that just reflect the differing opinions of their > authors, rather than an IETF rough consensus (JohnSt - your name is on both > docs!). > > Please fix this inconsistency (this message directed at the WG, not at you > Yoram). > > Andrew > > > -----Original Message----- > > From: Yoram Snir [mailto:ysnir@cisco.com] > > Sent: Tuesday, April 18, 2000 1:29 AM > > To: 'Andrew Smith' > > Cc: policy@raleigh.ibm.com > > Subject: RE: Core Model Last Call Issue: Execution Semantics > ... > > Maybe, the QoS PIM clearly defines a consistent model of > > decision making. > > Quating from the QoS PIM: ( I am sorry for the length of the > > section but it > > covers the whole subject and include examples that clear up > > the relevant > > issues) > > > > -------------- From the QoS PIM --------------- > > Section 3.2.4: > > "Each policy container is assigned a "match strategy", which is a name > > of a method to interpret the order of its rules (see section 1.2.1.5). > > For example, a FirstMatch strategy means that the rules will be > > "matched" according to ascending order of their Priority attribute. > > Decision strategy is explained in section 5." > > > > From majordomo@raleigh.ibm.com Mon Apr 24 07:47:33 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00719 for ; Mon, 24 Apr 2000 07:47:33 -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 HAA21802; Mon, 24 Apr 2000 07:43: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 HAA28320; Mon, 24 Apr 2000 07:43:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24902; Mon, 24 Apr 2000 07:12:33 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40766; Mon, 24 Apr 2000 07:12:30 -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 HAA28276 for ; Mon, 24 Apr 2000 07:12:30 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA24564 for ; Mon, 24 Apr 2000 07:12:28 -0400 Received: from ysnir8000 (telaviv3-dhcp73.cisco.com [144.254.93.201]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id OAA00941; Mon, 24 Apr 2000 14:13:08 +0300 (IDT) From: "Yoram Snir" To: "'John Strassner'" , "'Andrew Smith'" , Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Mon, 24 Apr 2000 14:10:48 +0200 Message-Id: <001a01bfade6$21839ca0$c95dfe90@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <015d01bfa9c4$3ea1d2a0$36b344ab@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit I tend to agree with John on this. The current situation is not inconsistent. There is no inconsistency between the PCIM and the QOSIM. The generality of the PCIM has strengths and weaknesses and it is up to specific domains to extend it to cover for these weaknesses, as the QOSIM has done. In order to preserve the applicability of PCIM to different domains we should not restrict it but keep it general. IMO, the PCIM should be an RFC as soon as possible in its current state. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of John Strassner > Sent: Wednesday, April 19, 2000 7:58 AM > To: Andrew Smith; policy@raleigh.ibm.com > Subject: Re: Core Model Last Call Issue: Execution Semantics > > > Hi Andrew, > > it actually is NOT inconsistent at all. The WG had decided > that for the generic policy case, they did NOT want these > additional semantics. In fact, some people wanted the > ability to say "evaluate this (third) set of policy rules > after this (first) set before this other (second) set." > > So the PCIM strove to be as general as possible. This was > NOT suitable for the application-specific constraints of QoS > Policies, so we added this information in the QoS PIM. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: > Sent: Tuesday, April 18, 2000 11:15 AM > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > Right, so that section of the QoS PIM has nothing (or very > little) to do > > with QoS: either this is a general problem (move Yoram's > text to the core > > model) or it is not a problem (remove the text completely > and save it for a > > rainy day when we realise we need it again). Otherwise we > have 2 documents > > that are inconsistent and that just reflect the differing > opinions of their > > authors, rather than an IETF rough consensus (JohnSt - > your name is on both > > docs!). > > > > Please fix this inconsistency (this message directed at > the WG, not at you > > Yoram). > > > > Andrew > > > > > -----Original Message----- > > > From: Yoram Snir [mailto:ysnir@cisco.com] > > > Sent: Tuesday, April 18, 2000 1:29 AM > > > To: 'Andrew Smith' > > > Cc: policy@raleigh.ibm.com > > > Subject: RE: Core Model Last Call Issue: Execution > Semantics > > ... > > > Maybe, the QoS PIM clearly defines a consistent model of > > > decision making. > > > Quating from the QoS PIM: ( I am sorry for the length of > the > > > section but it > > > covers the whole subject and include examples that clear > up > > > the relevant > > > issues) > > > > > > -------------- From the QoS PIM --------------- > > > Section 3.2.4: > > > "Each policy container is assigned a "match strategy", > which is a name > > > of a method to interpret the order of its rules (see > section 1.2.1.5). > > > For example, a FirstMatch strategy means that the rules > will be > > > "matched" according to ascending order of their Priority > attribute. > > > Decision strategy is explained in section 5." > > > > > > > > > > From majordomo@raleigh.ibm.com Tue Apr 25 06:24:44 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07812 for ; Tue, 25 Apr 2000 06:24:43 -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 GAA25166; Tue, 25 Apr 2000 06:21: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 GAA28340; Tue, 25 Apr 2000 06:21:45 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44786; Tue, 25 Apr 2000 05:48:14 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45034; Tue, 25 Apr 2000 05:48:11 -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 FAA03792 for ; Tue, 25 Apr 2000 05:48:12 -0400 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA21642 for ; Tue, 25 Apr 2000 05:48:08 -0400 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.22 2000/04/06 17:58:51 dmccart Exp $) with SMTP id JAA16291; Tue, 25 Apr 2000 09:48:46 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 25 Apr 2000 09:47:59 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Apr 2000 02:47:57 -0700 Message-Id: From: "Jensen, Kell Michael" To: "'Black_David@emc.com'" , jstrassn@cisco.com, andrew@extremenetworks.com, remoore@us.ibm.com Cc: policy@raleigh.ibm.com Subject: RE: Policy Execution Semantics: New Proposal Date: Tue, 25 Apr 2000 02:47:50 -0700 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jensen, Kell Michael" I think it would be an easy way to solve some of the unambigous issue raised before. However we need a method to change Rule Number, if we want to swap the order of a set of rules, and doesn't have any free rule Number in the area. Do we then still need the priority attribute? /Kell Michael -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: 17. april 2000 02:39 To: jstrassn@cisco.com; Black_David@emc.com; andrew@extremenetworks.com; remoore@us.ibm.com Cc: policy@raleigh.ibm.com; Black_David@emc.com Subject: Policy Execution Semantics: New Proposal Let me take another crack at this and see if I can come up with something that makes everyone happy. Proposal: (1) Add a new mandatory attribute to every Rule, Rule Number, a positive integer. Require that no two Rules in a policy and/or repository have the same Rule Number. Rule Number is used to determine what Rule to perform first when multiple Rules are eligible and all other means, including the Priority attributes (on Rule, Group, Container, etc.) have failed to select a single most eligible Rule. In such a case, the Rule with the larger Rule Number is performed first. (2) Rule Number is intended to be set automatically by a tool, such as a policy authoring tool. The Rule Numbers could also be assigned in cooperation with or solely by a policy repository as part of the operation of inserting each Rule into the repository. Manual/human/administrative control over policy execution should be accomplished via the various Priority attributes, not Rule Number. It is a good idea to preserve the Rule Number when a rule is modified, but there is no absolute requirement to do so. (3) Correct operation of policy clients must not depend on all policy rules having unique numbers, and policy clients should check that all retrieved rules do have unique numbers. This is of particular importance when a single client retrieves rules from more than one policy repository. (4) If a policy is resident in multiple repositories, and consistent predictable operation across the clients of those repositories is required, then the relative order of Rule Numbers should be the same in all of the repositories. Means for doing this need not be specified here, but could include adding or subtracting a fixed offset to/from all the Rule Numbers as part of the insertion operation if a set of rules retrieved from one repository conflicts with Rule Numbers already in use in another. Rationale: This is basically a brute force solution. Returning to the scenario from Minneapolis, and assuming that only one of the two rules is to be performed ... Example: Rule 1: Engineers get Bronze service. Rule 2: John gets Gold service. Fact: John is an Engineer. Oops: No rule priority specified When and where does John get Gold service? ... the answer is "All the time, and everywhere" because Rule 2 has the higher number. The fact that the answer is this simple is a good sign. The detailed rationale for the proposal is: (1) A new attribute is proposed because my attempts to use the existing Priority attribute aren't working. It is clearly intended that multiple objects be allowed to have the same Priority, therefore something else is needed. (2) My concerns about global priority not scaling were based on the use of the existing Priority attribute, which is intended to be set by the policy author. Inserting a rule into a 500+ rule policy and having to change the Priority of several hundred other rules is an example of the scaling problem. By separating the Rule Number attribute from Priority, and making it clear that Rule Number is intended to be set/generated automatically, this scaling problem is eliminated; a program has no problem changing thousands of rule numbers if that's called for. (3) This satisfies Andrew Smith's request that there be a way for a PDP to detect unresolvable conflicts when rules are downloaded. The PDP checks all the rule numbers, and complains if any two match; this seems reasonable to implement, and there are a number of ways of doing so. (4) This is a consequence of having multiple repositories An alternative that would get rid of this concern would be to use 128 bit UUIDs for Rule Numbers, as then one would have a strong guarantee that no two Rules could have the same Rule Number no matter how many repositories are involved. UUIDs would avoid the need to make Rule Numbers visible through the administrative interface for policy repositories, but 128 bits per rule seems excessive to me. What do people think of this? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Tue Apr 25 09:24:00 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11992 for ; Tue, 25 Apr 2000 09:23:59 -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 JAA26380; Tue, 25 Apr 2000 09:20:39 -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 JAA29120; Tue, 25 Apr 2000 09:20:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53864; Tue, 25 Apr 2000 08:52:56 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40028; Tue, 25 Apr 2000 08:52:53 -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 IAA34702 for ; Tue, 25 Apr 2000 08:52:56 -0400 From: Black_David@emc.com Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [168.159.208.81]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA16036 for ; Tue, 25 Apr 2000 08:52:52 -0400 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Apr 2000 08:52:23 -0400 Message-Id: <0F31E5C394DAD311B60C00E029101A070148F821@mxclsk.isus.emc.com> To: kell.michael.jensen@intel.com, Black_David@emc.com, jstrassn@cisco.com, andrew@extremenetworks.com, remoore@us.ibm.com Cc: policy@raleigh.ibm.com Subject: RE: Policy Execution Semantics: New Proposal Date: Tue, 25 Apr 2000 08:52:21 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Black_David@emc.com > I think it would be an easy way to solve some of the unambigous issue > raised before. > > However we need a method to change Rule Number, if we want to swap the order > of a set of rules, and doesn't have any free rule Number in the area. > > Do we then still need the priority attribute? The intention is to retain Priority for this purpose -- i.e., Rule Number provides a default ordering, and if someone doesn't like it, Priority can be set to achieve the desired order. There's nothing to stop a tool/administrator from setting Rule Number, but Priority is likely to provide more effective means - for the specific example of swapping the order of a set of rules, there may be a single rule group Priority or rule container Priority that does the job. Relying solely on Rule Number for all rule ordering makes it harder to have a tool automatically renumber the rules when a new one is inserted in the middle --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From majordomo@raleigh.ibm.com Tue Apr 25 18:20:09 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27604 for ; Tue, 25 Apr 2000 18:20:08 -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 SAA24892; Tue, 25 Apr 2000 18:17:13 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA28256; Tue, 25 Apr 2000 18:17:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57552; Tue, 25 Apr 2000 17:52:38 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44476; Tue, 25 Apr 2000 17:52:30 -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 RAA26200 for ; Tue, 25 Apr 2000 17:52:35 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA36472 for ; Tue, 25 Apr 2000 17:52:29 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA09752; Tue, 25 Apr 2000 17:51:33 -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 RAA10210; Tue, 25 Apr 2000 17:51:32 -0400 (EDT) Message-Id: <200004252151.RAA10210@monday.research.telcordia.com> Date: Tue, 25 Apr 2000 17:51:32 -0400 (EDT) From: Ritu Chadha Subject: qosPolicyMeter?? To: policy@raleigh.ibm.com Cc: chadha@mailee.research.telcordia.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: Q/+ERyx8CL56dJykBE85jQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha The class qosPolicyMeter is referred to in both the QoS Policy Schema and the Policy Framework QoS Information Model drafts, but is not defined in either of these drafts. Where can I find the definition of qosPolicyMeter? Thanks Ritu ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Wed Apr 26 04:47:56 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21761 for ; Wed, 26 Apr 2000 04:47:56 -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 EAA22894; Wed, 26 Apr 2000 04:45: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 EAA31814; Wed, 26 Apr 2000 04:45:11 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28518; Wed, 26 Apr 2000 04:14:41 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42512; Wed, 26 Apr 2000 04:14:32 -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 EAA28296 for ; Wed, 26 Apr 2000 04:14:34 -0400 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA24096 for ; Wed, 26 Apr 2000 04:14:31 -0400 Received: from jstrassnlap (stockley12-dhcp200.cisco.com [144.254.98.209]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id BAA15378; Wed, 26 Apr 2000 01:10:37 -0700 (PDT) Message-Id: <01eb01bfaf57$101c02f0$d162fe90@cisco.com> From: "John Strassner" To: "Ritu Chadha" , Cc: References: <200004252151.RAA10210@monday.research.telcordia.com> Subject: Re: qosPolicyMeter?? Date: Wed, 26 Apr 2000 01:11:43 -0700 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.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John Strassner" Content-Transfer-Encoding: 7bit This is being fixed in the next release of both drafts. They are in final edit and will be available either later this week or early next week at the very latest. regards, John ----- Original Message ----- From: "Ritu Chadha" To: Cc: Sent: Tuesday, April 25, 2000 2:51 PM Subject: qosPolicyMeter?? > The class qosPolicyMeter is referred to in both the QoS Policy Schema > and the Policy Framework QoS Information Model drafts, but is not > defined in either of these drafts. Where can I find the definition > of qosPolicyMeter? > > Thanks > Ritu > ============================================================ ================= > Ritu Chadha > Senior Scientist > Telcordia Technologies (973) 829-4869 (voice) > MCC 1J-218R (973) 829-5889 (fax) > 445 South Street chadha@research.telcordia.com > Morristown NJ 07960. > ============================================================ ================= > > > From majordomo@raleigh.ibm.com Wed Apr 26 14:34:23 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02004 for ; Wed, 26 Apr 2000 14:34:23 -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 OAA38854; Wed, 26 Apr 2000 14:30:54 -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 OAA24448; Wed, 26 Apr 2000 14:30:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38136; Wed, 26 Apr 2000 14:05:28 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46572; Wed, 26 Apr 2000 14:05:24 -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 OAA27300 for ; Wed, 26 Apr 2000 14:05:24 -0400 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA31228 for ; Wed, 26 Apr 2000 14:05:21 -0400 Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Apr 2000 11:02:27 -0700 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC7DC@SOL> From: Andrew Smith To: "'John Strassner'" , policy@raleigh.ibm.com Subject: RE: Core Model Last Call Issue: Execution Semantics Date: Wed, 26 Apr 2000 11:02:26 -0700 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: Andrew Smith That still sounds like an inconsistency in the thought-processes of the WG to me. But I guess nobody else is interested in fixing it so let's let sleeping policy-dogs lie. Andrew > -----Original Message----- > From: John Strassner [mailto:jstrassn@cisco.com] > Sent: Tuesday, April 18, 2000 10:58 PM > To: Andrew Smith; policy@raleigh.ibm.com > Subject: Re: Core Model Last Call Issue: Execution Semantics > > > Hi Andrew, > > it actually is NOT inconsistent at all. The WG had decided > that for the generic policy case, they did NOT want these > additional semantics. In fact, some people wanted the > ability to say "evaluate this (third) set of policy rules > after this (first) set before this other (second) set." > > So the PCIM strove to be as general as possible. This was > NOT suitable for the application-specific constraints of QoS > Policies, so we added this information in the QoS PIM. > > regards, > John > ----- Original Message ----- > From: "Andrew Smith" > To: > Sent: Tuesday, April 18, 2000 11:15 AM > Subject: RE: Core Model Last Call Issue: Execution Semantics > > > > Right, so that section of the QoS PIM has nothing (or very > little) to do > > with QoS: either this is a general problem (move Yoram's > text to the core > > model) or it is not a problem (remove the text completely > and save it for a > > rainy day when we realise we need it again). Otherwise we > have 2 documents > > that are inconsistent and that just reflect the differing > opinions of their > > authors, rather than an IETF rough consensus (JohnSt - > your name is on both > > docs!). > > > > Please fix this inconsistency (this message directed at > the WG, not at you > > Yoram). > > > > Andrew > > > > > -----Original Message----- > > > From: Yoram Snir [mailto:ysnir@cisco.com] > > > Sent: Tuesday, April 18, 2000 1:29 AM > > > To: 'Andrew Smith' > > > Cc: policy@raleigh.ibm.com > > > Subject: RE: Core Model Last Call Issue: Execution > Semantics > > ... > > > Maybe, the QoS PIM clearly defines a consistent model of > > > decision making. > > > Quating from the QoS PIM: ( I am sorry for the length of > the > > > section but it > > > covers the whole subject and include examples that clear > up > > > the relevant > > > issues) > > > > > > -------------- From the QoS PIM --------------- > > > Section 3.2.4: > > > "Each policy container is assigned a "match strategy", > which is a name > > > of a method to interpret the order of its rules (see > section 1.2.1.5). > > > For example, a FirstMatch strategy means that the rules > will be > > > "matched" according to ascending order of their Priority > attribute. > > > Decision strategy is explained in section 5." > > > > > > > > From majordomo@raleigh.ibm.com Thu Apr 27 09:49:46 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28852 for ; Thu, 27 Apr 2000 09:49:45 -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 JAA28116; Thu, 27 Apr 2000 09:43:46 -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 JAA21556; Thu, 27 Apr 2000 09:43:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50596; Thu, 27 Apr 2000 09:15:55 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54940; Thu, 27 Apr 2000 09:15:52 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA27334 for ; Thu, 27 Apr 2000 09:15:57 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id IAA05631; Thu, 27 Apr 2000 08:14:45 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568CE.0048E954 ; Thu, 27 Apr 2000 08:16:23 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: "Wijnen, Bert (Bert)" , Randy Bush Cc: iesg-secretary@ietf.org, policy@raleigh.ibm.com, John Strassner Message-Id: <862568CE.0048E7D8.00@tivmta4.tivoli.com> Date: Thu, 27 Apr 2000 09:10:04 -0400 Subject: Please Consider for PS: draft-ietf-policy-core-info-model-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Dear AD's, We request that you forward the subject document to the IESG for consideration as Proposed Standard. The last call on the subject draft is now closed. After careful consideration of the last call discussion on the mailing list, we, the working group chairs, believe we have rough consensus for moving the subject draft forward to the IESG for consideration as an IETF Proposed Standard RFC. Thank you, and thanks to all the people who contributed to the working group discussions, and especially to those who edited, contributed to, and wrote sections of the document. Ed Ellesson and John Strassner, co-chairs, policy framework working group From majordomo@raleigh.ibm.com Thu Apr 27 12:31:45 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03444 for ; Thu, 27 Apr 2000 12:31:44 -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 MAA24568; Thu, 27 Apr 2000 12:27: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 MAA34008; Thu, 27 Apr 2000 12:27:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54808; Thu, 27 Apr 2000 12:05:26 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42746; Thu, 27 Apr 2000 12:05:20 -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 MAA30292 for ; Thu, 27 Apr 2000 12:05:26 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA29668 for ; Thu, 27 Apr 2000 12:05:22 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA15295 for ; Thu, 27 Apr 2000 12:05:16 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA15267 for ; Thu, 27 Apr 2000 12:05:15 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Apr 2000 18:05:14 +0200 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB06F741CE@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Bush , Ed Ellesson Cc: iesg-secretary , Policy Mailing List , John Strassner Subject: RE: Please Consider for PS: draft-ietf-policy-core-info-model-05 .txt Date: Thu, 27 Apr 2000 18:05:13 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Ack, it is on my plate now Bert