From majordomo@raleigh.ibm.com Mon May 1 22:58:51 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 WAA11482 for ; Mon, 1 May 2000 22:58: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 WAA27352; Mon, 1 May 2000 22:53:07 -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 WAA32450; Mon, 1 May 2000 22:53:06 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52024; Mon, 1 May 2000 12:58:57 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47904; Mon, 1 May 2000 12:58:51 -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 MAA31064 for ; Mon, 1 May 2000 12:58:53 -0400 Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [203.197.74.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id MAA19210 for ; Mon, 1 May 2000 12:57:32 -0400 Received: (qmail 18620 invoked from network); 1 May 2000 17:11:10 -0000 Received: from surya.cse.iitb.ernet.in (144.16.111.14) by mailhost.iitb.ac.in with SMTP; 1 May 2000 17:11:10 -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 WAA09314 for ; Mon, 1 May 2000 22:26:47 +0530 (IST) Received: (from dhiman@localhost) by everest.cse.iitb.ernet.in (8.9.2/8.9.2) id WAA28507 for policy@raleigh.ibm.com; Mon, 1 May 2000 22:24:08 +0530 (GMT) Date: Mon, 1 May 2000 22:24:08 +0530 From: Dhiman Barman To: policy@raleigh.ibm.com Subject: network manager Message-Id: <20000501222408.A28356@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, I am in a need to use a Traffic Manager for a specific purpose. The feedback from TM will be used to configure/control network devices in a dynamic network. Is there any kind TM for us to refer to in public domain ? Thanks. Sincerely, Dhiman From majordomo@raleigh.ibm.com Tue May 2 16:20: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 QAA08209 for ; Tue, 2 May 2000 16:20:32 -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 QAA21638; Tue, 2 May 2000 16:17:13 -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 QAA15284; Tue, 2 May 2000 16:17:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51178; Tue, 2 May 2000 15:36:08 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42714; Tue, 2 May 2000 15:36:04 -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 PAA19902 for ; Tue, 2 May 2000 15:36:09 -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 OAA11016 for ; Tue, 2 May 2000 14:35:36 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568D3.006BC8E3 ; Tue, 2 May 2000 14:37:17 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <862568D3.006BC860.00@tivmta4.tivoli.com> Date: Tue, 2 May 2000 15:30:52 -0400 Subject: from [Internet-Drafts@ietf.org] 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 forwarding to policy list. ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on 05/02/2000 03:30 PM --------------------------- policy-owner@raleigh.ibm.com on 05/02/2000 06:43:40 AM To: policy-owner@raleigh.ibm.com cc: (bcc: Ed Ellesson/Tivoli Systems) Subject: BOUNCE policy@raleigh.ibm.com: Non-member submission from [Internet-Drafts@ietf.org] From nsyracus@cnri.reston.va.us Tue May 2 06:43:35 2000 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44504; Tue, 2 May 2000 06:43:35 -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 GAA03830 for ; Tue, 2 May 2000 06:43:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA28278 for ; Tue, 2 May 2000 06:43:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26740; Tue, 2 May 2000 06:43:34 -0400 (EDT) Message-Id: <200005021043.GAA26740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: policy@raleigh.ibm.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-policy-qos-info-model-01.txt Date: Tue, 02 May 2000 06:43:33 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Policy Framework QoS Information Model Author(s) : Y. Snir, Y. Ramberg, J. Strassner, R. Cohen Filename : draft-ietf-policy-qos-info-model-01.txt Pages : 71 Date : 01-May-00 This document presents an object-oriented information model for representing network QoS policies. This document refines the core policy information model presented in [PCIM]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing QoS policies. It also provides refinement of additional concepts that are important for building rule-specific as well as reusable QoS policy rules. This information model covers Differentiated Services QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. It is important to note that this document defines an information model, which by definition is independent of any particular repository and access protocol. A companion document [QoSSCHEMA] defines the mapping of these classes to a directory that uses LDAPv3 as its access protocol. A second companion document [QOSDEV] supplies low- level definitions of QoS mechanisms that are controlled by this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-info-model-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-info-model-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000501102231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-info-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-info-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000501102231.I-D@ietf.org> --OtherAccess-- --NextPart-- From majordomo@raleigh.ibm.com Tue May 2 16:25:10 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 QAA08267 for ; Tue, 2 May 2000 16:25:09 -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 QAA22352; Tue, 2 May 2000 16:17:10 -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 QAA28924; Tue, 2 May 2000 16:17:12 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37418; Tue, 2 May 2000 15:35:03 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54036; Tue, 2 May 2000 15:35:00 -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 PAA28024 for ; Tue, 2 May 2000 15:35:04 -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 OAA04853 for ; Tue, 2 May 2000 14:34:32 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568D3.006BAFC9 ; Tue, 2 May 2000 14:36:13 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <862568D3.006BAE45.00@tivmta4.tivoli.com> Date: Tue, 2 May 2000 15:29:46 -0400 Subject: from [Internet-Drafts@ietf.org] 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 forwarding to the list. ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on 05/02/2000 03:28 PM --------------------------- policy-owner@raleigh.ibm.com on 05/02/2000 06:43:45 AM To: policy-owner@raleigh.ibm.com cc: (bcc: Ed Ellesson/Tivoli Systems) Subject: BOUNCE policy@raleigh.ibm.com: Non-member submission from [Internet-Drafts@ietf.org] From nsyracus@cnri.reston.va.us Tue May 2 06:43:42 2000 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43022; Tue, 2 May 2000 06:43:42 -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 GAA03596 for ; Tue, 2 May 2000 06:43:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA25676 for ; Tue, 2 May 2000 06:43:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26755; Tue, 2 May 2000 06:43:39 -0400 (EDT) Message-Id: <200005021043.GAA26755@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: policy@raleigh.ibm.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-policy-qos-schema-01.txt Date: Tue, 02 May 2000 06:43:38 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : QoS Policy Schema Author(s) : Y. Snir, Y. Ramberg, J. Strassner, R. Cohen Filename : draft-ietf-policy-qos-schema-01.txt Pages : 79 Date : 01-May-00 The purpose of this document is to provide a mapping of QoS policy information to a form that can be implemented in a directory that uses (L)DAP as its access protocol. Its derivation is as follows. The structure of generic policy information is defined in the Policy Core Information Model ([PCIM]). The mapping of this information to a form that can be implemented in a directory is defined in the Policy Core Schema ([PFSCHEMA]). The [PCIM] is extended to represent specific information needed to represent QoS policies with the QoS Information Model ([QOSIM]). This draft, then, maps the data defined in the [QOSIM] to a form that can be implemented in a directory. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing policies to control the configuration and management of RSVP and Differentiated Services. This document also discusses LDAP related issues regarding the implementation of such a schema. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-schema-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-schema-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-schema-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000501102242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-schema-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-schema-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000501102242.I-D@ietf.org> --OtherAccess-- --NextPart-- From majordomo@raleigh.ibm.com Tue May 9 12:24: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 MAA24220 for ; Tue, 9 May 2000 12:24:52 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA20390; Tue, 9 May 2000 12:12: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 MAA34624; Tue, 9 May 2000 12:12:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48902; Tue, 9 May 2000 11:23:47 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48880; Tue, 9 May 2000 11:23:44 -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 LAA25514 for ; Tue, 9 May 2000 11:23:45 -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 KAA10816 for ; Tue, 9 May 2000 10:23:14 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568DA.0054AC4A ; Tue, 9 May 2000 10:24:51 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <862568DA.0054A8F4.00@tivmta4.tivoli.com> Date: Tue, 9 May 2000 11:18:04 -0400 Subject: Call for Volunteers: Policy Terminology Editor Team 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 Policy Framework Working Group, This is a call for volunteers, to edit the next revision of the policy terminology draft. Please send a reply to John and I, before the end of this week, Friday, May 12, to indicate your willingness to participate on this team. If you are on the current editor team for this draft, please indicate whether you wish to continue. The Policy Terminology draft is now the responsibility of this working group. We need a revised document to be ready for some level of working group last call before the next IETF, so time is short. This effort is fundamental to understanding how the multiple IETF policy efforts are related, and hence the need for urgency. Please respond as quickly as possible. Thanks! Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 From majordomo@raleigh.ibm.com Tue May 9 15:59:37 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 PAA29500 for ; Tue, 9 May 2000 15:59:37 -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 PAA22398; Tue, 9 May 2000 15:56:21 -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 PAA23130; Tue, 9 May 2000 15:56:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35236; Tue, 9 May 2000 15:32:24 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35226; Tue, 9 May 2000 15:32:21 -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 PAA29978 for ; Tue, 9 May 2000 15:32:23 -0400 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25402 for ; Tue, 9 May 2000 15:32:20 -0400 Received: from lucent.com (mstevens.lucentctc.com [205.181.0.85]) by rerun.lucentctc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id HKNWR9X0; Tue, 9 May 2000 15:31:51 -0400 Message-Id: <3918672B.7BDAB046@lucent.com> Date: Tue, 09 May 2000 15:29:47 -0400 From: Mark Stevens Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en Mime-Version: 1.0 To: Ed_Ellesson@tivoli.com Cc: policy@raleigh.ibm.com, johns@cisco.com Subject: Re: Call for Volunteers: Policy Terminology Editor Team References: <862568DA.0054A8F4.00@tivmta4.tivoli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mark Stevens Content-Transfer-Encoding: 7bit Ed, John, I am willing to participate. -Mark Ed_Ellesson@tivoli.com wrote: > Policy Framework Working Group, > > This is a call for volunteers, to edit the next revision of the policy > terminology draft. Please send a reply to John and I, before the end of this > week, Friday, May 12, to indicate your willingness to participate on this team. > If you are on the current editor team for this draft, please indicate whether > you wish to continue. > > The Policy Terminology draft is now the responsibility of this working group. > We need a revised document to be ready for some level of working group last call > before the next IETF, so time is short. > > This effort is fundamental to understanding how the multiple IETF policy efforts > are related, and hence the need for urgency. Please respond as quickly as > possible. Thanks! > > Ed Ellesson > Tivoli Systems > Research Triangle Park, NC > ed_ellesson@tivoli.com > 919-254-4115 From majordomo@raleigh.ibm.com Thu May 11 09:49: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 JAA27965 for ; Thu, 11 May 2000 09:49:49 -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 JAA18040; Thu, 11 May 2000 09:42: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 JAA27316; Thu, 11 May 2000 09:42:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48996; Thu, 11 May 2000 09:13:58 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37676; Thu, 11 May 2000 09:13:45 -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 JAA04532 for ; Thu, 11 May 2000 09:13:47 -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.8m3/NCO v2.07) with SMTP id JAA51870 for ; Thu, 11 May 2000 09:05:00 -0400 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568DC.0047DDA0 ; Thu, 11 May 2000 09:04:57 -0400 X-Lotus-Fromdomain: IBMUS To: policy@raleigh.ibm.com Message-Id: <852568DC.0047DD54.00@d54mta04.raleigh.ibm.com> Date: Thu, 11 May 2000 08:58:15 -0400 Subject: PCIM-06 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 An update to the PCIM, draft-ietf-policy-core-info-model-06.txt, is now available on the Internet-Drafts repository. This update was done in response to an IESG comment pointing out that the handling of time zone information in PCIM-05 was inadequate. The update also contains a general cleanup item, and a change that removes some text that might be appropriate for the LDAP representation of the model, but is not appropriate for the PCIM itself. Specifically: 1. The time zone issue concerned the use of UTC offsets. In PCIM-05, the ApplicableTimeZone property allowed times to be specified with a numeric offset (+ or -) from UTC time -- for example, -0500 for [US] Eastern Time. The iCalendar spec (RFC 2445), however, explains that while numeric offsets from UTC are fine for past times, they are not sufficient for future intervals of time that span Daylight Savings Time transitions. A new section 5.4 in PCIM-06 provides more details on this issue, and explains how it is being addressed in the PCIM. 2. There are also two changes unrelated to time zones that I made in PCIM-06. In both cases these involved the removal of obsolete text that should have been removed back in PCIM-03 or PCIM-04, but was missed. The two paragraphs that I removed: Since conditions may be defined explicitly in a subclass of PolicyRule, the AND/OR mechanism to combine these conditions with other (associated) PolicyConditions MUST be specified by the PolicyRule's subclass. (section 7.6) For actions defined explicitly in a subclass of PolicyRule, the ordering mechanism must be specified in the subclass definition. (section 7.10) The problem with both of these passages is that we introduced text in these sections stating that A policy rule that aggregates zero policy conditions [actions] is not a valid rule -- it may, for example, be in the process of being entered into the policy repository. In making this change, to allow for better automated detection of invalid policy rules, we legislated out of existence the cases that the two paragraphs were referring to. I don't regard these two deletions as technical changes to the PCIM -- they're just editorial cleanup that should have happened long ago. 3. Finally, I removed some "lingering LDAP" flavor from the two associations PolicyGroupInSystem and PolicyRuleInSystem, to parallel changes that were made during final WG review in the DMTF. Formerly, the relationship between a policy group or policy rule and the system it applies to was expressed in terms of "containment". While this might be how these associations are represented when the information model is mapped to LDAP, in the model itself they are more correctly characterized as ones of scope, not containment. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Thu May 11 10:37: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 KAA29204 for ; Thu, 11 May 2000 10:37:52 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA29724; Thu, 11 May 2000 10:32:50 -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 KAA23240; Thu, 11 May 2000 10:32:52 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42252; Thu, 11 May 2000 10:13:37 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41720; Thu, 11 May 2000 10:13:34 -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 KAA06400 for ; Thu, 11 May 2000 10:13:36 -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 JAA03578; Thu, 11 May 2000 09:13:04 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568DC.004E4206 ; Thu, 11 May 2000 09:14:46 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Cc: johns@cisco.com, Robert_Moore@IBMUS.rscs, "Wijnen, Bert (Bert)" Message-Id: <862568DC.004AB495.00@tivmta4.tivoli.com> Date: Thu, 11 May 2000 09:29:23 -0400 Subject: Re: PCIM-06 draft 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 Policy Framework Working Group, A new -06 version of the PCIM is now in the repository, and referenced from the wg home page. Thanks to Bob Moore for getting the document updated and posted! The major change in this version is with regard to the handling of time zones. We made this change in response to IESG concerns. We would like working group review comments while the -06 version is going through IETF last call. That is, we are running the wg review of the time zone change, and IETF last call review in parallel. Thanks! Ed Ellesson and John Strassner, co-chairs From majordomo@raleigh.ibm.com Tue May 16 03:36: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 DAA29285 for ; Tue, 16 May 2000 03:36:07 -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 DAA16688; Tue, 16 May 2000 03:32: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 DAA37630; Tue, 16 May 2000 03:32:28 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42800; Tue, 16 May 2000 03:03:35 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42948; Tue, 16 May 2000 03:03:26 -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 DAA05950 for ; Tue, 16 May 2000 03:03:26 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA17054 for ; Tue, 16 May 2000 03:03:23 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA20787 for ; Tue, 16 May 2000 03:03:23 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA20777 for ; Tue, 16 May 2000 03:03:22 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Tue, 16 May 2000 09:03:21 +0200 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB073DE5C9@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: policy@raleigh.ibm.com Subject: draft-iab-qos-00.txt Date: Tue, 16 May 2000 09:02:56 +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)" This document is about to go out as Informational RFC. If anyone has comments, pls let me know asap. Bert Wijnen From majordomo@raleigh.ibm.com Tue May 16 20:21: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 UAA14512 for ; Tue, 16 May 2000 20:21: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 UAA20766; Tue, 16 May 2000 20:17: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 UAA30002; Tue, 16 May 2000 20:17:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26584; Tue, 16 May 2000 19:49:46 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36304; Tue, 16 May 2000 19:49:43 -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 TAA26426 for ; Tue, 16 May 2000 19:49:47 -0400 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id TAA30264 for ; Tue, 16 May 2000 19:49:42 -0400 Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 May 2000 16:42:15 -0700 (Pacific Daylight Time) Received: from STAY.platinum.corp.microsoft.com ([172.30.236.91]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 16 May 2000 15:49:38 -0700 Content-Class: urn:content-classes:message Subject: RE: draft-iab-qos-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBF87.E368236A" Date: Tue, 16 May 2000 15:41:34 -0700 X-Mimeole: Produced By Microsoft Exchange V6.0.4366.0 Message-Id: <078292D50C98D2118D090008C7E9C6A60E327195@STAY.platinum.corp.microsoft.com> Thread-Topic: draft-iab-qos-00.txt Thread-Index: Ab+/ED3yCzE7Hb6vSg2oibQt6EbxPAAc1ohg From: "Yoram Bernet" To: "Wijnen, Bert (Bert)" , Cc: , "Tony Hain" X-Originalarrivaltime: 16 May 2000 22:49:38.0585 (UTC) FILETIME=[03DC3090:01BFBF89] Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Bernet" This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBF87.E368236A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do think that the draft serves a useful purpose in highlighting some areas in which work remains to be done. However, I think that it paints a pessimistic picture of the state of the art and negelcts important prior work and developments. I would like to see it refined to account for these. I think that it should not be issued as an RFC at this time. I'll delve a little deeper in the following paragraphs. I would be happy to write paragraph by paragraph comments on the draft, if the iab is receptive/interested in this.=20 The concluding paragraphs call for "integrating the various elements of the (QoS) architecture into a cohesive whole" (section 6). The major elements discussed in the draft are intergated services and differentiated services. Oddly enough, the integration of these into a cohesive whole is precisely the work that has been underway for over a year, in the issll working group (see http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-04.tx t). Yet this document is not even cited in the references. Geoff - are you aware of the work that has been going on in this realm? Section 4.12 cites the "chicken and egg" problem of applications waiting for infrastructure and infrastructure waiting for applications. I think that the missing yet relevant pieces here are network devices and host operating systems. Network devices had support for a primitive form of diffserv for years (they are now becoming available with more sophisticated forms of diffserv support). Similarly, major equipment vendors have had RSVP available for several years. An operating system with a relatively simple and cohesive API has just become broadly available. Sure - there have been RSVP APIs for some time, as well as traffic control APIs, yet these did not combine the different elements into a cohesive whole in a manner that simpifies the task for applications. Following the availability of an operating system with a cohesive API, QoS enabled applications are emerging. Applications that use the QoS API include SAP/R3, Netmeeting, and TAPI-3 enabled apps. Applications that are currently porting to these APIs include Windows Media Technology and IP/TV. I think that given this landscape and the dramatic recent changes, the assessment of the state of the art in the text is quite pessimistic. Which brings me to the third point - section 7, although it starts by stating charitably that "there is no reason to condemn the QoS architectures as completely impractical" and goes on to mention that the missing sections need to be filled in with something "more substantial than pixie dust and wishful thinking" - scares the hell out of me. While I actually agree that there are missing pieces and I agree that a great service can be done by filling these in (I happen to believe that they lie primarily in the area of policy based provisioning and configuration as well as traffic engineering), I am afraid that this doc, in its current form will have a chilling effecrt on the creativity that we are seeing in the industry. It stands to chill both potential customers as well as equipment vendors from further experimentation, development and deployment, much in the same way that the RSVP Applicability Statement did some time ago. =20 =20 I have been working for some time now on the integration of the existing QoS components into a cohesive whole. I have been working with leaders in the industry as well as with IT folks and with customers. I think that Geoff's assessment of the weaknesses of the various architectures is pretty much correct. I also think that the work that has been happenning in the ISSLL group has been combining the architectures in a manner that addresses many of the deficiencies. I agree with Geoff on many of the individual issues raised. For example, I agree that the converged architecture must address QoS deployment diversity (as discussed in section 4.10). I think that the current converged approach is heading in this direction. I have considered issuing a draft describing how it does so, but simply have not had the time. Briefly put, the current converged approach suggests that applications signal to indicate what they would like and to provide the network information about themselves. This signaling is generally alolowed to flow end-to-end through the network. It is listened to by those devices that can benefit from listening to it. It is ignored by those that cannot. Certain devices will respond by installing per-flow state. Others will simply apply aggregate diffserv style traffic handling. The quality of services that a specific subnetwork can offer and the efficiency with which it can do so will depend on the functionality of the network devices within that subnetwork. The network manager is able to configure network elements in his or her subnetwork, to dial-in the desired tradeoff of QE product (bieng able to simultaneously support high quality services and to operate the network efficiently in terms of resource consumption) and processing overhead. This can be done in a seamless manner - all the information is available to the network manager to choose the point at which he/she wishes to operate his/her network. His/her choices are compatible with the choicesof network managers upstream or downstream. This idea is developed in a number of papers including one published recently in IEEE Communications, February issue. =20 Yoram=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 16, 2000 12:03 AM > To: policy@raleigh.ibm.com > Subject: draft-iab-qos-00.txt >=20 >=20 > This document is about to go out as Informational RFC. > If anyone has comments, pls let me know asap. >=20 > Bert Wijnen >=20 >=20 ------_=_NextPart_001_01BFBF87.E368236A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-iab-qos-00.txt

