From majordomo@raleigh.ibm.com Mon Jun 5 18:12:59 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 SAA11603 for ; Mon, 5 Jun 2000 18:12:59 -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 SAA20730; Mon, 5 Jun 2000 18:09:25 -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 SAA12544; Mon, 5 Jun 2000 18:09:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37832; Mon, 5 Jun 2000 17:42:27 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29886; Mon, 5 Jun 2000 17:42:23 -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 RAA28498 for ; Mon, 5 Jun 2000 17:42:26 -0400 From: Man.M.Li@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA23686 for ; Mon, 5 Jun 2000 17:42:22 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id AAA27271; Tue, 6 Jun 2000 00:42:22 +0300 (EETDST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id AAA02505; Tue, 6 Jun 2000 00:42:21 +0300 (EETDST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 16:42:19 -0500 Message-Id: To: diffserv@ietf.org, policy@raleigh.ibm.com Subject: policy time period condition Date: Mon, 5 Jun 2000 16:38:26 -0500 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: Man.M.Li@nokia.com The draft-ietf-diffserv-pib-00.txt does not seem to contain policy time period condition as specified in PCIM. Is there a reason to leave it out? How can a PDP push a set of policies and mandate that they should be active only between 9 a.m. to 5 p.m. daily? Man Li Nokia Internet Communications 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 From majordomo@raleigh.ibm.com Tue Jun 6 04:19:41 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 EAA29779 for ; Tue, 6 Jun 2000 04:19:41 -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 EAA32722; Tue, 6 Jun 2000 04:16:19 -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 EAA31634; Tue, 6 Jun 2000 04:16:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43646; Tue, 6 Jun 2000 03:50:19 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28122; Tue, 6 Jun 2000 03:50:05 -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 DAA15120 for ; Tue, 6 Jun 2000 03:50:13 -0400 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA25096 for ; Tue, 6 Jun 2000 03:50:10 -0400 Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id AAA29231; Tue, 6 Jun 2000 00:49:38 -0700 (PDT) From: Keith McCloghrie Message-Id: <200006060749.AAA29231@foxhound.cisco.com> Subject: Re: policy time period condition To: Man.M.Li@nokia.com Date: Tue, 6 Jun 2000 00:49:37 -0700 (PDT) Cc: diffserv@ietf.org, policy@raleigh.ibm.com In-Reply-To: from "Man.M.Li@nokia.com" at Jun 05, 2000 04:38:26 PM X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Keith McCloghrie Content-Transfer-Encoding: 7bit > The draft-ietf-diffserv-pib-00.txt does not seem to contain policy time > period condition as specified in PCIM. Is there a reason to leave it out? If there were only 9am-5pm policies, then it wouldn't too bad. However, when a time period is independently specified for each policy, such that different policies have different periods with many overlapping periods, then conflict detection becomes quite complicated. > How can a PDP push a set of policies and mandate that they should be active > only between 9 a.m. to 5 p.m. daily? The PDP installs them at 9am every day, and replaces them with other policies at 5pm every day. Through the use of "contexts" (see section 3.2 in draft-ietf-rap-frameworkpib-00.txt), both sets of policies can be loaded into the PEP, and the PDP only needs to instruct the PEP to switch contexts at the relevant times. Keith. From majordomo@raleigh.ibm.com Fri Jun 9 12:32: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 MAA14627 for ; Fri, 9 Jun 2000 12:32:54 -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 MAA27360; Fri, 9 Jun 2000 12:29:25 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA24102; Fri, 9 Jun 2000 12:29:21 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55188; Fri, 9 Jun 2000 12:04:14 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55164; Fri, 9 Jun 2000 12:04:08 -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 MAA31418 for ; Fri, 9 Jun 2000 12:04:11 -0400 From: p.arbiol@teleline.es Received: from tsmtp3.ldap.isp (mailhost.teleline.es [195.235.113.141] (may be forged)) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA11928 for ; Fri, 9 Jun 2000 12:04:10 -0400 Message-Id: <200006091604.MAA11928@fwns2.raleigh.ibm.com> Received: from mailhost.teleline.es ([193.153.160.212]) by tsmtp3.ldap.isp (Netscape Messaging Server 4.1) with SMTP id FVW9U100.TDF for ; Fri, 9 Jun 2000 18:01:13 +0200 To: policy@raleigh.ibm.com Date: Fri, 9 Jun 2000 18:08:12 +0200 Subject: Negligencias medicas X-Mailer: mailhost.teleline.es Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: p.arbiol@teleline.es Para conseguir en un futuro próximo que disminuyan las negligencias y errores médico-sanitarios y mejorar la Sanidad puede aportar sus experiencias o conocimientos a http://www.negligencias.com NEGLIGENCIAS.COM - EL BUSCADOR From majordomo@raleigh.ibm.com Wed Jun 14 12:22:47 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 MAA26987 for ; Wed, 14 Jun 2000 12:22:46 -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 MAA21624; Wed, 14 Jun 2000 12:17:53 -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 MAA35470; Wed, 14 Jun 2000 12:17:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47592; Wed, 14 Jun 2000 11:38:26 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44734; Wed, 14 Jun 2000 11:38:18 -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 LAA30912 for ; Wed, 14 Jun 2000 11:38:21 -0400 Received: from bmailnj.iphighway.com ([63.89.157.130]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA26620 for ; Wed, 14 Jun 2000 11:38:16 -0400 Received: from brmnj-fw (63.89.157.129 [63.89.157.129]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L1GT5RGM; Wed, 14 Jun 2000 11:33:43 -0400 Message-Id: <4.3.1.2.20000614113749.00b8e238@bmailnj.brm.com> X-Sender: herzog@bmailnj.brm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 14 Jun 2000 11:37:58 -0400 To: policy@raleigh.ibm.com From: Shai Herzog Subject: COPS-PR (open) source code Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Shai Herzog Dear rappers and policy aficionados, As some of you asked for COPS source code availability I'd like to draw your attention to a new development. Due to "public pressure" we at IPHighway decided to make our COPS-PR *client* code available to the public on an open source basis. This commercial grade code was previously available only on a commercial basis, but can now be freely loaded from our web site (www.iphighway.com). In addition to the source code, you can also join a special mailing list for discussions, Q&A etc., regarding the code. As the COPS-PR standard evolve (and hopefully not too much more before it goes RFC) we'll be upgrading the code (although we cannot guarantee the pace of upgrades ;-) If you'd like to test this code against a true policy server, please note that this code is fully compatible with the IPHighway Open Policy System (OPS) 2.0 and the soon to be available OPS 3.0 beta. Enjoy Shai P.S., I am *NOT* the right person to ask about details of the code. If you have any technical questions please follow the procedure described in the web site. Also (with the exception of this announcement) please note that the public rap mailing list (rap@iphighway.com) shouldn't be used for such questions either. From majordomo@raleigh.ibm.com Wed Jun 14 13:25:11 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 NAA28960 for ; Wed, 14 Jun 2000 13:25:10 -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 NAA28382; Wed, 14 Jun 2000 13:20:21 -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 NAA32706; Wed, 14 Jun 2000 13:20:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43112; Wed, 14 Jun 2000 12:47:13 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41818; Wed, 14 Jun 2000 12:47:08 -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 MAA27124 for ; Wed, 14 Jun 2000 12:47:09 -0400 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA30002 for ; Wed, 14 Jun 2000 12:47:05 -0400 Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id JAA12001; Wed, 14 Jun 2000 09:46:52 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 14 Jun 2000 16:46:52 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 09:46:50 -0700 Message-Id: <4A043A1FE4B2D111AC3F00A0C96B5133048410C2@fmsmsx37.fm.intel.com> From: "Fenger, Russell J" To: rap@iphighway.com, rsvp@ISI.EDU, policy@raleigh.ibm.com Subject: Intel COPS Client SDK Date: Wed, 14 Jun 2000 09:46:47 -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: "Fenger, Russell J" The Intel COPS Client SDK is available under an open source distribution license. The first version provides support for COPS-RSVP extensions and was designed to allow support for additional COPS extensions in the future. Support for COPS-PR will be available after the next interop. The SDK was also designed to be portable to any environment by simply creating an environment-specific portability layer usable by the other layers of the SDK. A fully functional Win32 portability layer is provided for reference. Other portability layers are under development. The SDK also includes a COPS-RSVP server simulator binary for test purposes. The SDK is available at http://www.intel.com/ial/cops/. Russ From majordomo@raleigh.ibm.com Fri Jun 16 07:10:53 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 HAA08848 for ; Fri, 16 Jun 2000 07:10:52 -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 HAA27534; Fri, 16 Jun 2000 07:05:03 -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 HAA23448; Fri, 16 Jun 2000 07:05:04 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48314; Fri, 16 Jun 2000 06:36:25 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57266; Fri, 16 Jun 2000 06:36:22 -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 GAA30650 for ; Fri, 16 Jun 2000 06:36:25 -0400 Received: from mailboy.huawei.com.cn ([202.96.135.134]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA30904 for ; Fri, 16 Jun 2000 06:36:01 -0400 Received: from yuanwei17592 ([10.108.26.140]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA18395 for ; Fri, 16 Jun 2000 18:27:05 +0800 Message-Id: <000001bfd7c1$74fd98e0$8c1a6c0a@huawei.com.cn> From: "yuan wei" To: Subject: about Policy Based VPN Management Date: Fri, 16 Jun 2000 09:20:11 -0000 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01BFD774.12AEFFA0" 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: "yuan wei" This is a multi-part message in MIME format. ------=_NextPart_000_001D_01BFD774.12AEFFA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCiAgRG9lcyBhbnlvbmUgaGFzIHRoZSByZWZlcmVuY2VzIG9mIFBvbGljeSBCYXNlZCBW UE4gDQpNYW5hZ2VtZW50PyBJdCBzZWVtcyB0aGF0IHRoZSBjdXJyZW50IHdvcmsgb2YgIFBvbGlj eSBXRw0KaXMgbGltaXRlZCB0byBRb3MgUG9saWN5LiBJdCBpcyBzYWlkIHRoZSB0aGUgcm9hZG1h cCBvZg0KSFAgcG9saWN5WHBlcnQgaW5jbHVkZSB0aGUgVlBOLiBCdXQgd2hlcmUgY2FuIGkgZm91 bmQNCm1vcmUgZGV0YWlscy4NCg0KICBUaGFua3MgaW4gYWR2YW5jZS4NCg0KQmVzdCBSZWdhcmRz LA0KeXVhbiB3ZWkNCkVtYWlsOiB5dWFud2VpQHN6Lmh1YXdlaS5jb20uY24NCg0K ------=_NextPart_000_001D_01BFD774.12AEFFA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSw8L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7IERvZXMgYW55b25l IGhhcyB0aGUgcmVmZXJlbmNlcyBvZiBQb2xpY3kgQmFzZWQgVlBOIA0KPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+TWFuYWdlbWVudD8gSXQgc2VlbXMgdGhhdCB0aGUgY3VycmVudCB3 b3JrIG9mICBQb2xpY3kgDQpXRzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmlzIGxp bWl0ZWQgdG8gUW9zIFBvbGljeS4gSXQgaXMgc2FpZCB0aGUgdGhlIHJvYWRtYXAgDQpvZjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhQIHBvbGljeVhwZXJ0IGluY2x1ZGUgdGhlIFZQ Ti4gQnV0IHdoZXJlIGNhbiBpIA0KZm91bmQ8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5tb3JlIGRldGFpbHMuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPiZuYnNwOyBUaGFua3MgaW4gYWR2YW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPnl1YW4gd2VpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+RW1haWw6IDxBIA0KaHJlZj0ibWFpbHRvOnl1YW53ZWlAc3ouaHVhd2VpLmNvbS5jbiI+eXVh bndlaUBzei5odWF3ZWkuY29tLmNuPC9BPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_001D_01BFD774.12AEFFA0-- From majordomo@raleigh.ibm.com Fri Jun 16 07:44:30 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 HAA09532 for ; Fri, 16 Jun 2000 07:44:29 -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 HAA17184; Fri, 16 Jun 2000 07:40:08 -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 HAA34834; Fri, 16 Jun 2000 07:40:10 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42726; Fri, 16 Jun 2000 07:11:04 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47568; Fri, 16 Jun 2000 07:11:00 -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 HAA28392 for ; Fri, 16 Jun 2000 07:11:01 -0400 Received: from annexia.orchestream.com (mail.orchestream.com [195.153.64.98]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA30980 for ; Fri, 16 Jun 2000 07:10:58 -0400 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by annexia.orchestream.com (8.9.2/8.7.3) with ESMTP id LAA00472 for ; Fri, 16 Jun 2000 11:13:49 +0100 (BST) Received: from s1000.orchestream.com (unverified) by s1000.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 16 Jun 2000 12:08:49 +0100 Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 12:08:49 +0100 Message-Id: From: "Muirhead, Richard" To: "'yuan wei'" , policy@raleigh.ibm.com Subject: RE: about Policy Based VPN Management Date: Fri, 16 Jun 2000 12:08:44 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Muirhead, Richard" Naturally "VPN" can mean a number of different things (remote acccess, branch, IPSEC, MPLS etc.)...but for MPLS VPN management, Access Security management and QoS management it is worth checking out Orchestream's website. http://www.orchestream.com . We have a Generally Available product. Richard Muirhead Senior Vice President, Technology Solutions +44 410 307 326 (Cellphone) ---------------------------------------------------------------------------- - Orchestream - IP Service Activation ---------------------------------------------------------------------------- - Red Herring's 'Top 50 private companies most likely to change the world' Network Computing 'Well Connected' Award Networld + Interop, Las Vegas 2000 Network Computing "Editor's Choice" Award 1999 Winner 'Best of Show' Networld + Interop I Las Vegas 1999 ---------------------------------------------------------------------------- - Frankfurt - London - New York ---------------------------------------------------------------------------- - http://www.orchestream.com -----Original Message----- From: yuan wei [mailto:yuanwei@sz.huawei.com.cn] Sent: Friday, June 16, 2000 10:20 AM To: policy@raleigh.ibm.com Subject: about Policy Based VPN Management Hi, Does anyone has the references of Policy Based VPN Management? It seems that the current work of Policy WG is limited to Qos Policy. It is said the the roadmap of HP policyXpert include the VPN. But where can i found more details. Thanks in advance. Best Regards, yuan wei Email: yuanwei@sz.huawei.com.cn From majordomo@raleigh.ibm.com Fri Jun 16 09:07:05 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 JAA11066 for ; Fri, 16 Jun 2000 09:07:04 -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 JAA32950; Fri, 16 Jun 2000 09:03:15 -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 JAA34864; Fri, 16 Jun 2000 09:03:18 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47830; Fri, 16 Jun 2000 08:38:30 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51660; Fri, 16 Jun 2000 08:38:27 -0400 Received: from lmr (dyn9-37-49-166.raleigh.ibm.com [9.37.49.166]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA24006 for ; Fri, 16 Jun 2000 08:38:30 -0400 Message-Id: <001801bfd790$43af7d20$a6312509@raleigh.ibm.com> From: "Lee Rafalow" To: References: <000001bfd7c1$74fd98e0$8c1a6c0a@huawei.com.cn> Subject: Re: about Policy Based VPN Management Date: Fri, 16 Jun 2000 08:41:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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: "Lee Rafalow" Content-Transfer-Encoding: 7bit The IETF has a working group chartered to develop IPsec policy-based management. See http://www.ietf.org/html.charters/ipsp-charter.html ----- Original Message ----- From: "yuan wei" To: Sent: Friday, June 16, 2000 5:20 AM Subject: about Policy Based VPN Management > Hi, > > Does anyone has the references of Policy Based VPN > Management? It seems that the current work of Policy WG > is limited to Qos Policy. It is said the the roadmap of > HP policyXpert include the VPN. But where can i found > more details. > > Thanks in advance. > > Best Regards, > yuan wei > Email: yuanwei@sz.huawei.com.cn > > From majordomo@raleigh.ibm.com Fri Jun 16 10:15: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 KAA12521 for ; Fri, 16 Jun 2000 10:15:43 -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 KAA29674; Fri, 16 Jun 2000 10:12:18 -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 KAA30430; Fri, 16 Jun 2000 10:12:17 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47612; Fri, 16 Jun 2000 09:47:52 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47602; Fri, 16 Jun 2000 09:47:48 -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 JAA30292 for ; Fri, 16 Jun 2000 09:47: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 JAA27102 for ; Fri, 16 Jun 2000 09:47:48 -0400 Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 09:43:10 -0400 Message-Id: <6399122981E1D211AB490090271E0AA33C9EB3@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'policy@raleigh.ibm.com '" , "'yuanwei@sz.huawei.com.cn'" Subject: RE: about Policy Based VPN Management Date: Fri, 16 Jun 2000 09:43:08 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Francis Reichmeyer (IPHighway MA)" The MPLS working group has started working on policy-based management for MPLS, as well. For example, please see: draft-wright-policy-mpls-00.txt Thanks, -Fran -----Original Message----- From: Lee Rafalow To: policy@raleigh.ibm.com Sent: 06/16/2000 8:41 AM Subject: Re: about Policy Based VPN Management The IETF has a working group chartered to develop IPsec policy-based management. See http://www.ietf.org/html.charters/ipsp-charter.html ----- Original Message ----- From: "yuan wei" To: Sent: Friday, June 16, 2000 5:20 AM Subject: about Policy Based VPN Management > Hi, > > Does anyone has the references of Policy Based VPN > Management? It seems that the current work of Policy WG > is limited to Qos Policy. It is said the the roadmap of > HP policyXpert include the VPN. But where can i found > more details. > > Thanks in advance. > > Best Regards, > yuan wei > Email: yuanwei@sz.huawei.com.cn > > From majordomo@raleigh.ibm.com Mon Jun 19 16:12: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 QAA22569 for ; Mon, 19 Jun 2000 16:12: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 QAA18616; Mon, 19 Jun 2000 16:08:26 -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 QAA31994; Mon, 19 Jun 2000 16:08:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33712; Mon, 19 Jun 2000 15:43:24 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45988; Mon, 19 Jun 2000 15:43:21 -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 PAA33366 for ; Mon, 19 Jun 2000 15:43:24 -0400 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25692 for ; Mon, 19 Jun 2000 15:43:21 -0400 Received: from xpeditio.cnd.hp.com (xpeditio.cnd.hp.com [15.2.113.211]) by palrel3.hp.com (Postfix) with ESMTP id 2821C73E for ; Mon, 19 Jun 2000 12:43:18 -0700 (PDT) Received: (from mhugh@localhost) by xpeditio.cnd.hp.com (8.7.1/8.7.3 SMKit7.01) id NAA16598 for policy@raleigh.ibm.com; Mon, 19 Jun 2000 13:43:17 -0600 (MDT) From: Hugh Mahon Message-Id: <200006191943.NAA16598@xpeditio.cnd.hp.com> Subject: request for feedback: Policy requirements drafts To: policy@raleigh.ibm.com Date: Mon, 19 Jun 2000 13:43:17 -0600 (MDT) Organization: HP Network & System Management Division X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Hugh Mahon Content-Transfer-Encoding: 7bit Hi Folks, We are interested in getting feedback on the requirements draft and a sense of what people in the WG think is missing, could be enhanced, etc., in the drafts describing requirements and expected use of a policy management system. The current revisions of the draft are available at: http://www.users.uswest.net/~hmahon/draft-ietf-policy-req-02-diffs.txt http://www.users.uswest.net/~hmahon/draft-mahon-policy-use-00.txt http://www.users.uswest.net/~hmahon/draft-mahon-policy-mgmt-00.txt The documents contain the contents of previous revisions of the requirements draft plus other information (change bars are in the drafts to show new or changed content from the -01 rev of the requirements draft). The current structure of the documents is in response to feedback from the WG that the draft should be shorter but the information should be preserved. To leverage from the 'next steps' slide for the requirements document: next steps - can continue to add more information, but is there a specific direction people would like this to go in? - one suggestion for how to proceed is to describe what needs to be done to manage QoS in the environment, then describe the requirements to support those activities - should I go into more detail on the existing usage cases? - shorten all of the drafts (with suggestions of what is not important to keep) - other feedback, questions? Thanks, Hugh Mahon John Schnizlein From majordomo@raleigh.ibm.com Tue Jun 20 02:09:47 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 CAA14089 for ; Tue, 20 Jun 2000 02:09:42 -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 CAA29566; Tue, 20 Jun 2000 02:05:14 -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 CAA33490; Tue, 20 Jun 2000 02:05:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36686; Tue, 20 Jun 2000 01:34:15 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25158; Tue, 20 Jun 2000 01:34:12 -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 BAA02302 for ; Tue, 20 Jun 2000 01:34:12 -0400 Received: from hotmail.com (law2-f92.hotmail.com [216.32.181.92]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA32238 for ; Tue, 20 Jun 2000 01:34:10 -0400 Received: (qmail 47680 invoked by uid 0); 20 Jun 2000 05:33:39 -0000 Message-Id: <20000620053339.47679.qmail@hotmail.com> Received: from 24.5.72.99 by www.hotmail.com with HTTP; Mon, 19 Jun 2000 22:33:38 PDT X-Originating-Ip: [24.5.72.99] From: "sheri li" To: yuanwei@sz.huawei.com.cn, policy@raleigh.ibm.com Subject: Re: about Policy Based VPN Management Date: Mon, 19 Jun 2000 22:33:38 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "sheri li" Yuan, If you'd like to learn more about policy based VPN product. Check http://www.aventail.com It provides extranet products/services based on granualar access control policy. Sheri Li >From: "yuan wei" >Reply-To: "yuan wei" >To: >Subject: about Policy Based VPN Management >Date: Fri, 16 Jun 2000 09:20:11 -0000 > >Hi, > > Does anyone has the references of Policy Based VPN >Management? It seems that the current work of Policy WG >is limited to Qos Policy. It is said the the roadmap of >HP policyXpert include the VPN. But where can i found >more details. > > Thanks in advance. > >Best Regards, >yuan wei >Email: yuanwei@sz.huawei.com.cn > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From majordomo@raleigh.ibm.com Tue Jun 20 14:01:01 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 OAA00631 for ; Tue, 20 Jun 2000 14:01:01 -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 NAA23284; Tue, 20 Jun 2000 13:57:28 -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 NAA27396; Tue, 20 Jun 2000 13:57:29 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46962; Tue, 20 Jun 2000 13:25:35 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44902; Tue, 20 Jun 2000 13:25:32 -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 NAB02110 for ; Tue, 20 Jun 2000 13:25:36 -0400 Received: from groucho.doc.ic.ac.uk (IDENT:root@groucho.doc.ic.ac.uk [146.169.14.3]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA09186 for ; Tue, 20 Jun 2000 13:25:31 -0400 Received: from dse-pc-mss.doc.ic.ac.uk (dse-pc-mss.doc.ic.ac.uk [146.169.14.135]) by groucho.doc.ic.ac.uk (8.9.3/8.9.3) with ESMTP id SAA10777 for ; Tue, 20 Jun 2000 18:23:47 +0100 Message-Id: <4.3.1.2.20000620181450.00bc3700@dse-mail.doc.ic.ac.uk> X-Sender: mss@dse-mail.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 20 Jun 2000 18:17:22 +0100 To: policy@raleigh.ibm.com From: Morris Sloman Subject: Policy 2001 Deadline extended to 4 July Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Morris Sloman Policy 2001: Workshop on Policies for Distributed Systems and Networks 29-31 January 2001 Hosted by: HP Laboratories, Bristol, UK Technical Co-sponsored by IEEE ComSoc (not yet approved) See: http://www-dse.doc.ic.ac.uk/events/policy-2001/ for the latest information Policy based systems are the subject of a wide range of activities in universities, standardisation bodies and within industry. They have a wide spectrum of applications ranging from quality of service management within networks to security and enterprise modelling. This workshop will provide a forum for discussion and collaboration between researchers, developers and users of policy based systems. It will bring together the various communities working on policy and follows on from the successful informal Policy Workshop held in November 1999 (see http://www-dse.doc.ic.ac.uk/events/policy-99/). Within the Internet community there is considerable interest in Policy Based Networking. A number of companies have announced tools to support the specification and deployment of policies. Much of this work is focused on policies for quality of service management within networks and the Internet Engineering and Distributed Management Task Forces (IETF/DMTF) is actively working on standards related to this area (see http://www-dse.doc.ic.ac.uk/research/policies for links). The Security community has focused on the specification and analysis of access control policy which has evolved into the work on Role-Based Access Control (RBAC). There has been work over a number of years in the academic community on specification and analysis of policies for Distributed Systems mostly concentrating on authorisation policies. Although there are strong similarities in the concepts and techniques used by the different communities there is no commonly accepted terminology or notation for specifying policy. Several research groups are looking at high-level aspects of policy related to Enterprise Modelling. An ISO Open Distributed Processing working group is defining Policy and Role concepts within the Enterprise Viewpoint. Enterprise goals or Service Level Agreements can be considered as high-level abstract policies which must be progressively refined into implementable policies. The work on the specification and analysis of Business Rules is also relevant. The common concept of policy, within all of the above communities, is that polices define a set of rules governing choices in the behaviour of the system. The motivation is to be able to modify policy in order to change system behaviour without having to re-implement the system, or restructure the requirements specification. -------------------------------------------------------------------------- Authors are invited to submit papers addressing but not limited to the following topics: Abstractions and Notations for Policy Specification Security Policies and Role Based Access Control Management Policies Policy Based Networking Implementation Models and Techniques Services for Storing and Manipulating Policies Policy Support for Active Networks and Mobile Environments Application-Specific Policy Frameworks Policy Refinement Policy Analysis Business Rules Standardisation Activities Case Studies The emphasis of the workshop will be on practical approaches to policy, however, novel contributions are encouraged. Workshop format --------------- The workshop will include both invited papers and presentations on accepted refereed papers which will be published (probably by IEEE Press) in a proceedings. There will be substantial time allocated for discussions as well as panel sessions. PAPER SUBMISSIONS ----------------- Paper submissions must present original, unpublished research or experiences. They should be full papers and be no longer than 10 pages IEEE double column format. Submissions must include a cover page in ASCII format, containing the title, author name(s) and affiliation(s), the complete address (telephone, fax, email) of the corresponding author, and an abstract (max 150 words) followed by up to 5 keywords. Papers under review elsewhere must not be submitted to Policy 2000. Authors are requested to submit papers in electronic PDF or Postscript format. Instructions for electronic submissions will be available at the following URL: http://www-dse.doc.ic.ac.uk/events/policy-2001/ IMPORTANT DATES July 3, 2000: Submission of Full Papers September 26, 2000: Notifications of Acceptance October 26, 2000: Camera-ready Papers Due Date January 29-31, 2001 Workshop Local Arrangements ------------------ The workshop will be held at Hewlett-Packard's European research centre in Bristol. It is conveniently reached by road and rail (to Bristol Parkway Station) from London and Heathrow Airport. It takes approximately 80 minutes by train from London, Paddington. Directions and local information can be found at the HP's web site: http://www-uk.hpl.hp.com Hotel rooms will reserved at a local hotel. Details and costs to be provided. Organising Committee --------------------- Conference Chair Morris Sloman Department of Computing, Imperial College London SW7 2BZ, UK Phone: +44 20 7594 8279 Fax: +44 20 7581 8024 email: m.sloman@doc.ic.ac.uk Program Co-Chairs Emil Lupu Department of Computing, Imperial College Phone: +44 20 7594 8249 Fax: +44 20 7581 8024 London SW7 2BZ, UK email: e.c.lupu@doc.ic.ac.uk Jorge Lobo Bell Labs 600 Mountain Ave., 2c-219 Murray Hill, NJ 07974, USA Voice: +1-908-582-1731 Fax: +1-908-582-4092 Mail: jlobo@research.bell-labs.com Program Committee ------------------ David Black, EMC, USA Matt Blaze, AT&T, USA Jan Chomicki, Monmouth University, USA Naranker Dulay, Imperial College, UK Ed Ellesson, Tivoli Systems, USA Francisco Garcia, Agilent Laboratories, Scotland Cheh Goh, HP Labs, Bristol, UK Kohei Iseda, Fujitsu Laboratories, Japan Peter Linington, University of Kent, UK Hugh Mahon, HP, USA Ian Marshall, BT Labs., UK Zoran Milosevic, DSTC, Brisbane, Australia Naftaly Minksy, Rutgers University, USA Jonathan Moffett, University of York, UK Ken Moody, Cambridge University, UK Ravi Sandhu, George Mason University, USA Edgar Sibley, George Mason University, USA John Strassner, Cisco, USA Vijay Varadharajan, University of Western Sydney, Australia Dinesh Verma, IBM, USA Andrea Westerinen, SNIA, USA Local Organisation: ------------------- Jan Ward Events Co-ordinator HP Labs, Bristol Phone: +44 117 312 8032 Fax: +44 117 312 9364 email: jan@hplb.hpl.hp.com From majordomo@raleigh.ibm.com Mon Jun 26 11:03:02 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 LAA07866 for ; Mon, 26 Jun 2000 11:03:01 -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 LAA29788; Mon, 26 Jun 2000 11:01:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA20026; Mon, 26 Jun 2000 11:01:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27744; Mon, 26 Jun 2000 10:29:32 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37208; Mon, 26 Jun 2000 10:29:29 -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 KAA28418 for ; Mon, 26 Jun 2000 10:29:25 -0400 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA24012 for ; Mon, 26 Jun 2000 10:29:23 -0400 Received: from [24.128.63.114] (h0050e460d16d.ne.mediaone.net [24.128.63.114]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA01801; Mon, 26 Jun 2000 10:28:44 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 26 Jun 2000 10:29:03 -0400 Subject: Re: request for feedback: Policy requirements drafts From: Jon Saperia To: Hugh Mahon , , Jon Saperia Message-Id: In-Reply-To: <200006191943.NAA16598@xpeditio.cnd.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit on 06/19/2000 3:43 PM, Hugh Mahon at mhugh@xpeditio.cnd.hp.com wrote: Hugh some comments about: ~hmahon/draft-mahon-policy-use-00.txt First, I find it helpful for work items that are the result of or intended products of an active WG to be published on the WG page. Helps with references and keeping current. Page 4. > Policy Management is a way for the Network Administrator to > pro-actively manage the network, not simply react to how > users use the network. The intent is to ensure the value > of a shared resource, which is what the network is, not to > take anything away from the users. The second sentence could use a bit of rewording for clarity. I also have an issue with what is not included here. Policy is also to cause a consistent behavior or configuration. For example, I want to have all systems from XYZ vendor that are model 2's running release 4.4. I want to make sure we support they type of shared resource provisioning for 'quality of service' type examples but we should also include examples such as the one I describe. as well. Page 7 - 8. > Once the administrator has authored these rules they would > be committed to a repository. How the Policy Management > Application chooses to order operations is implementation > dependent, but the Policy Rules must be grouped together to > form a Policy Group. Once grouped the Policy can option- > ally be run through tools to determine if there are con- > flicts between Policy Rules within the Policy. > It may not be obvious to unfamiliar readers what is meant by a policy group here. I think the document would benefit from a table of terms for rule, condition, etc. I am aware of the terminology work that has been done in other documents, but think importing a few terms here would be helpful. Page 10. > Once the Policy Rules based configuration has been sent > to the Policy Target(s) the Policy Consumer will deter- > mine the success of the deployment and provide feedback > to the Policy Management Application. In order to > determine the success, for this example, the Policy Con- > sumer will query the device and examine the information > relating to the configuration of the Policy Target(s) to > determine if the configuration now matches what the Pol- > icy Consumer expects based on the Policy Data. This is one way of confirming correctness of the configuration operation which is quite reasonable. Another way would be via exception reporting or an ack. from the target. That is, an ack confirms correct reciept, i.e., success. Error messages can be sent back with what when wrong. Page 11. > As described above, at the start or end of a time/date > period expressed in a condition the Policy Consumer > would re-evaluate the Policy Rules for the Policy Target > and perform the necessary translations, check existing > configuration, perform any necessary clean-up, deploy > the corresponding configuration, and report status. > (Alternatively the Policy Consumer could generate the > appropriate information for any given time period speci- > fied in the Policy Rules and simply download them at the > appropriate times rather than filter at each time bound- > ary.) Also reasonable. Some policy consumers can send to the policy target the schedule for policy execution. Perhaps this is for a 'policy aware' device? The point is some devices under policy control will have scheduling capability locally and all the need is that the policy information contain this when deployed. This facility does not prevent the other type of distribution where the policy consumer reloads policy when needed. Page 16. > bilities. A well implemented Policy Consumer will detect > any problems with a Policy before deploying it on a Target > (if the problem wasn't detected in an automated way ear- > lier). If a Policy Consumer does detect such a problem it > will provide feedback to the Administrator through the Pol- > icy Management Repository. I understand policy consumer to be management application. In this context I agree that such software should check before deploying a policy. In some cases only the managed element will know at the time the request is made if the policy will work or not - this should be the exception. That said, the exception, that is to say the failed policy deployment should in my view be stored somewere - the repository is fine. The the event enunnciation is not via the repository it is via some enunciation software such as a gui, email, pager, etc. Page 18. > Scenario 1 allows for minimal change to the Core Informa- > tion Model. It would, however, cause Policies to be clut- > tered with Policy Rules (or condition lists within Policy > Rules) which only exist to handle contingencies. Such con- > ditions which deal with state likely would not be evaluated > on the Policy Targets (using existing devices as the > model), rather they would be evaluated on the Policy Con- > sumer. > > An example of such a state condition could be: > > condition type name: deviceDown > attributes: device address: 192.168.14.12 > considered down if no contact after: 30 > seconds > > To enable such a condition, either the Policy Consumer > would need to poll each of the devices named in each such > condition, or would need to be notified by some third party > monitoring the condition of each device named in each pol- > icy condition. > > I have a bit of a problem with this model in that it is too restrictive. I have no problem if people want to deploy policy in the fashion you describe here for failures and architectures should support this - but believe there is a better approach. Sure, the managed element should keep it's manager posted as to its status. This can be achieved via asynchronous or polling methods or a combination of both. In some cases, however; the managed element (policy target) should have the policy to apply in the case of a failure and is in the right place to do so rapidly. In SONET networks change over as a result of failure can take place fairly rapidly (that is the goal at least). These machines should have the policy to employ locally in the case of the failure due to time constraints, a polling based approach when rapid correction is desired would be problematic. My other concern about the example is that it is on a device basis. While it is true that entire devices can fail, it is more true that parts fail or the network infrastructure that connects them has a failure. so the condition is not deviceDown, but interface down. Page 19. > Scenario 2 would require a change to the Core Information > Model. On the association between a Policy and Policy Tar- > get, there would be conditional associations to other Poli- > cies. In the association would be conditions similar to > those described in Scenario 1, which describe conditions > under which the Policies for unusual circumstances would be > deployed. If the current indirect model for distribution > is followed, all of the policies would be placed in the > directory and the Policy Consumer would obtain all of the > policies, then change which Policy is deployed to the Pol- > icy Target on a status change as described in Scenario 1. > If a more direct model for Policy distribution were used, > then the Policy Management Application could be enabled to > change Policy distribution based on state not related to > traffic based conditions. > This is a bit closer to what I had in mind, except that it assumes that the policy management application is watching over everything and knows enough what to do in the case of a failure condition and then loads the correct policy to the devices it needs to. There is no problem in an architecture allowing for this type of approach but believe it to be insufficient in many circumstances. For this reason, a policy application may send to a managed device the policy to use when things are ok, and the policy to use (perhaps more than one) when there is a failure. Page 21. > 2.6.2. Snooping Signaling Messages to Glean Classification > Information There is no problem in principle with a management application collecting data from the network and using that for policy setting. My objection is that the example is RSVP specific and should be in this type of document, I think more broadly worded. For example, a management application could learn a lot from other types of instrumentation in the network about who is using the net, what type of traffic is being sent, etc. Both these examples have some interesting security implications though. Page 22. > 2.6.3. Offering High Quality Guarantees My comment about this section is that is why policy is most usefully expressed in terms of amount of traffic, capacity of a device and utilization. A device might be configured to deliver a maximum of X voice over IP sec. I like some of the examples but again find that they are too restrictive. A policy manager can send information to devices under some circumstances. In other cases the policy should contain what to do if a resource is exceeded, or alternatively a second policy would be triggered in the event of 'oversubscription'. This is not to say that the centralized policy manager would not have a function in this area since it may monitor for aggregate usage and cause policies to changes based on state or usage information from many places in the network. Page 33. > 3. Security Considerations My problem is not with what is there, but what is missing. Either the list should be complete or a pointer to other documents provided. I believe that user authentication is important for example. /jon