From majordomo@raleigh.ibm.com Tue May 1 05:13:53 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22071 for ; Tue, 1 May 2001 05:13: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 FAA27712; Tue, 1 May 2001 05:03: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 FAA33754; Tue, 1 May 2001 05:03:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55438; Tue, 1 May 2001 04:36:46 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47398; Tue, 1 May 2001 04:36:41 -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 EAA34234 for ; Tue, 1 May 2001 04:36:42 -0400 Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA27774 for ; Tue, 1 May 2001 04:36:40 -0400 Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f418aeX01158 for ; Tue, 1 May 2001 04:36:40 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f418add01135 for ; Tue, 1 May 2001 04:36:39 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 10:36:38 +0200 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0C28B003@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Policy Framework WG , Andrea Westerinen Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Date: Tue, 1 May 2001 10:36:36 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Inline > ---------- > From: Andrea Westerinen[SMTP:andreaw@cisco.com] > Sent: Tuesday, May 01, 2001 6:43 AM > To: Wijnen, Bert (Bert); Policy Framework WG > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Agreed. The title at the top of the pages is "Policy Terminology" but the > lead title is incorrect. Is "Policy Terminology" acceptable? > That is certainly better. Other titles we've used for this doc in the past An old one from Strassner/Ellesson (jun 1999) had the title: Terminology for describing network policy and services Another one from March 2000 (Reichmeyer, Grossman, Strassner, Condell) has the title: A Common Terminology for Policy Management In any event, the title should be such that we indicate for which "area" or "domain" we are trying to define the terminology. Maybe a title like: A Common Terminology for Policy-based Management Bert > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Wijnen, Bert (Bert) > Sent: Monday, April 30, 2001 10:14 AM > To: Policy Framework WG > Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > I think Randy has a point here! > > Bert > > > ---------- > > From: Randy Bush[SMTP:randy@psg.com] > > Sent: Thursday, April 26, 2001 6:21 PM > > To: Bert Wijnen > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > perhaps the title of this draft could be narrowed a bit. > > > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > Cc: policy@raleigh.ibm.com > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Policy Framework Working Group of the > > IETF. > > > > Title : Terminology > > Author(s) : A. Westerinen et al. > > Filename : draft-ietf-policy-terminology-03.txt > > Pages : 20 > > Date : 25-Apr-01 > > > > This document is a glossary of policy-related terms. It > > provides abbreviations, explanations, and recommendations for > > use of these terms. The document takes the approach and format > > of RFC2828 [R2828], which defines an Internet Security Glossary. > > The intent is to improve the comprehensibility and consistency > > of writing that deals with network policy, particularly Internet > > Standards documents (ISDs). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-policy-terminology-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > --NextPart > > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > > > --OtherAccess > > Content-Type: Message/External-body; > > access-type="mail-server"; > > server="mailserv@ietf.org" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-ietf-policy-terminology-03.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > --OtherAccess-- > > > > --NextPart-- > > > > > > ------- end of forwarded message ------- > > > From majordomo@raleigh.ibm.com Wed May 2 05:05:12 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04107 for ; Wed, 2 May 2001 05:05:11 -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 EAA25288; Wed, 2 May 2001 04:58: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 EAA37046; Wed, 2 May 2001 04:58:26 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33924; Wed, 2 May 2001 04:30:42 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA07722; Wed, 2 May 2001 04:30:36 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA35164 for ; Wed, 2 May 2001 04:30:38 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA26016 for ; Wed, 2 May 2001 04:30:35 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f428UBd11985; Wed, 2 May 2001 01:30:11 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AJS01309; Wed, 2 May 2001 01:30:04 -0700 (PDT) From: "Andrea Westerinen" To: "Scherling, Mark" , "'Wijnen, Bert \(Bert\)'" , "Policy Framework WG" Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Date: Wed, 2 May 2001 01:32:03 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <016D1D1E0314D5118A7F00508BD952522780DC@exvan01.x509.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Thanks for the input on this. Given all the suggestions below, I think that Terminology for Policy-Based Management of Networks might work. Is this acceptable? Andrea -----Original Message----- From: Scherling, Mark [mailto:mscherling@rsasecurity.com] Sent: Tuesday, May 01, 2001 9:03 AM To: 'Wijnen, Bert (Bert)'; Policy Framework WG; Andrea Westerinen Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt I agree with Bert that the title should reflect the contents. If the title is too broad it will not give any value to the contents since people will assume that all terminology is defined there. The title should be "Technical Policy Terminology" since it defines policy in technical terms, mostly related to networks. Using just Policy Terminology would not be correct since it doesn't define policy in a legal sense. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, May 01, 2001 1:37 AM To: Policy Framework WG; Andrea Westerinen Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Inline > ---------- > From: Andrea Westerinen[SMTP:andreaw@cisco.com] > Sent: Tuesday, May 01, 2001 6:43 AM > To: Wijnen, Bert (Bert); Policy Framework WG > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Agreed. The title at the top of the pages is "Policy Terminology" but the > lead title is incorrect. Is "Policy Terminology" acceptable? > That is certainly better. Other titles we've used for this doc in the past An old one from Strassner/Ellesson (jun 1999) had the title: Terminology for describing network policy and services Another one from March 2000 (Reichmeyer, Grossman, Strassner, Condell) has the title: A Common Terminology for Policy Management In any event, the title should be such that we indicate for which "area" or "domain" we are trying to define the terminology. Maybe a title like: A Common Terminology for Policy-based Management Bert > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Wijnen, Bert (Bert) > Sent: Monday, April 30, 2001 10:14 AM > To: Policy Framework WG > Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > I think Randy has a point here! > > Bert > > > ---------- > > From: Randy Bush[SMTP:randy@psg.com] > > Sent: Thursday, April 26, 2001 6:21 PM > > To: Bert Wijnen > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > perhaps the title of this draft could be narrowed a bit. > > > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > Cc: policy@raleigh.ibm.com > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Policy Framework Working Group of the > > IETF. > > > > Title : Terminology > > Author(s) : A. Westerinen et al. > > Filename : draft-ietf-policy-terminology-03.txt > > Pages : 20 > > Date : 25-Apr-01 > > > > This document is a glossary of policy-related terms. It > > provides abbreviations, explanations, and recommendations for > > use of these terms. The document takes the approach and format > > of RFC2828 [R2828], which defines an Internet Security Glossary. > > The intent is to improve the comprehensibility and consistency > > of writing that deals with network policy, particularly Internet > > Standards documents (ISDs). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-policy-terminology-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > --NextPart > > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > > > --OtherAccess > > Content-Type: Message/External-body; > > access-type="mail-server"; > > server="mailserv@ietf.org" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-ietf-policy-terminology-03.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > --OtherAccess-- > > > > --NextPart-- > > > > > > ------- end of forwarded message ------- > > > From majordomo@raleigh.ibm.com Wed May 2 16:22:26 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22388 for ; Wed, 2 May 2001 16:22:25 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA20758; Wed, 2 May 2001 16:13:40 -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 QAA37924; Wed, 2 May 2001 16:13:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57806; Wed, 2 May 2001 15:44:02 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41096; Wed, 2 May 2001 15:43:48 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA34728 for ; Wed, 2 May 2001 15:43:52 -0400 Received: from d04nm200nm300.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f42Jhi546844; Wed, 2 May 2001 15:43:44 -0400 Importance: Normal Subject: re: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt To: moats@tconl.com Cc: "Mircea Pana" , policy@raleigh.ibm.com, Ed Ellesson , "Joel M. Halpern" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Wed, 2 May 2001 15:52:23 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 05/02/2001 03:43:44 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" OK, I've made these changes in the draft. In updating sections 5.7 and 5.10, I found that I also needed to make the second paragraph in each section a little more "subclassy". Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com moats@tconl.com@raleigh.ibm.com on 04/27/2001 07:22:53 PM Please respond to moats@tconl.com Sent by: policy-owner@raleigh.ibm.com To: "Mircea Pana" , policy@raleigh.ibm.com cc: Ed Ellesson , "Joel M. Halpern" Subject: re: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt Mircea- What we are trying to capture is that you can attach subclasses of policyConditionAuxClass and policyActionAuxClass. Attaching those classes is (in my view) a null action, because they don't define anything. We are bound by the LDAP syntax rules because if we mark them as ABSTRACT, then we cannot use them in any content rules and the content rules should be as general as possible so that future updates don't require an update of this document. This (I think) is clarified by the following changes: Add the following sentence to the second paragraph of Section 5: If your implementation does not support auxiliary class inheritance and supports content rules, you will have to list auxiliary classes in content rules explicitly. Replace the first paragraph of 5.7 with The purpose of a policy condition is to determine whether or not the set of actions (contained in the policyRule that the condition applies to) should be executed or not. Subclasses of this auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When a subclass of this class is attached to an instance of policyRuleConditionAssociation, or to an instance of policyRule, it represents a rule-specific policy condition. When a subclass of this class is attached to an instance of policyInstance, it represents a reusable policy condition. and replace the first paragraph of 5.10 with The purpose of a policy action is to execute one or more operations that will affect network traffic and/or systems, devices, etc. in order to achieve a desired policy state. Subclasses of this auxiliary class can be attached to instances of three other classes in the Core Policy Schema. When a subclass of this class is attached to an instance of policyRuleActionAssociation, or to an instance of policyRule, it represents a rule-specific policy action. When a subclass of this class is attached to an instance of policyInstance, it represents a reusable policy action. Ryan > ** Original Subject: Re: WG Last Call on draft-ietf-policy-core-schema-10.txt > ** Original Sender: "Mircea Pana" > ** Original Date: Fri, 27 Apr 2001 09:22:16 -0500 > ** Original Message follows... > > I would greatly appreciate if the authors could address this issue > before the end of the "last call" (CoB Mon., April 30). > > Thanks, > Mircea. > > > "Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote: > > > > The policyCondition and policyAction are modeled as auxiliary object > > classes. Therefore it seems to be valid to attach them without > > specialization to entries of various structural classes. Should this be > > allowed? For example: LDAP allows the attachment of a > > policyConditionAuxClass class to a policyInstance entry without > > attaching any of the policyConditionAuxClass subclasses. > > > > IMO: If this is acceptable then a clarification should be added to PCLS > > to describe the evaluation / execution semantics? If this is not > > acceptable then additional constraints should be added as text or the > > class types should be changed from AUXILIARY to ABSTRACT. > > > > Regards, > > Mircea. > > Ed Ellesson wrote: > > > > The latest revision of the Policy Framework LDAP Core Schema is in the I-D > > repository. This revision reflects all known issues and comments. > > This note commences a two week working group last call, intended to bring > > forth any last issues. After such issues are resolved according to the > > working group consensus, we will be submitting this document to the IESG > > for approval as a proposed standard. > > > > This last call ends at CoB on Mon, April 30. > > > > Thank you, > > Joel M. Halpern > > w/ Ed Ellesson >** --------- End Original Message ----------- ** > From majordomo@raleigh.ibm.com Wed May 2 21:12:07 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27802 for ; Wed, 2 May 2001 21:12:07 -0400 (EDT) From: majordomo@raleigh.ibm.com 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 VAA10378; Wed, 2 May 2001 21:05:23 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA26052; Wed, 2 May 2001 21:05:19 -0400 Date: Wed, 2 May 2001 21:05:19 -0400 Message-Id: <200105030105.VAA26052@rtpmail03.raleigh.ibm.com> Even though this is an IETF document, I wonder if you need the "of Networks". In the Core Policy documents, we've tried to keep the scope of potential application broader than just networking, while at the same time focusing initially on networking disciplines like QoS and IPsec. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Andrea Westerinen" @raleigh.ibm.com on 05/02/2001 04:32:03 AM Please respond to "Andrea Westerinen" Sent by: policy-owner@raleigh.ibm.com To: "Scherling, Mark" , "'Wijnen, Bert \(Bert\)'" , "Policy Framework WG" cc: Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Thanks for the input on this. Given all the suggestions below, I think that Terminology for Policy-Based Management of Networks might work. Is this acceptable? Andrea -----Original Message----- From: Scherling, Mark [mailto:mscherling@rsasecurity.com] Sent: Tuesday, May 01, 2001 9:03 AM To: 'Wijnen, Bert (Bert)'; Policy Framework WG; Andrea Westerinen Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt I agree with Bert that the title should reflect the contents. If the title is too broad it will not give any value to the contents since people will assume that all terminology is defined there. The title should be "Technical Policy Terminology" since it defines policy in technical terms, mostly related to networks. Using just Policy Terminology would not be correct since it doesn't define policy in a legal sense. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, May 01, 2001 1:37 AM To: Policy Framework WG; Andrea Westerinen Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Inline > ---------- > From: Andrea Westerinen[SMTP:andreaw@cisco.com] > Sent: Tuesday, May 01, 2001 6:43 AM > To: Wijnen, Bert (Bert); Policy Framework WG > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Agreed. The title at the top of the pages is "Policy Terminology" but the > lead title is incorrect. Is "Policy Terminology" acceptable? > That is certainly better. Other titles we've used for this doc in the past An old one from Strassner/Ellesson (jun 1999) had the title: Terminology for describing network policy and services Another one from March 2000 (Reichmeyer, Grossman, Strassner, Condell) has the title: A Common Terminology for Policy Management In any event, the title should be such that we indicate for which "area" or "domain" we are trying to define the terminology. Maybe a title like: A Common Terminology for Policy-based Management Bert > Andrea > > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Wijnen, Bert (Bert) > Sent: Monday, April 30, 2001 10:14 AM > To: Policy Framework WG > Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > I think Randy has a point here! > > Bert > > > ---------- > > From: Randy Bush[SMTP:randy@psg.com] > > Sent: Thursday, April 26, 2001 6:21 PM > > To: Bert Wijnen > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > perhaps the title of this draft could be narrowed a bit. > > > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > Cc: policy@raleigh.ibm.com > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > > > --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Policy Framework Working Group of the > > IETF. > > > > Title : Terminology > > Author(s) : A. Westerinen et al. > > Filename : draft-ietf-policy-terminology-03.txt > > Pages : 20 > > Date : 25-Apr-01 > > > > This document is a glossary of policy-related terms. It > > provides abbreviations, explanations, and recommendations for > > use of these terms. The document takes the approach and format > > of RFC2828 [R2828], which defines an Internet Security Glossary. > > The intent is to improve the comprehensibility and consistency > > of writing that deals with network policy, particularly Internet > > Standards documents (ISDs). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-policy-terminology-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > --NextPart > > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > > > --OtherAccess > > Content-Type: Message/External-body; > > access-type="mail-server"; > > server="mailserv@ietf.org" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > > > --OtherAccess > > Content-Type: Message/External-body; > > name="draft-ietf-policy-terminology-03.txt"; > > site="ftp.ietf.org"; > > access-type="anon-ftp"; > > directory="internet-drafts" > > > > Content-Type: text/plain > > Content-ID: <20010425143032.I-D@ietf.org> > > > > --OtherAccess-- > > > > --NextPart-- > > > > > > ------- end of forwarded message ------- > > > From majordomo@raleigh.ibm.com Wed May 2 22:24:22 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29463 for ; Wed, 2 May 2001 22:24:22 -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 WAA33204; Wed, 2 May 2001 22:17:46 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id WAA37228; Wed, 2 May 2001 22:17:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51672; Tue, 1 May 2001 00:42:34 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35770; Tue, 1 May 2001 00:42:29 -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 AAA26206 for ; Tue, 1 May 2001 00:42:34 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA20874 for ; Tue, 1 May 2001 00:42:31 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f414g8d15941; Mon, 30 Apr 2001 21:42:08 -0700 (PDT) Received: from andreawlap (dhcp-128-107-131-164.cisco.com [128.107.131.164]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AJM00208; Mon, 30 Apr 2001 21:42:01 -0700 (PDT) From: "Andrea Westerinen" To: "Wijnen, Bert \(Bert\)" , "Policy Framework WG" Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Date: Mon, 30 Apr 2001 21:43:59 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0C28AEA2@nl0006exch002u.nl.lucent.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Agreed. The title at the top of the pages is "Policy Terminology" but the lead title is incorrect. Is "Policy Terminology" acceptable? Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Wijnen, Bert (Bert) Sent: Monday, April 30, 2001 10:14 AM To: Policy Framework WG Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt I think Randy has a point here! Bert > ---------- > From: Randy Bush[SMTP:randy@psg.com] > Sent: Thursday, April 26, 2001 6:21 PM > To: Bert Wijnen > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > perhaps the title of this draft could be narrowed a bit. > > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Cc: policy@raleigh.ibm.com > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Policy Framework Working Group of the > IETF. > > Title : Terminology > Author(s) : A. Westerinen et al. > Filename : draft-ietf-policy-terminology-03.txt > Pages : 20 > Date : 25-Apr-01 > > This document is a glossary of policy-related terms. It > provides abbreviations, explanations, and recommendations for > use of these terms. The document takes the approach and format > of RFC2828 [R2828], which defines an Internet Security Glossary. > The intent is to improve the comprehensibility and consistency > of writing that deals with network policy, particularly Internet > Standards documents (ISDs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-policy-terminology-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20010425143032.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-policy-terminology-03.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20010425143032.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > > ------- end of forwarded message ------- > From majordomo@raleigh.ibm.com Thu May 3 14:13:13 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02389 for ; Thu, 3 May 2001 14:13:12 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA24392; Thu, 3 May 2001 14:06:59 -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 OAA24886; Thu, 3 May 2001 14:06:58 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA11978; Thu, 3 May 2001 13:38:28 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50110; Thu, 3 May 2001 13:38:24 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA22592 for ; Thu, 3 May 2001 13:38:24 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA29354 for ; Thu, 3 May 2001 13:38:20 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 13:37:59 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Subject: PCLS Last Call is now complete Date: Thu, 3 May 2001 13:37:58 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson Hi, Policy WG: The working group last call on PCLS, Policy Core LDAP Schema (draft-ietf-policy-core-schema-10.txt) is complete. The document will be revised with the working group comments, which were discussed on the policy wg mailing list. It will then be submitted to the IESG for approval for proposed standard status. Ed Ellesson, w/ Joel Halpern Co-chairs, Policy WG From majordomo@raleigh.ibm.com Thu May 3 16:50:43 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09567 for ; Thu, 3 May 2001 16:50:43 -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 QAA18148; Thu, 3 May 2001 16:44:33 -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 QAA31798; Thu, 3 May 2001 16:44:31 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50080; Thu, 3 May 2001 16:10:22 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31384; Thu, 3 May 2001 16:10:18 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA31616 for ; Thu, 3 May 2001 16:10:18 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f43K0KA112416; Thu, 3 May 2001 16:00:21 -0400 Importance: Normal Subject: Re: PCLS Last Call is now complete To: Ed Ellesson Cc: "'policy@raleigh.ibm.com'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Thu, 3 May 2001 16:00:58 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 05/03/2001 04:00:20 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" OK, PCLS-11 is on its way to the Internet-Drafts repository. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Ed Ellesson @raleigh.ibm.com on 05/03/2001 01:37:58 PM Please respond to Ed Ellesson Sent by: policy-owner@raleigh.ibm.com To: "'policy@raleigh.ibm.com'" cc: Subject: PCLS Last Call is now complete Hi, Policy WG: The working group last call on PCLS, Policy Core LDAP Schema (draft-ietf-policy-core-schema-10.txt) is complete. The document will be revised with the working group comments, which were discussed on the policy wg mailing list. It will then be submitted to the IESG for approval for proposed standard status. Ed Ellesson, w/ Joel Halpern Co-chairs, Policy WG From majordomo@raleigh.ibm.com Thu May 3 16:50:56 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09581 for ; Thu, 3 May 2001 16:50:56 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA15344; Thu, 3 May 2001 16:44:34 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA34874; Thu, 3 May 2001 16:44:31 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41486; Thu, 3 May 2001 16:15:46 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42502; Thu, 3 May 2001 16:15:43 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA36458 for ; Thu, 3 May 2001 16:15:43 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA18854 for ; Thu, 3 May 2001 16:15:42 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43KFfG09959 for ; Thu, 3 May 2001 16:15:41 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43KFe309927 for ; Thu, 3 May 2001 16:15:41 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 22:15:39 +0200 Message-Id: <2413FED0DFE6D111B3F90008C7FA61FB0C348811@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andrea Westerinen Cc: Policy Framework WG Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt Date: Thu, 3 May 2001 22:15:36 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" Sounds fine to me. So is this the doc to go to WG Last Call? Bert > ---------- > From: Andrea Westerinen[SMTP:andreaw@cisco.com] > Sent: Thursday, May 03, 2001 7:18 PM > To: Robert Moore > Cc: Scherling, Mark; 'Wijnen, Bert (Bert)'; Policy Framework WG > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > The reflector seems to be working strangely. So, trying my reply again > ... > > I am happy to go with the document name ... > Terminology for Policy-Based Management > > Andrea > > -----Original Message----- > From: Robert Moore [mailto:remoore@us.ibm.com] > Sent: Wednesday, May 02, 2001 5:04 AM > To: Andrea Westerinen > Cc: Scherling, Mark; 'Wijnen, Bert (Bert)'; Policy Framework WG > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > Even though this is an IETF document, I wonder if > you need the "of Networks". In the Core Policy > documents, we've tried to keep the scope of potential > application broader than just networking, while at > the same time focusing initially on networking > disciplines like QoS and IPsec. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > > > "Andrea Westerinen" @raleigh.ibm.com on 05/02/2001 > 04:32:03 AM > > Please respond to "Andrea Westerinen" > > Sent by: policy-owner@raleigh.ibm.com > > > To: "Scherling, Mark" , "'Wijnen, Bert > \(Bert\)'" , "Policy Framework WG" > > cc: > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > Thanks for the input on this. > > Given all the suggestions below, I think that > Terminology for Policy-Based Management of Networks > might work. > > Is this acceptable? > Andrea > > -----Original Message----- > From: Scherling, Mark [mailto:mscherling@rsasecurity.com] > Sent: Tuesday, May 01, 2001 9:03 AM > To: 'Wijnen, Bert (Bert)'; Policy Framework WG; Andrea Westerinen > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > I agree with Bert that the title should reflect the contents. If the > title > is too broad it will not give any value to the contents since people will > assume that all terminology is defined there. The title should be > "Technical Policy Terminology" since it defines policy in technical terms, > mostly related to networks. Using just Policy Terminology would not be > correct since it doesn't define policy in a legal sense. > > > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, May 01, 2001 1:37 AM > To: Policy Framework WG; Andrea Westerinen > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > Inline > > > ---------- > > From: Andrea Westerinen[SMTP:andreaw@cisco.com] > > Sent: Tuesday, May 01, 2001 6:43 AM > > To: Wijnen, Bert (Bert); Policy Framework WG > > Subject: RE: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > Agreed. The title at the top of the pages is "Policy Terminology" but > the > > lead title is incorrect. Is "Policy Terminology" acceptable? > > > That is certainly better. Other titles we've used for this doc in the past > > An old one from Strassner/Ellesson (jun 1999) had the > title: > > Terminology for describing network policy and services > > Another one from March 2000 (Reichmeyer, Grossman, Strassner, > Condell) has the title: > > A Common Terminology for Policy Management > > In any event, the title should be such that we indicate for which "area" > or > "domain" we are trying to define the terminology. > Maybe a title like: > > A Common Terminology for Policy-based Management > > Bert > > > Andrea > > > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Wijnen, Bert (Bert) > > Sent: Monday, April 30, 2001 10:14 AM > > To: Policy Framework WG > > Subject: FW: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > > > I think Randy has a point here! > > > > Bert > > > > > ---------- > > > From: Randy Bush[SMTP:randy@psg.com] > > > Sent: Thursday, April 26, 2001 6:21 PM > > > To: Bert Wijnen > > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > > > > perhaps the title of this draft could be narrowed a bit. > > > > > > From: Internet-Drafts@ietf.org > > > To: IETF-Announce: ; > > > Cc: policy@raleigh.ibm.com > > > Subject: I-D ACTION:draft-ietf-policy-terminology-03.txt > > > Date: Thu, 26 Apr 2001 07:22:00 -0400 > > > > > > --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Policy Framework Working Group of the > > > IETF. > > > > > > Title : Terminology > > > Author(s) : A. Westerinen et al. > > > Filename : draft-ietf-policy-terminology-03.txt > > > Pages : 20 > > > Date : 25-Apr-01 > > > > > > This document is a glossary of policy-related terms. It > > > provides abbreviations, explanations, and recommendations for > > > use of these terms. The document takes the approach and format > > > of RFC2828 [R2828], which defines an Internet Security Glossary. > > > The intent is to improve the comprehensibility and consistency > > > of writing that deals with network policy, particularly Internet > > > Standards documents (ISDs). > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-policy-terminology-03.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-ietf-policy-terminology-03.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > --NextPart > > > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > > > > > --OtherAccess > > > Content-Type: Message/External-body; > > > access-type="mail-server"; > > > server="mailserv@ietf.org" > > > > > > Content-Type: text/plain > > > Content-ID: <20010425143032.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-ietf-policy-terminology-03.txt > > > > > > --OtherAccess > > > Content-Type: Message/External-body; > > > name="draft-ietf-policy-terminology-03.txt"; > > > site="ftp.ietf.org"; > > > access-type="anon-ftp"; > > > directory="internet-drafts" > > > > > > Content-Type: text/plain > > > Content-ID: <20010425143032.I-D@ietf.org> > > > > > > --OtherAccess-- > > > > > > --NextPart-- > > > > > > > > > ------- end of forwarded message ------- > > > > > > > > > > From majordomo@raleigh.ibm.com Fri May 4 21:53:47 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24506 for ; Fri, 4 May 2001 21:53:47 -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 VAA26886; Fri, 4 May 2001 21:48:03 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA20478; Fri, 4 May 2001 21:48:00 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43370; Fri, 4 May 2001 21:21:34 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA67416; Fri, 4 May 2001 21:21: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 VAA34906 for ; Fri, 4 May 2001 21:21:27 -0400 Received: from longmail2.lboard.com ([63.109.116.89]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA30930 for ; Fri, 4 May 2001 20:35:41 -0400 Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 20:35:23 -0400 Message-Id: From: Ed Ellesson To: "'policy@raleigh.ibm.com'" Cc: "'Wijnen, Bert (Bert)'" , "Joel M. Halpern" Subject: Policy WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Fri, 4 May 2001 20:35:22 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed Ellesson Policy Framework WG: Our AD has asked us to inform other relevant WG's that this WG Last Call is going on in our WG. This is to give these other WG's a chance for review and comments, because the terminology is also meant to be used in those WG's. Therefore, the Policy WG Last Call for this Terminology draft is hereby extended to end at CoB on Fri, May 18, 2001, rather than May 11, in order to give the other wg's time to respond. Extended WG Last Call: The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. The other wg's to which we are sending this last call, are as follows: DiffServ RAP IPSP SNMPCONF AAA AAAArch (IRTF) RSVP MPLS We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed Separate notes will be sent to each of these working groups, and their chairs. We apologize if you receive more than one similar notice. . Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group From majordomo@raleigh.ibm.com Sun May 6 10:45:03 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11193 for ; Sun, 6 May 2001 10:45:03 -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 KAA31874; Sun, 6 May 2001 10:39:10 -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 KAA37316; Sun, 6 May 2001 10:39:05 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43098; Sun, 6 May 2001 08:41:35 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA177866; Sun, 6 May 2001 08:41:27 -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 IAA28898 for ; Sun, 6 May 2001 08:41:32 -0400 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA22186 for ; Sun, 6 May 2001 08:40:41 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA04007 for ; Sun, 6 May 2001 05:40:21 -0700 (MST)] Received: [from zei02exm02.cork.cig.mot.com (zei02exm02.cork.cig.mot.com [175.3.80.202]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id FAA25967 for ; Sun, 6 May 2001 05:40:20 -0700 (MST)] Received: by zei02exm02.cork.cig.mot.com with Internet Mail Service (5.5.2651.58) id <2Z4060BW>; Sun, 6 May 2001 13:40:20 +0100 Message-Id: <13EE655665F4D311AB4D0008C789498A030BC52B@zei02exm02.cork.cig.mot.com> From: Nayak Sanjay-snayak01 To: "'policy@raleigh.ibm.com'" Subject: Comments for Policy Terminology Draft Date: Sun, 6 May 2001 13:40:10 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Nayak Sanjay-snayak01 On the latest draft-ietf-policy-terminology-03.txt, I have following comment : - The following terms have been used in other IETF docs such as draft-ietf-policy-req-02.txt (Requirements for a Policy Management System), draft-ietf-policy-framework-00.txt (Policy Framework - this is no more on the web site since it expired last year) and PCIM RFC 3060 : Policy Management Tool Policy Consumer Policy Target While "target" is defined in the draft-ietf-policy-terminology-03.txt, it would be useful to define the 3 terms above if they are still consistent with the PFWG's understanding of the framework. Regards, Sanjay. From majordomo@raleigh.ibm.com Mon May 7 17:41:58 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23058 for ; Mon, 7 May 2001 17:41:57 -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 RAA07666; Mon, 7 May 2001 17:35:54 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA37986; Mon, 7 May 2001 17:35:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23656; Mon, 7 May 2001 10:01:26 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46624; Mon, 7 May 2001 10:01:21 -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 KAA09864 for ; Mon, 7 May 2001 10:01:20 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA08660 for ; Mon, 7 May 2001 10:01:18 -0400 Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn2.cisco.com [171.68.12.75]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA24204; Mon, 7 May 2001 07:00:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20010507094258.01827428@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 10:00:30 -0400 To: Nayak Sanjay-snayak01 From: John Schnizlein Subject: Re: Comments for Policy Terminology Draft Cc: "'policy@raleigh.ibm.com'" In-Reply-To: <13EE655665F4D311AB4D0008C789498A030BC52B@zei02exm02.cork.c ig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein Sanjay, These terms were part of an architectural model that failed to reach consensus in the WG. There was explicit discussion that resulted in a consensus that the terminology draft is not the correct place to define a presumptive architecture (especially where consensus on the architecture was not reached). Definitions that referenced expired drafts were intentionally deleted. Where the Policy Consumer reference remains in (p 87) RFC 3060, it can be understood in context. John At 08:40 AM 5/6/2001, Nayak Sanjay-snayak01 wrote: >On the latest draft-ietf-policy-terminology-03.txt, I have following comment : > >- The following terms have been used in other IETF docs such as draft-ietf-policy-req-02.txt (Requirements for a Policy Management System), draft-ietf-policy-framework-00.txt (Policy Framework - this is no more on the web site since it expired last year) and PCIM RFC 3060 : > Policy Management Tool > Policy Consumer > Policy Target > >While "target" is defined in the draft-ietf-policy-terminology-03.txt, it would be useful to define the 3 terms above if they are still consistent with the PFWG's understanding of the framework. > >Regards, >Sanjay. From majordomo@raleigh.ibm.com Mon May 7 21:07:51 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25691 for ; Mon, 7 May 2001 21:07:50 -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 VAA32304; Mon, 7 May 2001 21:01:03 -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 VAA02616; Mon, 7 May 2001 21:00:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27630; Mon, 7 May 2001 20:33:44 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36326; Mon, 7 May 2001 20:33:41 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id UAA02726 for ; Mon, 7 May 2001 20:33:40 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA22618 for ; Mon, 7 May 2001 20:33:39 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f480WNQ18388; Mon, 7 May 2001 17:32:23 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AKK00040; Mon, 7 May 2001 17:32:12 -0700 (PDT) From: "Andrea Westerinen" To: "Guus Sliepen" , Cc: "AAAARCH mailing list" Subject: RE: Comments on draft-ietf-policy-terminology-03.txt Date: Mon, 7 May 2001 17:33:40 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010507164917.R315@sliepen.warande.net> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Thanks for the comments. Replies inline. Andrea -----Original Message----- From: owner-aaaarch@fokus.gmd.de [mailto:owner-aaaarch@fokus.gmd.de]On Behalf Of Guus Sliepen Sent: Monday, May 07, 2001 7:49 AM To: policy@raleigh.ibm.com Cc: AAAARCH mailing list Subject: Comments on draft-ietf-policy-terminology-03.txt Hello, We've been asked by Ed Elleson to review your terminology draft since it's in Last Call. I've send a subscribtion request for the policy mailing list but since I haven't received a confirmation yet, please CC me if you reply to this. $ Authentication, Authorization, Accounting (AAA) (A) AAA efforts in the IETF have focused on the most widely deployed use of authentication: Remote Authentication Dial In User Service (RADIUS), and its expansion in Diameter (a [...] This is not a definition of the term "AAA". But since this document is all about AAA, maybe the term itself should be explained as well. We purposely did not try to define AAA since we only talk about AAA as an area of use. Aspects of policy and AAA can exist without the other. My concern is that the definition of AAA should reside with the AAA WG, not with the Policy WG or its terminology document. $ Differentiated Services (DS) (T) The IP header field, called the DS-field. In IPv4, it defines the layout of the ToS (Type of Service) octet; in IPv6, it is the Traffic Class octet. [R2474] This is only a very specific part of DS. There is also routing based on for example source IP or protocol type/port number. This definition appears to me as if what you describe is the only thing to DS. There is also an "(A)" (area of use) documented in the definition and a pointer to "Quality of Service." Again, our definition takes its lead from the DiffServ WG's documents and charter. That said, the definition could be expanded as follows: (A) "Differentiated Services" is also an "area of use" for QoS policies. It requires policy to define the correspondence between codepoints in the packet's DS-field and individual per-hop behaviors (to achieve a specified per-domain behavior). In addition, policy can be used to specify the routing of packets based on various classification criteria. (See also "Quality of Service" and "filter.") The sentence before "(See also ..." is added, also the reference to "filter" is added. And, we would have to add a similar sentence to the definition of "Quality of Service." $ information model (T) An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, application, protocol, or platform. I think you mean "implementation" instead of "application". QoS for example, is an application. "Application" refers to "software usage". Repositories, software that uses the model, protocols and platforms are all "implementations." I can change the wording to "software usage", if this is clearer. $ policy condition (P) A representation of the necessary state and/or [...] - In [R3060], a rule's conditions can be expressed as either an ORed set of ANDed sets of statements (disjunctive normal form), or an ANDed set of ORed sets of statements (conjunctive normal form). Individual condition statements can also be negated. I think the second part of this definition should be labeled with a (T). Agreed. $ policy enforcement (P) The execution of a policy decision. Shouldn't that be the execution of the actions related to a policy decision? A "policy decision" is the resultant set of actions. The definition for policy decision reads: $ policy decision (P) Two perspectives of "policy decision" exist: - A "process" perspective that deals with the evaluation of a policy rule's conditions - A "result" perspective that deals with the actions for enforcement, when the conditions of a policy rule are TRUE The decision and enforcement definitions are coupled. $ Service Level Specification (SLS) (P) Specifies handling of a customer's traffic by a network provider. It is negotiated between a customer and the provider, and defines DiffServ parameters (such as specific Code Points and Per-Hop-Behaviors, profile characteristics and treatment of the traffic for those Code Points). [...] Policies can also be about other things than QoS, I think you shouldn't mention the part about DiffServ. I know you are doing lots of QoS specific things, but this is still is the Policy Terminolgy draft from the Policy Framework WG :). The major focus of the Policy Framework WG was/is QoS. That is the reason behind this focus in the terminology draft. However, we could address your concern/comment by modifying the definition slightly to read (changes in CAPS): (P) Specifies handling of a customer's traffic by a network provider. It is negotiated between a customer and the provider, and (FOR EXAMPLE) IN A DIFFSERV ENVIRONMENT, defines parameters such as specific Code Points and Per-Hop-Behaviors, profile characteristics and treatment of the traffic for those Code Points. [...] ------------------------------------------- Met vriendelijke groet / with kind regards, Guus Sliepen ------------------------------------------- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ ------------------------------------------- From majordomo@raleigh.ibm.com Tue May 8 06:52:15 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18594 for ; Tue, 8 May 2001 06:52:14 -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 GAA21870; Tue, 8 May 2001 06:46:32 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA32558; Tue, 8 May 2001 06:46:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61896; Tue, 8 May 2001 06:04:03 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA61356; Tue, 8 May 2001 06:03:57 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA04244 for ; Tue, 8 May 2001 06:03:56 -0400 Received: from leeloo.ipg.pt (leeloo.ipg.pt [193.137.232.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id GAA28012 for ; Tue, 8 May 2001 06:03:51 -0400 Received: from jaguar (unverified [193.137.232.8]) by leeloo.ipg.pt (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 08 May 2001 11:04:38 +0100 From: "Vitor Roque" To: "IETF DiffServ Mailing List" , "IETF Policy Mailing List" , Subject: API for COPS Date: Tue, 8 May 2001 11:03:06 +0100 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Vitor Roque" Content-Transfer-Encoding: 7bit Dear Sirs, I'm a PhD student at University of Aveiro. I would like to know if there are API's for COPS and where i can find it for testing. Thanks in advance Best Regards V.Roque --- Vitor Manuel Gomes Roque Instituto Politecnico da Guarda Tel. +351.271 222 634 Departamento de Informatica Fax. +351.271 220 150 Av. Dr. Francisco Sa Carneiro, 50 6300-559 Guarda - PORTUGAL email: vroque@ipg.pt Home Page: http://www.ipg.pt/user/estg/~vroque From majordomo@raleigh.ibm.com Tue May 8 10:16:56 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23701 for ; Tue, 8 May 2001 10:16:56 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22420; Tue, 8 May 2001 10:09:00 -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 KAA39050; Tue, 8 May 2001 10:08:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38190; Tue, 8 May 2001 09:18:59 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44326; Tue, 8 May 2001 09:18:56 -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 JAA32768 for ; Tue, 8 May 2001 09:18:15 -0400 Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id JAA29414 for ; Tue, 8 May 2001 09:17:34 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id JAA07681; Tue, 8 May 2001 09:15:46 -0400 Message-Id: <200105081315.JAA07681@zcars0m9.nortelnetworks.com> Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 8 May 2001 09:15:28 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KHAN7R8D; Tue, 8 May 2001 09:15:29 -0400 Received: from tweedy (dhcp223-142.engeast.baynetworks.com [192.32.223.142]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9F3QYV; Tue, 8 May 2001 09:15:29 -0400 X-Sender: khchan@zbl6c000.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 08 May 2001 09:14:16 -0400 To: Vitor Roque X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: [Diffserv] API for COPS Cc: IETF DiffServ Mailing List , IETF Policy Mailing List , diffserv-interest , rap@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Kwok-Ho Chan" Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From majordomo@raleigh.ibm.com Tue May 8 12:32:55 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00854 for ; Tue, 8 May 2001 12:32:54 -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 MAA36020; Tue, 8 May 2001 12:24:51 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA33238; Tue, 8 May 2001 12:24:52 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA67616; Tue, 8 May 2001 11:50:18 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA65532; Tue, 8 May 2001 11:50:14 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA35742 for ; Tue, 8 May 2001 11:50:13 -0400 Received: from fridge.docomo-usa.com ([216.98.102.228]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA17918 for ; Tue, 8 May 2001 11:50:03 -0400 Received: from DCLNTAS1 (dhcp34.docomo-usa.com [172.21.96.34]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f48Ftfq28149; Tue, 8 May 2001 08:55:41 -0700 (PDT) From: "Alexander Hagen" To: "'Kwok-Ho Chan'" , "'Vitor Roque'" Cc: "'IETF DiffServ Mailing List'" , "'IETF Policy Mailing List'" , "'diffserv-interest'" , Subject: RE: [Diffserv] API for COPS Date: Tue, 8 May 2001 08:47:54 -0700 Message-Id: <004b01c0d7d6$49a46e60$226015ac@DCLNTAS1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200105081315.JAA07681@zcars0m9.nortelnetworks.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Alexander Hagen" Content-Transfer-Encoding: 7bit Personal Opinion: Check out: http://www.networkcomputing.com/1024/1024f1.html A little dated but perhaps a good starting point. For my two cents, Cisco (QPM-COPS), Nortel (Optivity) and Intel (COPS SDK) all have COPS implementations worth looking at. Cisco and Nortels take advantage of LDAP (W2K AD, NDS, Iplanet/Netscape) while Intels SDK offers source code and Linux support. Alexander Hagen Senior Research Engineer: Development DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) 181 Metro Drive, Suite 300, San Jose, CA 95110, USA TEL :+1-408-573-1050 (Main) FAX : +1-408-573-1090 (Main) TEL: +1-408-451-4706 (Direct) E-mail: ahagen@dcl.docomo-usa.com Web: -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Kwok-Ho Chan Sent: Tuesday, May 08, 2001 6:14 AM To: Vitor Roque Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; diffserv-interest; rap@ops.ietf.org Subject: Re: [Diffserv] API for COPS Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From majordomo@raleigh.ibm.com Tue May 8 13:49:26 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03157 for ; Tue, 8 May 2001 13:49:25 -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 NAA15710; Tue, 8 May 2001 13:37:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA36628; Tue, 8 May 2001 13:37:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28956; Tue, 8 May 2001 13:10:01 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31764; Tue, 8 May 2001 13:09:57 -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 NAA24892 for ; Tue, 8 May 2001 13:09:56 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA20764 for ; Tue, 8 May 2001 13:09:50 -0400 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f48H9Tn15829; Tue, 8 May 2001 10:09:29 -0700 (PDT) Received: from JSALOWEY-W2K.cisco.com (dhcp-128-107-131-41.cisco.com [128.107.131.41]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABC02240; Tue, 8 May 2001 10:08:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20010508095813.00b12958@mira-sjc5-6.cisco.com> X-Sender: jsalowey@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 May 2001 10:05:08 -0700 To: aaaarch@fokus.gmd.de, policy@raleigh.ibm.com From: Joseph Salowey Subject: Comments on Policy Terminology Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Joseph Salowey The draft looks good, but there are a few areas that confuse me. $policy request I was a little confused by this definition, perhaps is would be good to add something like "A policy request may also refer to the retrieval of policy rules pertaining to a specific situation." This definition should probably user "policy server" instead of "policy service" to be consistent with other definitions. $role I find the third definition of a role confusing. Can a managed element be something that is accessing a resource such as a user? If it is then explicitly stating so may help clarify things. If it isn't then I think the definition is missing something. Additionally a role can be a dynamic characteristic. $role combination I also find role combination confusing especially "That determination may examine all applicable policy rules identified by the role combination, its sub-combinations and the individual roles in the combination, or may require that PRCs explicitly match the role combination specified for the managed element." What does it mean for PRC's to explicitly match the role combination? Perhaps this usage of role and role combination is implementation specific, do you have a reference in mind? Thanks, Joe From majordomo@raleigh.ibm.com Tue May 8 14:29:26 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04187 for ; Tue, 8 May 2001 14:29:25 -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 OAA17748; Tue, 8 May 2001 14:22:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA38340; Tue, 8 May 2001 14:22:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA04012; Tue, 8 May 2001 13:50:33 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31636; Tue, 8 May 2001 13:50:29 -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 NAA39034 for ; Tue, 8 May 2001 13:50:29 -0400 Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA25268 for ; Tue, 8 May 2001 13:50:22 -0400 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id RAA27776; Tue, 8 May 2001 17:50:11 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 May 2001 17:50:05 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 10:50:03 -0700 Message-Id: <4148FEAAD879D311AC5700A0C969E8900655DCF9@orsmsx35.jf.intel.com> From: "Hegde, Shriharsha" To: Vitor Roque Cc: IETF Policy Mailing List , rap@ops.ietf.org Subject: RE: API for COPS Date: Tue, 8 May 2001 10:49:59 -0700 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Hegde, Shriharsha" Client (PEP) side SDK is open sourced at http://www.intel.com/ial/cops -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Tuesday, May 08, 2001 6:14 AM To: Vitor Roque Cc: IETF DiffServ Mailing List; IETF Policy Mailing List; diffserv-interest; rap@ops.ietf.org Subject: Re: [Diffserv] API for COPS Thank you for your interest in using COPS. Currently only the protocol aspects is been standardized. Of course that most implementations use an API, but this is not exposed since the environments in the PEPs have real-time requirements, and the PDPs' user access is mostly from a GUI and DataBase. Some vendors may sell a developer's kit for COPS, but I will let them respond to your E-Mail. I think this E-Mail thread doesn't belong in the DiffServ list. This is a topic belonging to the RAP working group E-Mail list. I have added rap to the CC list above. Please remove DiffServ from the CC list after this message, else Brian will send you a message. :) -- Kwok Ho Chan -- At 11:03 AM 5/8/01 +0100, Vitor Roque wrote: >Dear Sirs, > >I'm a PhD student at University of Aveiro. I would like to know if there are >API's for COPS and where i can find it for testing. > >Thanks in advance >Best Regards >V.Roque > >--- >Vitor Manuel Gomes Roque > >Instituto Politecnico da Guarda Tel. +351.271 222 634 >Departamento de Informatica Fax. +351.271 220 150 >Av. Dr. Francisco Sa Carneiro, 50 >6300-559 Guarda - PORTUGAL email: vroque@ipg.pt >Home Page: http://www.ipg.pt/user/estg/~vroque > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >http://www1.ietf.org/mailman/listinfo/diffserv >Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml > From majordomo@raleigh.ibm.com Wed May 9 15:04:35 2001 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21768 for ; Wed, 9 May 2001 15:04:34 -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 OAA31106; Wed, 9 May 2001 14:56:43 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA31980; Wed, 9 May 2001 14:56:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40208; Wed, 9 May 2001 14:27:40 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA64520; Wed, 9 May 2001 14:27:37 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA23350 for ; Wed, 9 May 2001 14:27:37 -0400 Received: from longsys.com (dmz.longsys.com [63.111.150.5]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA25882 for ; Wed, 9 May 2001 14:27:27 -0400 Received: from joel (discordian.longsys.com [63.111.150.74]) by longsys.com (8.10.0/8.10.0) with ESMTP id f49IR0q27680 for ; Wed, 9 May 2001 18:27:00 GMT Message-Id: <4.2.2.20010509142405.00c58990@localhost> X-Sender: joel@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 09 May 2001 14:26:37 -0400 To: policy@raleigh.ibm.com From: "Joel M. Halpern" Subject: Documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Joel M. Halpern" We now have revisions to PCIMe draft-ietf-policy-pcim-ext-01.txt, QPIM draft-ietf-policy-qos-info-model-03.txt, and QDDIM draft-ietf-policy-qos-device-info-model-03.txt available. Firstly, thank you to the various author teams and particularly the document editors for getting these out. While it is true that the various overlapping groups of authors are working on the holes in each document and the consistency questions between documents, we really need input from the working group. Please look at these documents and comment on the list. Thank you, Joel M. Halpern From majordomo@raleigh.ibm.com Fri May 11 12:42:55 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15029 for ; Fri, 11 May 2001 12:42:54 -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 MAA34342; Fri, 11 May 2001 12:33: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 MAA10376; Fri, 11 May 2001 12:30:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA63282; Fri, 11 May 2001 11:57:59 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA63260; Fri, 11 May 2001 11:57:56 -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 LAA35874 for ; Fri, 11 May 2001 11:57:55 -0400 Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA33744 for ; Fri, 11 May 2001 11:57:54 -0400 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 May 2001 17:57:52 +0100 Message-Id: <03ADBFD12399D3119C2800508B0C66D201718585@g04.research.kpn.com> From: "Jonatan, T.H." To: "'policy@raleigh.ibm.com'" Subject: Comments on Policy Terminology Date: Fri, 11 May 2001 17:57:51 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jonatan, T.H." Hi, I find the definition about SLA, SLS and SLO are somewhat confusing. $ Service Level Agreement (SLA) (P) The documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service. (See also "Service Level Objective.") [R2475] $ Service Level Objective (SLO) (P) Partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA. "Service Level Objectives" may be defined as part of an SLA, or in a separate document. It is a set of parameters and their values. The actions of enforcing and reporting monitored compliance can be implemented as one or more policies. (See also "Service Level Agreement.") IMHO SLO can both exist in SLA and SLS but the way it is presented in SLA and SLS is different (i.e. business-oriented way as oppose to technical oriented way). $ Service Level Specification (SLS) (P) Specifies handling of a customer's traffic by a network provider. It is negotiated between a customer and the provider, and defines DiffServ parameters (such as specific Code Points and Per-Hop-Behaviors, profile characteristics and treatment of the traffic for those Code Points). An SLS is a combination of an SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce). (See also "Service Level Agreement" and "Service Level Objective.") This definition is confusing because: SLA defitinion gives an impression that SLA is the whole thing about the service written in business oriented perspective while SLS definition gives an impression as if it is a technical interpretation of SLA (as operational guideline for traffic handling). But then it mentions that SLS is "a combination between" SLA and SLO which suggest that SLS is the whole thing. So is SLS bigger than SLA or the other way around or they both at the same level but address different perspective? Regards, Tjaja From majordomo@raleigh.ibm.com Fri May 11 12:46:46 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15148 for ; Fri, 11 May 2001 12:46:45 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA24984; Fri, 11 May 2001 12:34:03 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA30608; Fri, 11 May 2001 12:30:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35722; Fri, 11 May 2001 11:52:12 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41346; Fri, 11 May 2001 11:52:08 -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 LAA39284 for ; Fri, 11 May 2001 11:52:08 -0400 Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id LAA31510 for ; Fri, 11 May 2001 11:52:07 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id LAA19344; Fri, 11 May 2001 11:51:32 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 11 May 2001 11:51:15 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTDDQXK6; Fri, 11 May 2001 11:51:15 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JVC0W2FQ; Fri, 11 May 2001 11:51:18 -0400 Message-Id: <3AFC09A0.8E7CF078@americasm01.nt.com> Date: Fri, 11 May 2001 11:47:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy Subject: Re: Result of the compoundPolicyAction References: <3AE48F16.FF171888@americasm01.nt.com> <3AE58EE9.4D3BEF5D@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit Do the PCIMe authors have any opinion wrt. this subject? Here is an example to support the case 2. below. The following NAT rule "in the packets from 10.10.10.10, change *both* the source addr. and the source port or, if any of the above fails then drop the packet" could be implemented as follows: Rule: If SourceIP=10.10.10.10 then (ordered, Do_until_success): Action_1(compound, unordered, Do_all): Action_1_1(simple): Set SourceIP to 1.2.3.4 Action_1_2(simple): Set SourcePort to 2001 Action_2: Drop packet Action_1 (compound, Do_all) should be considered successful only if both Action_1_1 and Action_1_2 are successful. Then Action_2 is not executed. If either Action_1_1 or Action_1_2 fails, then Action_1 should be considered failed and Action_2 should be executed. Thank You, Mircea. > > The result of the execution of a compoundPolicyAction (success or > > failure) is important for the execution strategy of the aggregating > > policyRules or compoundPolicyAction. To avoid ambiguity, it may be good > > to add a clarification to the next release of PCIMe. > > > > A suggestion might be: > > > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: > > The compoundPolicyAction is successful if an aggregated policyAction is > > successful. If all the aggregated policyActions fail, then the > > aggregating compoundPolicyAction is considered failed. > > > > 2. For compoundPolicyAction.executionStrategy=Do_All: > > The compoundPolicyAction is successful if all the aggregated > > policyActions are successful. If one or more aggregated policyActions > > fail, then the aggregating compoundPolicyAction is considered failed. > > > > (2bis. An alternative to 2 might be: > > The compoundPolicyAction is successful if one or more aggregated > > policyActions are successful. If all the aggregated policyActions fail, > > then the aggregating compoundPolicyAction is considered failed. > > If both 2. and 2bis are applicable in various situations then it may be > > useful to add a "Do_Any" execution strategy?) > > > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: > > The compoundPolicyAction is successful if one or more aggregated > > policyActions are successful. If the first attempt to execute an > > aggregated policyAction fails, then the aggregating compoundPolicyAction > > is considered failed. > > > > Regards, > > Mircea. > > > > P.S. BTW in PCIMe-01, the example at the end of the paragraph "4.7.2 > > Compound Policy Actions" uses the retired "Mandatory Do All" decision > > strategy. For consistency with the rest of the document, this should be > > corrected. From majordomo@raleigh.ibm.com Fri May 11 18:19:04 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21938 for ; Fri, 11 May 2001 18:19:03 -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 SAA42912; Fri, 11 May 2001 18:08:14 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA10434; Fri, 11 May 2001 18:06:36 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45090; Fri, 11 May 2001 17:25:24 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39450; Fri, 11 May 2001 17:25:21 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA27954 for ; Fri, 11 May 2001 17:25:20 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA20902 for ; Fri, 11 May 2001 17:25:01 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4BLOE926205; Fri, 11 May 2001 14:24:15 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAL02759; Fri, 11 May 2001 14:24:12 -0700 (PDT) From: "Andrea Westerinen" To: "Angelos D. Keromytis" , "Ed Ellesson" , "Policy@Raleigh. Ibm. Com" Cc: "'Luis Sanchez'" , "Joel M. Halpern" , Subject: RE: IPSP WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Fri, 11 May 2001 14:26:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200105080320.f483KvX08190@nyarlathotep.keromytis.org> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Replying and also sending to the policy mail list ... Angelos, From my reading of the RFC, KeyNote is a specific implementation architecture and language for trust management. I agree that it is directly related to security, but policy is only part of the architecture. We do not describe specific policy implementations in the terminology draft, but focus instead on general policy terms and broad areas of use. Andrea -----Original Message----- From: Angelos D. Keromytis [mailto:angelos@keromytis.org] Sent: Monday, May 07, 2001 8:21 PM To: Ed Ellesson Cc: 'Luis Sanchez'; Joel M. Halpern; johns@cisco.com; andreaw@cisco.com Subject: Re: IPSP WG Notice: Policy Terminology Draft, Extended WG Last Call Since the Policy Terminology draft is supposed to be applicable to IPSP as well, I think this entry should be added: $ KeyNote (T) A system/language designed to express and evaluate security policies, credentials, and the trust relationships between users and entities that manage policies and domains. It is application-independent but can be (and has been) applied to different policy applications, such as IPsec, TLS, packet filtering, and executable content sandboxing. [R2704] And the biblio reference: [R2704] The KeyNote Trust Management System, Version 2. M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. September 1999. Cheers, -Angelos From majordomo@raleigh.ibm.com Fri May 11 18:43:13 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22316 for ; Fri, 11 May 2001 18:43:13 -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 SAA24870; Fri, 11 May 2001 18:38:08 -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 SAA35774; Fri, 11 May 2001 18:36:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA70084; Fri, 11 May 2001 17:55:03 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA65454; Fri, 11 May 2001 17:55:00 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA35532 for ; Fri, 11 May 2001 17:55:00 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA26980 for ; Fri, 11 May 2001 17:54:59 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4BLsYU11467; Fri, 11 May 2001 14:54:34 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAL03931; Fri, 11 May 2001 14:54:23 -0700 (PDT) From: "Andrea Westerinen" To: "Joseph Salowey" , , Subject: RE: Comments on Policy Terminology Date: Fri, 11 May 2001 14:56:20 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.3.2.7.2.20010508095813.00b12958@mira-sjc5-6.cisco.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Replies inline. Andrea -----Original Message----- From: owner-aaaarch@fokus.gmd.de [mailto:owner-aaaarch@fokus.gmd.de]On Behalf Of Joseph Salowey Sent: Tuesday, May 08, 2001 10:05 AM To: aaaarch@fokus.gmd.de; policy@raleigh.ibm.com Subject: Comments on Policy Terminology The draft looks good, but there are a few areas that confuse me. $policy request I was a little confused by this definition, perhaps is would be good to add something like "A policy request may also refer to the retrieval of policy rules pertaining to a specific situation." How about this for a definition? (Anything in CAPS is added.) ... (P) A message requesting a policy-RELATED service. THIS MAY REFER TO A REQUEST TO RETRIEVE A SPECIFIC SET OF POLICY RULES, TO DETERMINE THE ACTIONS TO ENFORCE, OR OTHER POLICY REQUESTS. When sent by a PEP to a PDP, it is more accurately qualified as a "policy decision request." [R2753] (See also "policy decision.") This definition should probably user "policy server" instead of "policy service" to be consistent with other definitions. We don't use the term "policy server" since its meaning varies widely. Please see our definition of this term. $role I find the third definition of a role confusing. Can a managed element be something that is accessing a resource such as a user? No. If it is then explicitly stating so may help clarify things. If it isn't then I think the definition is missing something. A person's Role is the first definition. The third definition is the use of an attribute called "Role" to label a rule. A "Role" is also assigned to entities such as devices, ports, interfaces, etc. When the "Role" on the rule and on the entity match, then it is assumed that the rule is applicable to the entity. This definition is used in SNMPCONF, PIBs and the policy model. Additionally a role can be a dynamic characteristic. Where it is restricted? $role combination I also find role combination confusing especially "That determination may examine all applicable policy rules identified by the role combination, its sub-combinations and the individual roles in the combination, or may require that PRCs explicitly match the role combination specified for the managed element." What does it mean for PRC's to explicitly match the role combination? PRCs do not allow sub-combinations of roles. Let me rephrase the sentence as (using CAPS for anything new) ... That determination may examine all applicable policy rules identified by the role combination, its sub-combinations and the individual roles in the combination. IN THE CASE OF PRCs, A PRC MUST EXPLICITLY MATCH THE ROLE COMBINATION OF THE MANAGED ELEMENT IN ORDER TO BE APPLICABLE AND/OR ENFORCED. Perhaps this usage of role and role combination is implementation specific, do you have a reference in mind? I will add a reference to the policy core model [RFC 3060]. The PRC work is still an I-D. Thanks, Joe From majordomo@raleigh.ibm.com Fri May 11 18:58:08 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22400 for ; Fri, 11 May 2001 18:58:08 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA26694; Fri, 11 May 2001 18:53:18 -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 SAA40864; Fri, 11 May 2001 18:50:14 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52500; Fri, 11 May 2001 18:07:47 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45282; Fri, 11 May 2001 18:07:39 -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 SAA27152 for ; Fri, 11 May 2001 18:07:38 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA10366 for ; Fri, 11 May 2001 18:07:11 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4BM55t07584; Fri, 11 May 2001 15:05:05 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAL04383; Fri, 11 May 2001 15:06:31 -0700 (PDT) From: "Andrea Westerinen" To: "Jonatan, T.H." , Subject: RE: Comments on Policy Terminology Date: Fri, 11 May 2001 15:08:28 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <03ADBFD12399D3119C2800508B0C66D201718585@g04.research.kpn.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Perhaps we could modify the problematic sentence slightly as follows ... An SLS is a specific SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce) to guarantee quality of service for network traffic. Andrea -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Jonatan, T.H. Sent: Friday, May 11, 2001 9:58 AM To: 'policy@raleigh.ibm.com' Subject: Comments on Policy Terminology Hi, I find the definition about SLA, SLS and SLO are somewhat confusing. $ Service Level Agreement (SLA) (P) The documented result of a negotiation between a customer/consumer and a provider of a service, that specifies the levels of availability, serviceability, performance, operation or other attributes of the service. (See also "Service Level Objective.") [R2475] $ Service Level Objective (SLO) (P) Partitions an SLA into individual metrics and operational information to enforce and/or monitor the SLA. "Service Level Objectives" may be defined as part of an SLA, or in a separate document. It is a set of parameters and their values. The actions of enforcing and reporting monitored compliance can be implemented as one or more policies. (See also "Service Level Agreement.") IMHO SLO can both exist in SLA and SLS but the way it is presented in SLA and SLS is different (i.e. business-oriented way as oppose to technical oriented way). $ Service Level Specification (SLS) (P) Specifies handling of a customer's traffic by a network provider. It is negotiated between a customer and the provider, and defines DiffServ parameters (such as specific Code Points and Per-Hop-Behaviors, profile characteristics and treatment of the traffic for those Code Points). An SLS is a combination of an SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce). (See also "Service Level Agreement" and "Service Level Objective.") This definition is confusing because: SLA defitinion gives an impression that SLA is the whole thing about the service written in business oriented perspective while SLS definition gives an impression as if it is a technical interpretation of SLA (as operational guideline for traffic handling). But then it mentions that SLS is "a combination between" SLA and SLO which suggest that SLS is the whole thing. So is SLS bigger than SLA or the other way around or they both at the same level but address different perspective? Regards, Tjaja From majordomo@raleigh.ibm.com Sat May 12 04:45:02 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14040 for ; Sat, 12 May 2001 04:45:01 -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 EAA19120; Sat, 12 May 2001 04:37:58 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA27986; Sat, 12 May 2001 04:35:48 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34758; Sat, 12 May 2001 03:49:08 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55310; Sat, 12 May 2001 03:49: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 DAA35692 for ; Sat, 12 May 2001 03:49:01 -0400 Received: from mail01.san.yahoo.com (mail01.san.yahoo.com [209.132.1.35]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA19978 for ; Sat, 12 May 2001 03:49:00 -0400 Received: from ntearb4s22b666 (62.0.180.41) by mail01.san.yahoo.com (5.1.062) id 3AEBC0F8006AE965; Sat, 12 May 2001 00:36:46 -0700 From: "Ron Cohen" To: "Mircea Pana" , "IETF Policy" Subject: RE: Result of the compoundPolicyAction Date: Sat, 12 May 2001 09:48:29 +0200 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AFC09A0.8E7CF078@americasm01.nt.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ron Cohen" Content-Transfer-Encoding: 7bit Mircea, This is exactly the purpose of execution strategy. I understand that you think that this tool is needed in the PCIMe. The authors where not fully in agreement whether this is a required feature and whether policy entities (PEPs and PDPs) would be able to implement this. The issue was that some interpreted this to mean do action_1_1, and if you fail to do so, undo the operation (which is not always possible), while others (including me) interpreted this as first check that you can do action_1_1 and action_1_2, if you can not do both don't do either one and move on to action 2. Ron > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mircea Pana > Sent: Friday, May 11, 2001 5:48 PM > To: IETF Policy > Subject: Re: Result of the compoundPolicyAction > > > Do the PCIMe authors have any opinion wrt. this subject? > > Here is an example to support the case 2. below. The following NAT rule > > "in the packets from 10.10.10.10, > change *both* the source addr. > and the source port or, > if any of the above fails > then drop the packet" > > could be implemented as follows: > > Rule: If SourceIP=10.10.10.10 then (ordered, Do_until_success): > Action_1(compound, unordered, Do_all): > Action_1_1(simple): Set SourceIP to 1.2.3.4 > Action_1_2(simple): Set SourcePort to 2001 > Action_2: Drop packet > > Action_1 (compound, Do_all) should be considered successful only if both > Action_1_1 and Action_1_2 are successful. Then Action_2 is not executed. > If either Action_1_1 or Action_1_2 fails, then Action_1 should be > considered failed and Action_2 should be executed. > > Thank You, > Mircea. > > > > > The result of the execution of a compoundPolicyAction (success or > > > failure) is important for the execution strategy of the aggregating > > > policyRules or compoundPolicyAction. To avoid ambiguity, it > may be good > > > to add a clarification to the next release of PCIMe. > > > > > > A suggestion might be: > > > > > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: > > > The compoundPolicyAction is successful if an aggregated > policyAction is > > > successful. If all the aggregated policyActions fail, then the > > > aggregating compoundPolicyAction is considered failed. > > > > > > 2. For compoundPolicyAction.executionStrategy=Do_All: > > > The compoundPolicyAction is successful if all the aggregated > > > policyActions are successful. If one or more aggregated policyActions > > > fail, then the aggregating compoundPolicyAction is considered failed. > > > > > > (2bis. An alternative to 2 might be: > > > The compoundPolicyAction is successful if one or more aggregated > > > policyActions are successful. If all the aggregated > policyActions fail, > > > then the aggregating compoundPolicyAction is considered failed. > > > If both 2. and 2bis are applicable in various situations then > it may be > > > useful to add a "Do_Any" execution strategy?) > > > > > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: > > > The compoundPolicyAction is successful if one or more aggregated > > > policyActions are successful. If the first attempt to execute an > > > aggregated policyAction fails, then the aggregating > compoundPolicyAction > > > is considered failed. > > > > > > Regards, > > > Mircea. > > > > > > P.S. BTW in PCIMe-01, the example at the end of the paragraph "4.7.2 > > > Compound Policy Actions" uses the retired "Mandatory Do All" decision > > > strategy. For consistency with the rest of the document, this > should be > > > corrected. From majordomo@raleigh.ibm.com Mon May 14 14:23:33 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20603 for ; Mon, 14 May 2001 14:23: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 OAA28182; Mon, 14 May 2001 14:17:33 -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 OAA34484; Mon, 14 May 2001 14:17:29 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56008; Mon, 14 May 2001 13:32:30 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA58786; Mon, 14 May 2001 13:32:26 -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 NAA18944 for ; Mon, 14 May 2001 13:32:25 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA10010 for ; Mon, 14 May 2001 13:32:23 -0400 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4EHVpd06136; Mon, 14 May 2001 10:31:52 -0700 (PDT) Received: from JSALOWEY-W2K.cisco.com (sjc-vpn-597.cisco.com [10.21.66.85]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ABF54200; Mon, 14 May 2001 10:31:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20010514101446.00b797b8@mira-sjc5-6.cisco.com> X-Sender: jsalowey@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 May 2001 10:28:34 -0700 To: "Andrea Westerinen" From: Joseph Salowey Subject: RE: Comments on Policy Terminology Cc: , In-Reply-To: References: <4.3.2.7.2.20010508095813.00b12958@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Joseph Salowey Comments in line Thanks, Joe >The draft looks good, but there are a few areas that confuse me. > >$policy request > >I was a little confused by this definition, perhaps is would be good to add >something like > >"A policy request may also refer to the retrieval of policy rules >pertaining to a specific situation." > > How about this for a definition? (Anything in CAPS is added.) ... > (P) A message requesting a policy-RELATED service. THIS MAY REFER > TO A REQUEST TO RETRIEVE A SPECIFIC SET OF POLICY RULES, TO > DETERMINE THE ACTIONS TO ENFORCE, OR OTHER POLICY REQUESTS. > When sent by a PEP to a PDP, it is more accurately qualified > as a "policy decision request." [R2753] (See also "policy > decision.") > >This definition should probably user "policy server" instead of "policy >service" to be consistent with other definitions. > > We don't use the term "policy server" since its meaning varies widely. >Please see our definition of this term. This helps. >$role > >I find the third definition of a role confusing. Can a managed element be >something that is accessing a resource such as a user? > > No. > >If it is then >explicitly stating so may help clarify things. If it isn't then I think >the definition is missing something. > > A person's Role is the first definition. The third definition is the >use of an attribute called "Role" to label a rule. A "Role" is also >assigned to entities such as devices, ports, interfaces, etc. When the >"Role" on the rule and on the entity match, then it is assumed that the rule >is applicable to the entity. This definition is used in SNMPCONF, PIBs and >the policy model. I like the simpler role definition in RFC 3060, but I can see what you are trying to convey. I think If you add a reference to RFC 3060 it will help greatly. >Additionally a role can be a dynamic characteristic. > > Where it is restricted? > > >$role combination > >I also find role combination confusing especially "That determination may >examine all applicable policy rules identified by the role combination, its >sub-combinations and the individual roles in the combination, or may >require that PRCs explicitly match the role combination specified for the >managed element." > >What does it mean for PRC's to explicitly match the role combination? > > PRCs do not allow sub-combinations of roles. Let me rephrase the >sentence as (using CAPS for anything new) ... > That determination may examine all applicable policy rules > identified by the role combination, its sub-combinations > and the individual roles in the combination. IN THE CASE OF > PRCs, A PRC MUST EXPLICITLY MATCH THE ROLE COMBINATION OF > THE MANAGED ELEMENT IN ORDER TO BE APPLICABLE AND/OR ENFORCED. This helps. >Perhaps this usage of role and role combination is implementation specific, >do you have a reference in mind? > > I will add a reference to the policy core model [RFC 3060]. The PRC >work is still an I-D. > >Thanks, > >Joe From majordomo@raleigh.ibm.com Wed May 16 03:06:11 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00690 for ; Wed, 16 May 2001 03:06:09 -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 CAA17862; Wed, 16 May 2001 02:58:03 -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 CAA32640; Wed, 16 May 2001 02:58:33 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57980; Wed, 16 May 2001 01:36:36 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35700; Wed, 16 May 2001 01:36:31 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA39526 for ; Wed, 16 May 2001 01:36:31 -0400 Received: from mail01.san.yahoo.com (mail01.san.yahoo.com [209.132.1.35]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA41692 for ; Wed, 16 May 2001 01:35:55 -0400 Received: from ntearb4s22b666 (62.0.182.97) by mail01.san.yahoo.com (5.1.062) id 3AEBC0F800858A04; Tue, 15 May 2001 22:27:47 -0700 From: "Ron Cohen" To: Cc: "Mircea Pana" , "IETF Policy" Subject: RE: Result of the compoundPolicyAction Date: Wed, 16 May 2001 07:39:30 +0200 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <989976444.3b01d77c87c26@citadel.mobility.ccrle.nec.de> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ron Cohen" Content-Transfer-Encoding: 7bit > > My first question is what means Action 1 fails > (a) both A1_1 and A1_2 fails > (b) A1_1 or A1_2 fails (b) - since the executuion strategy for A1 is do-all > Second thing, Ron you assume that we can check whether an action > is possible to > perform, before performing the action. E.g., the case of RSVP, > where you setup a > guaranteed path, you find out whether there is enough resource > available by > performing the setup action. However, I have to admit, that the > action is not so > difficult to rollback. So either one, either check before or rollback if this is possible Ron > > Marcus > > Zitiere Ron Cohen : > > > Mircea, > > > > This is exactly the purpose of execution strategy. I understand that > > you > > think that this tool is needed in the PCIMe. The authors where not fully > > in > > agreement whether this is a required feature and whether policy > > entities > > (PEPs and PDPs) would be able to implement this. The issue was that > > some > > interpreted this to mean do action_1_1, and if you fail to do so, undo > > the > > operation (which is not always possible), while others (including me) > > interpreted this as first check that you can do action_1_1 and > > action_1_2, > > if you can not do both don't do either one and move on to action 2. > > > > Ron > > > > > -----Original Message----- > > > From: policy-owner@raleigh.ibm.com > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mircea Pana > > > Sent: Friday, May 11, 2001 5:48 PM > > > To: IETF Policy > > > Subject: Re: Result of the compoundPolicyAction > > > > > > > > > Do the PCIMe authors have any opinion wrt. this subject? > > > > > > Here is an example to support the case 2. below. The following NAT > > rule > > > > > > "in the packets from 10.10.10.10, > > > change *both* the source addr. > > > and the source port or, > > > if any of the above fails > > > then drop the packet" > > > > > > could be implemented as follows: > > > > > > Rule: If SourceIP=10.10.10.10 then (ordered, Do_until_success): > > > Action_1(compound, unordered, Do_all): > > > Action_1_1(simple): Set SourceIP to 1.2.3.4 > > > Action_1_2(simple): Set SourcePort to 2001 > > > Action_2: Drop packet > > > > > > Action_1 (compound, Do_all) should be considered successful only if > > both > > > Action_1_1 and Action_1_2 are successful. Then Action_2 is not > > executed. > > > If either Action_1_1 or Action_1_2 fails, then Action_1 should be > > > considered failed and Action_2 should be executed. > > > > > > Thank You, > > > Mircea. > > > > > > > > > > > The result of the execution of a compoundPolicyAction (success or > > > > > failure) is important for the execution strategy of the > > aggregating > > > > > policyRules or compoundPolicyAction. To avoid ambiguity, it > > > may be good > > > > > to add a clarification to the next release of PCIMe. > > > > > > > > > > A suggestion might be: > > > > > > > > > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: > > > > > The compoundPolicyAction is successful if an aggregated > > > policyAction is > > > > > successful. If all the aggregated policyActions fail, then the > > > > > aggregating compoundPolicyAction is considered failed. > > > > > > > > > > 2. For compoundPolicyAction.executionStrategy=Do_All: > > > > > The compoundPolicyAction is successful if all the aggregated > > > > > policyActions are successful. If one or more aggregated > > policyActions > > > > > fail, then the aggregating compoundPolicyAction is considered > > failed. > > > > > > > > > > (2bis. An alternative to 2 might be: > > > > > The compoundPolicyAction is successful if one or more aggregated > > > > > policyActions are successful. If all the aggregated > > > policyActions fail, > > > > > then the aggregating compoundPolicyAction is considered failed. > > > > > If both 2. and 2bis are applicable in various situations then > > > it may be > > > > > useful to add a "Do_Any" execution strategy?) > > > > > > > > > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: > > > > > The compoundPolicyAction is successful if one or more aggregated > > > > > policyActions are successful. If the first attempt to execute an > > > > > aggregated policyAction fails, then the aggregating > > > compoundPolicyAction > > > > > is considered failed. > > > > > > > > > > Regards, > > > > > Mircea. > > > > > > > > > > P.S. BTW in PCIMe-01, the example at the end of the paragraph > > "4.7.2 > > > > > Compound Policy Actions" uses the retired "Mandatory Do All" > > decision > > > > > strategy. For consistency with the rest of the document, this > > > should be > > > > > corrected. > > > > > From majordomo@raleigh.ibm.com Wed May 16 14:54:26 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16872 for ; Wed, 16 May 2001 14:54:24 -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 OAA23784; Wed, 16 May 2001 14:46:50 -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 OAA35318; Wed, 16 May 2001 14:47:18 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA58468; Wed, 16 May 2001 13:53:07 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41564; Wed, 16 May 2001 13:53:04 -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 NAA24076 for ; Wed, 16 May 2001 13:53:04 -0400 Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id NAA16674 for ; Wed, 16 May 2001 13:52:26 -0400 Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id NAA22291; Wed, 16 May 2001 13:52:21 -0400 Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 16 May 2001 13:52:10 -0400 Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KTD1CGL9; Wed, 16 May 2001 13:52:12 -0400 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.214.95]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KZY42RG8; Wed, 16 May 2001 13:52:14 -0400 Message-Id: <3B02BD66.B5504B2E@americasm01.nt.com> Date: Wed, 16 May 2001 13:48:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: Ron Cohen Cc: "Marcus.Brunner" , IETF Policy Subject: Re: Result of the compoundPolicyAction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Mircea Pana" Content-Transfer-Encoding: 7bit > > My first question is what means Action 1 fails > > (a) both A1_1 and A1_2 fails > > (b) A1_1 or A1_2 fails > > (b) - since the executuion strategy for A1 is do-all I agree with Ron on this. Actually, the intent of my original message was to point out that PCIMe should answer the following question: Under which circumstances a CompoundPolicyAction is considered a success (or a failure)? IMO the answer depends on the CompoundPolicyAction's ExecutionStrategy and on the individual results of its CompoundedPolicyActions. > > Second thing, Ron you assume that we can check whether an action > > is possible to > > perform, before performing the action. E.g., the case of RSVP, > > where you setup a > > guaranteed path, you find out whether there is enough resource > > available by > > performing the setup action. However, I have to admit, that the > > action is not so > > difficult to rollback. > > So either one, either check before or rollback if this is possible In my example, a "feasibility check" is optional (an implementation optimization with no additional semantics) while a rollback is useless: the packet is dropped any way by A2. Regards, Mircea. > > Ron > > > > > Marcus > > > > Zitiere Ron Cohen : > > > > > Mircea, > > > > > > This is exactly the purpose of execution strategy. I understand that > > > you > > > think that this tool is needed in the PCIMe. The authors where not fully > > > in > > > agreement whether this is a required feature and whether policy > > > entities > > > (PEPs and PDPs) would be able to implement this. The issue was that > > > some > > > interpreted this to mean do action_1_1, and if you fail to do so, undo > > > the > > > operation (which is not always possible), while others (including me) > > > interpreted this as first check that you can do action_1_1 and > > > action_1_2, > > > if you can not do both don't do either one and move on to action 2. > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: policy-owner@raleigh.ibm.com > > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Mircea Pana > > > > Sent: Friday, May 11, 2001 5:48 PM > > > > To: IETF Policy > > > > Subject: Re: Result of the compoundPolicyAction > > > > > > > > > > > > Do the PCIMe authors have any opinion wrt. this subject? > > > > > > > > Here is an example to support the case 2. below. The following NAT > > > rule > > > > > > > > "in the packets from 10.10.10.10, > > > > change *both* the source addr. > > > > and the source port or, > > > > if any of the above fails > > > > then drop the packet" > > > > > > > > could be implemented as follows: > > > > > > > > Rule: If SourceIP=10.10.10.10 then (ordered, Do_until_success): > > > > Action_1(compound, unordered, Do_all): > > > > Action_1_1(simple): Set SourceIP to 1.2.3.4 > > > > Action_1_2(simple): Set SourcePort to 2001 > > > > Action_2: Drop packet > > > > > > > > Action_1 (compound, Do_all) should be considered successful only if > > > both > > > > Action_1_1 and Action_1_2 are successful. Then Action_2 is not > > > executed. > > > > If either Action_1_1 or Action_1_2 fails, then Action_1 should be > > > > considered failed and Action_2 should be executed. > > > > > > > > Thank You, > > > > Mircea. > > > > > > > > > > > > > > The result of the execution of a compoundPolicyAction (success or > > > > > > failure) is important for the execution strategy of the > > > aggregating > > > > > > policyRules or compoundPolicyAction. To avoid ambiguity, it > > > > may be good > > > > > > to add a clarification to the next release of PCIMe. > > > > > > > > > > > > A suggestion might be: > > > > > > > > > > > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success: > > > > > > The compoundPolicyAction is successful if an aggregated > > > > policyAction is > > > > > > successful. If all the aggregated policyActions fail, then the > > > > > > aggregating compoundPolicyAction is considered failed. > > > > > > > > > > > > 2. For compoundPolicyAction.executionStrategy=Do_All: > > > > > > The compoundPolicyAction is successful if all the aggregated > > > > > > policyActions are successful. If one or more aggregated > > > policyActions > > > > > > fail, then the aggregating compoundPolicyAction is considered > > > failed. > > > > > > > > > > > > (2bis. An alternative to 2 might be: > > > > > > The compoundPolicyAction is successful if one or more aggregated > > > > > > policyActions are successful. If all the aggregated > > > > policyActions fail, > > > > > > then the aggregating compoundPolicyAction is considered failed. > > > > > > If both 2. and 2bis are applicable in various situations then > > > > it may be > > > > > > useful to add a "Do_Any" execution strategy?) > > > > > > > > > > > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure: > > > > > > The compoundPolicyAction is successful if one or more aggregated > > > > > > policyActions are successful. If the first attempt to execute an > > > > > > aggregated policyAction fails, then the aggregating > > > > compoundPolicyAction > > > > > > is considered failed. > > > > > > > > > > > > Regards, > > > > > > Mircea. > > > > > > > > > > > > P.S. BTW in PCIMe-01, the example at the end of the paragraph > > > "4.7.2 > > > > > > Compound Policy Actions" uses the retired "Mandatory Do All" > > > decision > > > > > > strategy. For consistency with the rest of the document, this > > > > should be > > > > > > corrected. > > > > > > > > From majordomo@raleigh.ibm.com Fri May 18 13:32:21 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02892 for ; Fri, 18 May 2001 13:32:20 -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 NAA16974; Fri, 18 May 2001 13:22:46 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA28264; Fri, 18 May 2001 13:23:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49390; Fri, 18 May 2001 12:32:51 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45282; Fri, 18 May 2001 12:32:48 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA28128 for ; Fri, 18 May 2001 12:32:48 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f4IGWFN158694 for ; Fri, 18 May 2001 12:32:15 -0400 Importance: Normal Subject: QDDIM: Preamble marking To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore" Date: Fri, 18 May 2001 12:38:59 -0400 X-Mimetrack: Serialize by Router on D04NM200/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 05/18/2001 12:32:15 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore" In QDDIM-03, there is an uneasy combination of two partial solutions to address the problem of how to identify flows on a datapath. In this note I propose that we complete the PreambleMarker approach, and remove the remaining traces of the approach based on the NextService.TrafficClass property. The problem we're looking to solve can be summarized as follows: we need ways to both (1) capture and (2) use information about intermediate results, like InProfile vs. OutOfProfile for a meter. There's also another requirement that has been brought up a few times, that we need to decide whether we're going to try to address in QDDIM: information that's captured on an ingress interface, prior to a packet's trip across the routing core, needs to be available for use when the packet reaches an egress interface. As I read [DSMODEL], they decided not to address this requirement. But I think we've been leaning towards saying that we will address it in QDDIM. This is important because (I think) this additional requirement forces us down the PreambleMarker / PreambleFilter path, as opposed to the NextService. TrafficClass path. The reason is that the chain of NextService associations is always broken by the routing core, and must start over with the first ConditioningService on an egress interface. The packet preamble serves as the vehicle for getting the information from the ingress side to the egress side. So here's my proposal for QDDIM: 1. We follow the basic [DSMODEL] approach, which says that if you need to re-split traffic streams that have been merged together, you must insert a new Classifier. 2. We remove TrafficClass entirely from NextService, so that the only keys for the association are the two references. This makes it very easy to draw instance diagrams, since there's always at most one NextService instance between any two ConditioningServices. 3. On the theory that we want to start small, we add *one* capability beyond the existing packet- classification criteria: the ability to capture and use information about what happened to a packet at a particular meter. So the "capture" part of the picture looks like this: +---------+ | Meter-A | a | | b d --->| In-|---PM-1---> | | c e | Out-|---PM-2---> +---------+ Each of the five instances of NextService (actually, NextServiceAfterMeter in the case of b and c) is uniquely identified by its two reference properties. PreambleMarker PM-1 adds the following information to the packet preamble: (Meter-A, In). I don't think we need to specify the format of this information in the model -- just that it's a two-element structure that identifies a meter and a result. Similarly, PreambleMarker PM-2 adds (Meter-A, Out) to the preambles of packets that come through it. 4. For the "use" part, we need a new subclass of FilterEntryBase that matches on these (, ) structures in a packet's preamble. To simplify the case where there's just a single level of metering in a box, but different individual meters on each ingress interface, I think we want to allow a wildcard "any" for the part of one of these filters. With this wildcard, an administrator could then specify a Classifier to select all packets that were found to be InProfile by their respective meters, without having to name each meter individually in a separate ClassifierElement. 5. An implication of 1 and 2 is that when we're dealing with microflows, we'll often need to reclassify after merging the flows: +---------+ +----+ | Meter-A | |CL-1|--GOLD-----> GOLD---->| | +--->| |--SILVER---> SILVER-->| In-|---PM-1---+ | |--BRONZE---> BRONZE-->| | +----+ | Out-|---PM-2---+ +---------+ | +----+ | |CL-2|--GOLD-----> +--->| |--SILVER---> | |--BRONZE---> +----+ I think that this proposal is one that (a) solves our particular requirement of preserving metering results across the routing core (as well as along the datapath on a particular ingress or egress interface) and (b) is small enough that we can add, and add correctly, in the next version of QDDIM. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Fri May 18 14:15:59 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10427 for ; Fri, 18 May 2001 14:15:58 -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 OAA23060; Fri, 18 May 2001 14:07: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 OAA33944; Fri, 18 May 2001 14:07:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41666; Fri, 18 May 2001 13:14:50 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51638; Fri, 18 May 2001 13:14:46 -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 NAA33094 for ; Fri, 18 May 2001 13:14:46 -0400 Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA25444 for ; Fri, 18 May 2001 13:13:59 -0400 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id RAA17895 for ; Fri, 18 May 2001 17:14:13 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 18 May 2001 17:13:53 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 10:13:51 -0700 Message-Id: <75F7304BB41CD411B06600A0C98414FC015B726F@ORSMSX54> From: "Sahita, Ravi" To: "'policy@raleigh.ibm.com'" Subject: RE: RAP WG Notice: Policy Terminology Draft, Extended WG Last C all Date: Fri, 18 May 2001 10:13:38 -0700 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Sahita, Ravi" 1. The document defines... $ role combination (P) An unordered set of roles that characterize managed elements and indicate the applicability of policy rules and PRovisioning Classes (PRCs). A policy system uses the set of roles reported by the managed element to determine the correct rules/PRCs to be sent for enforcement... However, the framework PIB defines RoleCombination as.... ... "RoleCombination" which is a lexicographically ordered set of roles. ... The comparing of roles (or role combinations) is case sensitive. ... 2. [COPS-RSVP], [COPS-PR], [SPPI] are not referenced. Ravi. -----Original Message----- From: Ed Ellesson [mailto:eellesson@lboard.com] Sent: Friday, May 04, 2001 5:36 PM To: 'rap@ops.ietf.org' Cc: 'Scott Hahn'; 'Mark Stevens'; 'Wijnen, Bert (Bert)'; Joel M. Halpern Subject: RAP WG Notice: Policy Terminology Draft, Extended WG Last Call RAP WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group From majordomo@raleigh.ibm.com Mon May 21 22:39:15 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23950 for ; Mon, 21 May 2001 22:39:14 -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 WAA25664; Mon, 21 May 2001 22:32: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 WAA33426; Mon, 21 May 2001 22:33:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34838; Mon, 21 May 2001 21:49:16 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34574; Mon, 21 May 2001 21:49:13 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA35894 for ; Mon, 21 May 2001 21:49:11 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA22202 for ; Mon, 21 May 2001 21:48:11 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4M1kbc17236; Mon, 21 May 2001 18:46:37 -0700 (PDT) Received: from andreawlap (dhcp-128-107-131-164.cisco.com [128.107.131.164]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABW01642; Mon, 21 May 2001 18:48:04 -0700 (PDT) From: "Andrea Westerinen" To: "Angelos D. Keromytis" Cc: "Ed Ellesson" , "Policy@Raleigh. Ibm. Com" , "'Luis Sanchez'" , "Joel M. Halpern" , Subject: RE: IPSP WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Mon, 21 May 2001 18:50:08 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200105120716.f4C7Ga028020@nyarlathotep.keromytis.org> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit We did remove several references to WGs and specific implementations - since we started to rathole on all the different possibilities. SPSL was identified early on as a "technique" and has been in the draft since -00 (I believe). However, you are correct in that it is another language. I don't feel that any context is lost by removing SPSL from the draft. So, I will take this path unless the other editors or policy WG members feel differently. Andrea -----Original Message----- From: Angelos D. Keromytis [mailto:angelos@keromytis.org] Sent: Saturday, May 12, 2001 12:17 AM To: Andrea Westerinen Cc: Ed Ellesson; Policy@Raleigh. Ibm. Com; 'Luis Sanchez'; Joel M. Halpern; johns@cisco.com Subject: Re: IPSP WG Notice: Policy Terminology Draft, Extended WG Last Call In message , "Andrea Westerinen " writes: >Replying and also sending to the policy mail list ... > >Angelos, >>From my reading of the RFC, KeyNote is a specific implementation >architecture and language for trust management. I agree that it is directly >related to security, but policy is only part of the architecture. We do not >describe specific policy implementations in the terminology draft, but focus >instead on general policy terms and broad areas of use. Well, there *is* an entry for SPSL in the draft... -Angelos From majordomo@raleigh.ibm.com Tue May 22 11:36:54 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22755 for ; Tue, 22 May 2001 11:36: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 LAA21404; Tue, 22 May 2001 11:31: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 LAA32288; Tue, 22 May 2001 11:31:35 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43172; Tue, 22 May 2001 02:59:00 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16402; Tue, 22 May 2001 02:58:49 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA05464 for ; Tue, 22 May 2001 02:58:49 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA24858 for ; Tue, 22 May 2001 02:57:47 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f4M6ugc20433; Mon, 21 May 2001 23:56:42 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABW06488; Mon, 21 May 2001 23:58:10 -0700 (PDT) From: "Andrea Westerinen" To: "Joseph Salowey" Cc: , Subject: RE: Comments on Policy Terminology Date: Tue, 22 May 2001 00:00:15 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010514101446.00b797b8@mira-sjc5-6.cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit It looks like we have consensus and I will add the reference to RFC3060 for role. Thanks. Andrea -----Original Message----- From: owner-aaaarch@fokus.gmd.de [mailto:owner-aaaarch@fokus.gmd.de]On Behalf Of Joseph Salowey Sent: Monday, May 14, 2001 10:29 AM To: Andrea Westerinen Cc: aaaarch@fokus.gmd.de; policy@raleigh.ibm.com Subject: RE: Comments on Policy Terminology Comments in line Thanks, Joe >The draft looks good, but there are a few areas that confuse me. > >$policy request > >I was a little confused by this definition, perhaps is would be good to add >something like > >"A policy request may also refer to the retrieval of policy rules >pertaining to a specific situation." > > How about this for a definition? (Anything in CAPS is added.) ... > (P) A message requesting a policy-RELATED service. THIS MAY REFER > TO A REQUEST TO RETRIEVE A SPECIFIC SET OF POLICY RULES, TO > DETERMINE THE ACTIONS TO ENFORCE, OR OTHER POLICY REQUESTS. > When sent by a PEP to a PDP, it is more accurately qualified > as a "policy decision request." [R2753] (See also "policy > decision.") > >This definition should probably user "policy server" instead of "policy >service" to be consistent with other definitions. > > We don't use the term "policy server" since its meaning varies widely. >Please see our definition of this term. This helps. >$role > >I find the third definition of a role confusing. Can a managed element be >something that is accessing a resource such as a user? > > No. > >If it is then >explicitly stating so may help clarify things. If it isn't then I think >the definition is missing something. > > A person's Role is the first definition. The third definition is the >use of an attribute called "Role" to label a rule. A "Role" is also >assigned to entities such as devices, ports, interfaces, etc. When the >"Role" on the rule and on the entity match, then it is assumed that the rule >is applicable to the entity. This definition is used in SNMPCONF, PIBs and >the policy model. I like the simpler role definition in RFC 3060, but I can see what you are trying to convey. I think If you add a reference to RFC 3060 it will help greatly. >Additionally a role can be a dynamic characteristic. > > Where it is restricted? > > >$role combination > >I also find role combination confusing especially "That determination may >examine all applicable policy rules identified by the role combination, its >sub-combinations and the individual roles in the combination, or may >require that PRCs explicitly match the role combination specified for the >managed element." > >What does it mean for PRC's to explicitly match the role combination? > > PRCs do not allow sub-combinations of roles. Let me rephrase the >sentence as (using CAPS for anything new) ... > That determination may examine all applicable policy rules > identified by the role combination, its sub-combinations > and the individual roles in the combination. IN THE CASE OF > PRCs, A PRC MUST EXPLICITLY MATCH THE ROLE COMBINATION OF > THE MANAGED ELEMENT IN ORDER TO BE APPLICABLE AND/OR ENFORCED. This helps. >Perhaps this usage of role and role combination is implementation specific, >do you have a reference in mind? > > I will add a reference to the policy core model [RFC 3060]. The PRC >work is still an I-D. > >Thanks, > >Joe From majordomo@raleigh.ibm.com Tue May 22 12:13:33 2001 Received: from fwns1.raleigh.ibm.com ([204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24129 for ; Tue, 22 May 2001 12:13:31 -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 KAA20962; Tue, 22 May 2001 10:47:42 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA25642; Tue, 22 May 2001 10:47:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41884; Tue, 22 May 2001 02:59:00 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16394; Tue, 22 May 2001 02:58:49 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA37448 for ; Tue, 22 May 2001 02:58:47 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA30736 for ; Tue, 22 May 2001 02:57:46 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4M6wGU04344; Mon, 21 May 2001 23:58:16 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABW06493; Mon, 21 May 2001 23:58:13 -0700 (PDT) From: "Andrea Westerinen" To: , Subject: RE: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft, Extended WG Last Call (fwd) Date: Tue, 22 May 2001 00:00:18 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200105182024.QAA25597@europa-h0001027441c5.ne.mediaone.net> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Replies inline. Andrea -----Original Message----- From: owner-snmpconf@snmp.com [mailto:owner-snmpconf@snmp.com]On Behalf Of Jon Saperia Sent: Friday, May 18, 2001 1:24 PM To: policy@raleigh.ibm.com Cc: snmpconf@snmp.com Subject: snmpconf Re: SNMPCONF WG Notice: Policy Terminology Draft, Extended WG Last Call (fwd) Joel sent my posting back to me the other day with the suggestion that I reforward it to the Policy WG and that I add as much specific lanaguage as possible. At 06:21 PM 5/14/01 -0400, Jon Saperia wrote: >Ed, > >Thanks for the additional poke. I have commented on previous versions of >this document. One of my original concerns still stands in that the >document often references the COPS protocols and not SNMP in the context >of Policy information. Specifics: > > 1. There is no reference to SNMPCONF.: We have tried to clean up the references to WGs in the document - but I see that AAA still talks about the WG. I would rather move the sentences around in the definition of AAA (as noted below), than to include the existence of IETF WGs in an RFC. Here is a new definition for AAA: (A) AAA deals with control, authentication, authorization and accounting of systems and environments based on policies set by the administrators and users of the systems. The use of policy may be implicit - as defined by RADIUS [R2138]. In RADIUS, a network access server sends dial-user credentials to an AAA server, and receives authentication that the user is who he/she claims, along with a set of attribute-value pairs authorizing various service features. Policy is implied in both the authentication, which can be restricted by time of day, number of sessions, calling number, etc., and the attribute- values authorized. From page 3: - "T" identifies various techniques to create or convey policy-related information in a network. For example, COPS and an "Information Model" are two techniques for communicating and describing policy-related data. Replace with: - "T" identifies various techniques to create or convey policy-related information in a network. For example, COPS and an "Information Model" are two techniques for communicating and describing policy-related data. SNMP and MIBs are another. OK. > > 2. There is an incorrect impression left by the definition of PIB and > MIB that MIBs do not/can not carry policy information. In fact the > definition of a MIB points back to a PIB. Could you elaborate on this comment (that MIBs point to a PIB)? This is what is in the draft ... $ MIB See "Policy Management Information Base." $ Policy Management Information Base (MIB) (T) Collections of policy-related managed objects, defined as a module and accessed via an SNMP framework. > >An additional comment: > > Policy Translation - This mixes access methods (such as CLI) with > level of abstraction. If you want to call translation the thing you > do when moving from one access method to another great. There is way > too much in the current policy translation definition to be helpful I > do not agree with the use of 'blurring' in this definition. We have spent much time arguing over levels of translation and abstraction in the WG and within the policy terminology editors list. This issue has been raised at least twice before, with a decision to keep the definition "as is". Translation is not restricted to "moving from one access method to another". You could translate in a single tool from policy goals and SLAs to specific device representations (with no access methods involved at all). The reality is that the industry and implementations have blurred this term. However, if you would like to propose a specific rewrite, I would be happy to discuss this one more time. SNMP and SNMPCONF should be added to the terminology section. I will add a description of SNMP as a "technique", but will be removing all WG references. > >Thanks >/jon > > > > > > SNMPCONF WG: > > > > Our AD has asked us to inform your WG that this WG Last Call is > > going on in the Policy Framework WG. This is to give you a > > chance for review and comments, because the terminology is also > > meant to be used by your WG. > > > > Extended WG Last Call: > > > > This last call is hereby extended to end at CoB on Fri, May 18, 2001. > > > > The latest revision of the Terminology Draft is in the I-D > > repository. > > > > for your reference: > > > > http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt > > > > > > Please also note that the title is changing to be more > > descriptive: > > > > Terminology for Policy-Based Management > > > > This revision reflects all known issues and comments. > > This note extends the current working group last call, > > to two weeks from today, and is intended to bring > > forth any last issues. After such issues are resolved according > > to the working group consensus, we will be submitting > > this document to the IESG for publication as an informational RFC. > > > > > > We are also strongly suggesting that the comments/discussion be done to/on > > the > > policy fw wg mailing list... so that we have one archive to check later if > > needed. > > > > If you are not already subscribed to the policy framework mailing list: > > General Discussion: policy@raleigh.ibm.com > > To Subscribe: policy-request@raleigh.ibm.com > > In Body: subscribe > > Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy > > Thank you, and we apologize if you receive more than one notice like this. > > > > Ed Ellesson, > > with Joel Halpern > > > > Co-chairs, Policy Framework Working Group > > > > > > > > > >Thanks, >/jon >-- > >Jon Saperia saperia@jdscons.com > Phone: 617-744-1079 > Fax: 617-249-0874 > http://www.jdscons.com/ ------- End of Forwarded Message From majordomo@raleigh.ibm.com Tue May 22 12:46:17 2001 Received: from fwns2.raleigh.ibm.com ([204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25002 for ; Tue, 22 May 2001 12:46:15 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA25620; Tue, 22 May 2001 12:33:28 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA29944; Tue, 22 May 2001 12:31:24 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16552; Tue, 22 May 2001 02:59:01 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27650; Tue, 22 May 2001 02:58:48 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id CAA28996 for ; Tue, 22 May 2001 02:58:47 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA19726 for ; Tue, 22 May 2001 02:57:46 -0400 Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4M6wGU04339; Mon, 21 May 2001 23:58:16 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABW06489; Mon, 21 May 2001 23:58:12 -0700 (PDT) From: "Andrea Westerinen" To: "Sahita, Ravi" , Subject: RE: RAP WG Notice: Policy Terminology Draft, Extended WG Last Call Date: Tue, 22 May 2001 00:00:17 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <75F7304BB41CD411B06600A0C98414FC015B726F@ORSMSX54> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Replies inline. Andrea -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com] Sent: Friday, May 18, 2001 10:14 AM To: 'policy@raleigh.ibm.com' Subject: RE: RAP WG Notice: Policy Terminology Draft, Extended WG Last Call 1. The document defines... $ role combination (P) An unordered set of roles that characterize managed elements and indicate the applicability of policy rules and PRovisioning Classes (PRCs). A policy system uses the set of roles reported by the managed element to determine the correct rules/PRCs to be sent for enforcement... However, the framework PIB defines RoleCombination as.... ... "RoleCombination" which is a lexicographically ordered set of roles. ... The comparing of roles (or role combinations) is case sensitive. ... Thanks - you are correct. It seems that PIBs and RFC3060 both prescribe an alphabetical order. We should replace the word, "unordered", by "lexicographically ordered". 2. [COPS-RSVP], [COPS-PR], [SPPI] are not referenced. COPS and SPPI are referenced. Is there a reason to differentiate COPS-RSVP from COPS-PR? Ravi. -----Original Message----- From: Ed Ellesson [mailto:eellesson@lboard.com] Sent: Friday, May 04, 2001 5:36 PM To: 'rap@ops.ietf.org' Cc: 'Scott Hahn'; 'Mark Stevens'; 'Wijnen, Bert (Bert)'; Joel M. Halpern Subject: RAP WG Notice: Policy Terminology Draft, Extended WG Last Call RAP WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group