I do think that the draft serves a useful purpose in = highlighting some areas in which work remains to be done. However, I = think that it paints a pessimistic picture of the state of the art and = negelcts important prior work and developments. I would like to see it = refined to account for these. I think that it should not be issued as an = RFC at this time. I'll delve a little deeper in the following = paragraphs. I would be happy to write paragraph by paragraph comments on = the draft, if the iab is receptive/interested in this.

The concluding paragraphs call for "integrating = the various elements of the (QoS) architecture into a cohesive = whole" (section 6). The major elements discussed in the draft are = intergated services and differentiated services. Oddly enough, the = integration of these into a cohesive whole is precisely the work that = has been underway for over a year, in the issll working group (see http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-r= svp-04.txt). Yet this document is not even cited in the references. = Geoff - are you aware of the work that has been going on in this = realm?

Section 4.12 cites the "chicken and egg" = problem of applications waiting for infrastructure and infrastructure = waiting for applications. I think that the missing yet relevant pieces = here are network devices and host operating systems. Network devices had = support for a primitive form of diffserv for years (they are now = becoming available with more sophisticated forms of diffserv support). = Similarly, major equipment vendors have had RSVP available for several = years. An operating system with a relatively simple and cohesive API has = just become broadly available. Sure - there have been RSVP APIs for some = time, as well as traffic control APIs, yet these did not combine the = different elements into a cohesive whole in a manner that simpifies the = task for applications. Following the availability of an operating system = with a cohesive API, QoS enabled applications are emerging. Applications = that use the QoS API include SAP/R3, Netmeeting, and TAPI-3 enabled = apps. Applications that are currently porting to these APIs include = Windows Media Technology and IP/TV. I think that given this landscape = and the dramatic recent changes, the assessment of the state of the art = in the text is quite pessimistic.

Which brings me to the third point - section 7, = although it starts by stating charitably that "there is no reason = to condemn the QoS architectures as completely impractical" and = goes on to mention that the missing sections need to be filled in with = something "more substantial than pixie dust and wishful = thinking" - scares the hell out of me. While I actually agree that = there are missing pieces and I agree that a great service can be done by = filling these in (I happen to believe that they lie primarily in the = area of policy based provisioning and configuration as well as traffic = engineering), I am afraid that this doc, in its current form will have a = chilling effecrt on the creativity that we are seeing in the industry. = It stands to chill both potential customers as well as equipment vendors = from further experimentation, development and deployment, much in the = same way that the RSVP Applicability Statement did some time = ago.  

 
I have been working for some time now on the = integration of the existing QoS components into a cohesive whole. I have = been working with leaders in the industry as well as with IT folks and = with customers. I think that Geoff's assessment of the weaknesses of the = various architectures is pretty much correct. I also think that the work = that has been happenning in the ISSLL group has been combining the = architectures in a manner that addresses many of the deficiencies. I = agree with Geoff on many of the individual issues raised. For example, I = agree that the converged architecture must address QoS deployment = diversity (as discussed in section 4.10). I think that the current = converged approach is heading in this direction. I have considered = issuing a draft describing how it does so, but simply have not had the = time. Briefly put, the current converged approach suggests that = applications signal to indicate what they would like and to provide the = network information about themselves. This signaling is generally = alolowed to flow end-to-end through the network. It is listened to by = those devices that can benefit from listening to it. It is ignored by = those that cannot. Certain devices will respond by installing per-flow = state. Others will simply apply aggregate diffserv style traffic = handling. The quality of services that a specific subnetwork can offer = and the efficiency with which it can do so will depend on the = functionality of the network devices within that subnetwork. The network = manager is able to configure network elements in his or her subnetwork, = to dial-in the desired tradeoff of QE product (bieng able to = simultaneously support high quality services and to operate the network = efficiently in terms of resource consumption) and processing overhead. = This can be done in a seamless manner - all the information is available = to the network manager to choose the point at which he/she wishes to = operate his/her network. His/her choices are compatible with the = choicesof network managers upstream or downstream. This idea is = developed in a number of papers including one published recently in IEEE = Communications, February issue.   

Yoram
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Tuesday, May 16, 2000 12:03 AM
> To: policy@raleigh.ibm.com
> Subject: draft-iab-qos-00.txt
>
>
> This document is about to go out as = Informational RFC.
> If anyone has comments, pls let me know = asap.
>
> Bert Wijnen
>
>

------_=_NextPart_001_01BFBF87.E368236A-- From majordomo@raleigh.ibm.com Wed May 17 18:44:37 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12026 for ; Wed, 17 May 2000 18:44:37 -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 SAA20804; Wed, 17 May 2000 18:35:18 -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 SAA35900; Wed, 17 May 2000 18:35:21 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15686; Wed, 17 May 2000 18:05:05 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32574; Wed, 17 May 2000 18:05:02 -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 SAA37658 for ; Wed, 17 May 2000 18:05:07 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA26322 for ; Wed, 17 May 2000 18:05:02 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12935; Wed, 17 May 2000 15:04:06 -0700 (PDT) Received: from p7020-img-nt.cisco.com (dhcp-171-69-91-63.cisco.com [171.69.91.63]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA24532; Wed, 17 May 2000 17:03:57 -0500 (CDT) Message-Id: <4.3.1.2.20000517150146.028f9610@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 17 May 2000 15:02:18 -0700 To: "Yoram Bernet" From: Fred Baker Subject: RE: draft-iab-qos-00.txt Cc: "Wijnen, Bert (Bert)" , , , "Tony Hain" In-Reply-To: <078292D50C98D2118D090008C7E9C6A60E327195@STAY.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Fred Baker At 03:41 PM 5/16/00 -0700, Yoram Bernet wrote: >I would be happy to write paragraph by paragraph comments on the draft, if >the iab is receptive/interested in this. I can't imagine that they wouldn't be. I think you should copy the IAB on your comments. From majordomo@raleigh.ibm.com Tue May 30 10:51:18 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 KAA00243 for ; Tue, 30 May 2000 10:51:17 -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 KAA27928; Tue, 30 May 2000 10:46:26 -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 KAA27992; Tue, 30 May 2000 10:46:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15150; Tue, 30 May 2000 10:09:10 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA60966; Tue, 30 May 2000 10:09:07 -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 KAA30158 for ; Tue, 30 May 2000 10:09:08 -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 JAA29710 for ; Tue, 30 May 2000 09:08:37 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568EF.004DF9AA ; Tue, 30 May 2000 09:11:41 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <862568EF.004CEA9F.00@tivmta4.tivoli.com> Date: Tue, 30 May 2000 09:36:15 -0400 Subject: Last Call: Policy Core Information Model - Version 1 Specification to Proposed Standard 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 I am forwarding this note to the policy list, since the list only accepts notes from subscribers. Sorry for delay...I was out of the office, closing on the house I sold, and moving out of it. Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on 05/30/2000 09:34 AM --------------------------- The IESG on 05/25/2000 03:23:43 PM Please respond to iesg@ietf.org To: IETF-Announce: ; cc: policy@raleigh.ibm.com (bcc: Ed Ellesson/Tivoli Systems) Subject: Last Call: Policy Core Information Model - Version 1 Specification to Proposed Standard The IESG has received a request from the Policy Framework Working Group to consider Policy Core Information Model - Version 1 Specification as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-06.txt From majordomo@raleigh.ibm.com Tue May 30 15:31:35 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 PAA08160 for ; Tue, 30 May 2000 15:31:34 -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 PAA29368; Tue, 30 May 2000 15:24: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 PAA20452; Tue, 30 May 2000 15:24:50 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37542; Tue, 30 May 2000 14:57:28 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56982; Tue, 30 May 2000 14:57:25 -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 OAA19594 for ; Tue, 30 May 2000 14:57:28 -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 NAA01980 for ; Tue, 30 May 2000 13:56:56 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568EF.00685FAD ; Tue, 30 May 2000 14:00:02 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <862568EF.00685DC8.00@tivmta4.tivoli.com> Date: Tue, 30 May 2000 14:56:28 -0400 Subject: Polterm Editor/Design Team 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 Policy Framework Working Group: This is to thank all of you who expressed interest in contributing to the policy terminology draft, and to announce that Andrea Westerinen , will be the editor for the next draft of the document. Thank you Andrea, for agreeing to edit this important draft! The following people also expressed interest in contributing, and will constitute the "design team" for this draft, led by Andrea. Clear and proper credit to the editors/contributors of earlier drafts will also be attributed in the new draft. Andrea, please consider this note as your mandate to move forward, and to organize the efforts of this team to produce a new draft well before the next IETF draft deadline (for the Pittsburgh IETF meeting), so that other working group drafts can use the terminology documented there. Proposed "Design Team": Andrea will be the document editor, and the "Design Team" includes: John Schnizlein Jay Perry Shai Herzog Bob Quinn "Mark Scherling" Ed Ellesson John Strassner "Huynh, An-Ni (An-Ni)" Mark Stevens "Said Soulhi (LMC)" "Mark A. Carlson" As always, anyone can contribute to the efforts of our working group, including the polterm project. However, to get things moving again, we felt it would be good to have a somewhat smaller group (i.e. smaller than the entire working group) produce the next draft, so that it can get done and out in a short period of time. The above team constitutes that smaller group of individuals, who indicated their interest to contribute by responding to our earlier note requesting volunteers. Of course, the resulting draft will be discussed and a working group consensus developed for its contents, on this mailing list, once it has been produced and posted by the above design team. Thanks again to all of you who are planning to contribute. Ed Ellesson and John Strassner.