From majordomo@raleigh.ibm.com Mon Jan 3 16:23:59 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07843 for ; Mon, 3 Jan 2000 16:23:59 -0500 (EST) 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 QAA22040; Mon, 3 Jan 2000 16:16:13 -0500 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 QAA32428; Mon, 3 Jan 2000 16:16:14 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22914; Mon, 3 Jan 2000 15:56:10 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49014; Mon, 3 Jan 2000 15:56:07 -0500 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 PAA27386 for ; Mon, 3 Jan 2000 15:56:10 -0500 From: remoore@us.ibm.com Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA20270 for ; Mon, 3 Jan 2000 15:56:09 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525685B.0072FFB3 ; Mon, 3 Jan 2000 15:56:05 -0500 X-Lotus-Fromdomain: IBMUS To: policy@raleigh.ibm.com Message-Id: <8525685B.0072FD61.00@d54mta04.raleigh.ibm.com> Date: Mon, 3 Jan 2000 15:54:10 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Spelling "raleigh" correctly this time.... Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com ---------------------- Forwarded by Robert Moore/Raleigh/IBM on 01/03/2000 03:53 PM --------------------------- Robert Moore 01/03/2000 03:52 PM To: johns@cisco.com cc: policy@raliegh.ibm.com From: Robert Moore/Raleigh/IBM@IBMUS Subject: John, > 5. PolicyInstance. This will be corrected, per the mail list discussion, to > include a structural policyInstance class that inherits from the abstract > Policy class, as well as two structural classes, policyConditionInstance and > policyActionInstance. It will also leave room for defining additional > policySomethingElseInstance classes from the ppolicyInstance class in the > future, if we need to. Just to make sure I'm not missing something, this item from your "ed hamlin" note applies only to the LDAP version of the Core Policy Schema, right? So there's nothing I need to do about it for the update to the Information Model document. Thanks. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Tue Jan 4 04:29:03 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26638 for ; Tue, 4 Jan 2000 04:29:02 -0500 (EST) 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 EAA23874; Tue, 4 Jan 2000 04:21:49 -0500 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 EAA24690; Tue, 4 Jan 2000 04:21:46 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43500; Tue, 4 Jan 2000 04:10:22 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30534; Tue, 4 Jan 2000 03:40:31 -0500 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 DAA22936 for ; Tue, 4 Jan 2000 03:40:27 -0500 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA30928 for ; Tue, 4 Jan 2000 03:40:19 -0500 Received: from ysnir8000 (telaviv3-dhcp40.cisco.com [144.254.93.168]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id KAA01204; Tue, 4 Jan 2000 10:41:11 +0200 (IST) From: "Yoram Snir" To: , , "John Strassner (E-mail)" Subject: RE: Date: Tue, 4 Jan 2000 10:38:02 +0200 Message-Id: <000d01bf568f$03432f70$a85dfe90@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <8525685B.0072FD61.00@d54mta04.raleigh.ibm.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Bob In order to keep the model consistent, please keep the PolicyInstance definition as it was in previously, i.e., extending the Policy class. A question regarding the policyRuleConditionAssociation and policyRuleActionAssociation definition, why is the policyConditionName, policyActionName, respectively, attributes defined? why are they MUST attributes? There are cases when an ad-hoc (not reusable) condition will be name less. The Policy class supplies a naming attribute (CN) as a MAY attribute, and it seems to be enough since Policy is the superior class of policyRuleConditionAssociation, policyRuleActionAssociation, PolicyInstance, policyActionInstance, policyConditionInstance. If the idea is that reusable object must have a name and we want to enforce this via the schema, then I would suggest that the policyActionInstance, policyConditionInstance will have a single MUST attribute that is the CN. Thanks. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of remoore@us.ibm.com > Sent: Monday, January 03, 2000 10:54 PM > To: policy@raleigh.ibm.com > Subject: > > > > > Spelling "raleigh" correctly this time.... > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > ---------------------- Forwarded by Robert Moore/Raleigh/IBM > on 01/03/2000 > 03:53 PM --------------------------- > > Robert Moore > 01/03/2000 03:52 PM > > To: johns@cisco.com > cc: policy@raliegh.ibm.com > From: Robert Moore/Raleigh/IBM@IBMUS > Subject: > > > John, > > > 5. PolicyInstance. This will be corrected, per the mail > list discussion, > to > > include a structural policyInstance class that inherits > from the abstract > > Policy class, as well as two structural classes, > policyConditionInstance > and > > policyActionInstance. It will also leave room for defining > additional > > policySomethingElseInstance classes from the > ppolicyInstance class in the > > future, if we need to. > > Just to make sure I'm not missing something, this item from your "ed > hamlin" > note applies only to the LDAP version of the Core Policy > Schema, right? So > there's nothing I need to do about it for the update to the > Information > Model > document. > > Thanks. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > > > From majordomo@raleigh.ibm.com Tue Jan 4 16:47:03 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07493 for ; Tue, 4 Jan 2000 16:47:02 -0500 (EST) 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 QAA12614; Tue, 4 Jan 2000 16:37:40 -0500 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 QAA20082; Tue, 4 Jan 2000 16:37:40 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54854; Tue, 4 Jan 2000 16:21:52 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48946; Tue, 4 Jan 2000 16:21:48 -0500 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 QAA30452 for ; Tue, 4 Jan 2000 16:21:52 -0500 Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA07592 for ; Tue, 4 Jan 2000 16:21:49 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Tue, 4 Jan 2000 16:20:58 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 16:20:59 -0500 Message-Id: <63E0DAD7784FD21188310000F80824B302447345@zmpkdx02.us.nortel.com> From: "Ken Roberts" To: John Strassner , policy@raleigh.ibm.com Subject: RE: Preparing the Policy Core Information Model for Last Call Date: Tue, 4 Jan 2000 16:20:54 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF56F9.98192B58" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Roberts" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF56F9.98192B58 Content-Type: text/plain; charset="iso-8859-1" John, et al, I'm very pleased to support the Last Call on the Policy CIM, subject to some clarification. The decision to remove contentious material in the name of consensus is a time honoured standards tradition and is a useful tool to advance work - I do not oppose its use here but do request for clarification "version 1" be added to the RFC title. This is just to ensure that folks do not "assume" the work is complete in all respects and go off to look at other interesting things. The model as it stands is fine for what it addresses, however there are significant omissions notably but not exclusively what has been called the "administrative aspects" of policy including such things as security, audit, fault (i.e. violation detection/ resolution), et al, aspects. Lastly indulge me in wishing all my colleagues a happy, safe and prosperous New Year and I look forward to our discussions and meetings in 2000. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ------_=_NextPart_001_01BF56F9.98192B58 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Preparing the Policy Core Information Model for Last = Call

John, et al,
I'm very pleased to support the Last Call on the = Policy CIM, subject to some clarification.
The decision to remove contentious material in the = name of consensus is a time honoured standards tradition and is a = useful tool to advance work - I do not oppose its use here but do = request for clarification "version 1" be added to the RFC = title. This is just to ensure that folks do not "assume" the = work is complete in all respects and go off to look at other = interesting things.

The model as it stands is fine for what it addresses, = however there are significant omissions notably but not exclusively = what has been called the "administrative aspects" of policy = including such things as security, audit, fault (i.e. violation = detection/ resolution), et al, aspects.

Lastly indulge me in wishing all my colleagues a = happy, safe and prosperous New Year and I look forward to our = discussions and meetings in 2000.

---------------------------------------------------------------= -----------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   = :        = 655-7844        =         =         ?Direct  : = 408-565-7844
?  Fax    = :        408-565-8226
? email :      = kjr@nortelnetworks.com
 
This message may contain information proprietary to = Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.


------_=_NextPart_001_01BF56F9.98192B58-- From majordomo@raleigh.ibm.com Wed Jan 5 11:17:46 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09402 for ; Wed, 5 Jan 2000 11:17:44 -0500 (EST) 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 LAA26430; Wed, 5 Jan 2000 11:10:23 -0500 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 LAA24198; Wed, 5 Jan 2000 11:10:19 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA08072; Wed, 5 Jan 2000 10:53:54 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45950; Wed, 5 Jan 2000 10:53:49 -0500 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 KAA25226 for ; Wed, 5 Jan 2000 10:53:51 -0500 From: remoore@us.ibm.com Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA33140; Wed, 5 Jan 2000 10:53:50 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525685D.005750F6 ; Wed, 5 Jan 2000 10:53:43 -0500 X-Lotus-Fromdomain: IBMUS To: ysnir@cisco.com Cc: policy@raleigh.ibm.com, "John Strassner (E-mail)" Message-Id: <8525685D.00574DBE.00@d54mta04.raleigh.ibm.com> Date: Wed, 5 Jan 2000 10:51:39 -0500 Subject: RE: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com Hi Yoram, See my responses below. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com "Yoram Snir" on 01/04/2000 03:38:02 AM Please respond to To: Robert Moore/Raleigh/IBM@IBMUS, , "John Strassner (E-mail)" cc: Subject: RE: Bob In order to keep the model consistent, please keep the PolicyInstance definition as it was in previously, i.e., extending the Policy class. Yes, that's what I was intending to do when I get back to the LDAP Core Schema document. Currently, though, that document is in a holding pattern, waiting for the Core Info Model document to land first. A question regarding the policyRuleConditionAssociation and policyRuleActionAssociation definition, why is the policyConditionName, policyActionName, respectively, attributes defined? why are they MUST attributes? There are cases when an ad-hoc (not reusable) condition will be name less. The Policy class supplies a naming attribute (CN) as a MAY attribute, and it seems to be enough since Policy is the superior class of policyRuleConditionAssociation, policyRuleActionAssociation, PolicyInstance, policyActionInstance, policyConditionInstance. If the idea is that reusable object must have a name and we want to enforce this via the schema, then I would suggest that the policyActionInstance, policyConditionInstance will have a single MUST attribute that is the CN. I have no problem with downgrading the policy*Name attributes to MAY in all four of these structural classes, so that an instance that's named with CN doesn't need to have the policy*Name attribute at all. Does anybody else see a problem with this change? Thanks. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of remoore@us.ibm.com > Sent: Monday, January 03, 2000 10:54 PM > To: policy@raleigh.ibm.com > Subject: > > > > > Spelling "raleigh" correctly this time.... > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > ---------------------- Forwarded by Robert Moore/Raleigh/IBM > on 01/03/2000 > 03:53 PM --------------------------- > > Robert Moore > 01/03/2000 03:52 PM > > To: johns@cisco.com > cc: policy@raliegh.ibm.com > From: Robert Moore/Raleigh/IBM@IBMUS > Subject: > > > John, > > > 5. PolicyInstance. This will be corrected, per the mail > list discussion, > to > > include a structural policyInstance class that inherits > from the abstract > > Policy class, as well as two structural classes, > policyConditionInstance > and > > policyActionInstance. It will also leave room for defining > additional > > policySomethingElseInstance classes from the > ppolicyInstance class in the > > future, if we need to. > > Just to make sure I'm not missing something, this item from your "ed > hamlin" > note applies only to the LDAP version of the Core Policy > Schema, right? So > there's nothing I need to do about it for the update to the > Information > Model > document. > > Thanks. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > > > From majordomo@raleigh.ibm.com Wed Jan 5 12:15:07 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10920 for ; Wed, 5 Jan 2000 12:15:06 -0500 (EST) 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 MAA26248; Wed, 5 Jan 2000 12:06:21 -0500 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 MAA26572; Wed, 5 Jan 2000 12:03:00 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53520; Wed, 5 Jan 2000 11:52:06 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53510; Wed, 5 Jan 2000 11:52:03 -0500 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 LAA31134 for ; Wed, 5 Jan 2000 11:52:06 -0500 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29128 for ; Wed, 5 Jan 2000 11:52:01 -0500 Received: from ysnir8000 ([144.254.95.23]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id SAA20693; Wed, 5 Jan 2000 18:41:05 +0200 (IST) From: "Yoram Snir" To: Cc: , "'John Strassner (E-mail)'" Subject: RE: Date: Wed, 5 Jan 2000 18:37:22 +0200 Message-Id: <001801bf579b$2afe75d0$0200000a@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <8525685D.00574DBE.00@d54mta04.raleigh.ibm.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Thanks. Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com] > Sent: Wednesday, January 05, 2000 5:52 PM > To: ysnir@cisco.com > Cc: policy@raleigh.ibm.com; John Strassner (E-mail) > Subject: RE: > > > > > Hi Yoram, > > See my responses below. > > Regards, > Bob > > Bob Moore > IBM Networking Software > +1-919-254-4436 > remoore@us.ibm.com > > > > "Yoram Snir" on 01/04/2000 03:38:02 AM > > Please respond to > > To: Robert Moore/Raleigh/IBM@IBMUS, , "John > Strassner (E-mail)" > cc: > Subject: RE: > > > > Bob > In order to keep the model consistent, please keep the PolicyInstance > definition as it was in previously, i.e., extending the Policy class. > > Yes, that's what I was intending to do when I get back to the > LDAP Core > Schema document. Currently, though, that document is in a holding > pattern, waiting for the Core Info Model document to land first. > > > A question regarding the policyRuleConditionAssociation and > policyRuleActionAssociation definition, why is the > policyConditionName, > policyActionName, respectively, attributes defined? why are they MUST > attributes? > There are cases when an ad-hoc (not reusable) condition will > be name less. > > The Policy class supplies a naming attribute (CN) as a MAY > attribute, and > it > seems to be enough since Policy is the superior class of > policyRuleConditionAssociation, policyRuleActionAssociation, > PolicyInstance, > policyActionInstance, policyConditionInstance. > > If the idea is that reusable object must have a name and we > want to enforce > this via the schema, then I would suggest that the > policyActionInstance, > policyConditionInstance will have a single MUST attribute > that is the CN. > > I have no problem with downgrading the policy*Name attributes > to MAY in > all four of these structural classes, so that an instance > that's named with > CN doesn't need to have the policy*Name attribute at all. > Does anybody > else see a problem with this change? > > > Thanks. > > Yoram Snir > Cisco Systems > Tel. 972-9-9700085 > Mobile 972-54-970085 > > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of remoore@us.ibm.com > > Sent: Monday, January 03, 2000 10:54 PM > > To: policy@raleigh.ibm.com > > Subject: > > > > > > > > > > Spelling "raleigh" correctly this time.... > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > ---------------------- Forwarded by Robert Moore/Raleigh/IBM > > on 01/03/2000 > > 03:53 PM --------------------------- > > > > Robert Moore > > 01/03/2000 03:52 PM > > > > To: johns@cisco.com > > cc: policy@raliegh.ibm.com > > From: Robert Moore/Raleigh/IBM@IBMUS > > Subject: > > > > > > John, > > > > > 5. PolicyInstance. This will be corrected, per the mail > > list discussion, > > to > > > include a structural policyInstance class that inherits > > from the abstract > > > Policy class, as well as two structural classes, > > policyConditionInstance > > and > > > policyActionInstance. It will also leave room for defining > > additional > > > policySomethingElseInstance classes from the > > ppolicyInstance class in the > > > future, if we need to. > > > > Just to make sure I'm not missing something, this item from your "ed > > hamlin" > > note applies only to the LDAP version of the Core Policy > > Schema, right? So > > there's nothing I need to do about it for the update to the > > Information > > Model > > document. > > > > Thanks. > > > > Regards, > > Bob > > > > Bob Moore > > IBM Networking Software > > +1-919-254-4436 > > remoore@us.ibm.com > > > > > > > > > > > > > > > > > > From majordomo@raleigh.ibm.com Sat Jan 8 14:04:55 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20439 for ; Sat, 8 Jan 2000 14:04:54 -0500 (EST) 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 OAA29772; Sat, 8 Jan 2000 14:00:55 -0500 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 OAA26184; Sat, 8 Jan 2000 14:00:56 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50202; Sat, 8 Jan 2000 13:41:12 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37650; Sat, 8 Jan 2000 13:41:09 -0500 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 NAA25210 for ; Sat, 8 Jan 2000 13:41:12 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA35182 for ; Sat, 8 Jan 2000 13:41:08 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA07319; Sat, 8 Jan 2000 10:40:35 -0800 (PST) Message-Id: <4.2.0.58.20000108101918.017bd890@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 08 Jan 2000 10:41:20 -0800 To: "Ken Roberts" , policy@raleigh.ibm.com From: "John C. Strassner" Subject: RE: Preparing the Policy Core Information Model for Last Call Cc: johns@cisco.com, Ed_Ellesson@tivoli.com, remoore@us.ibm.com In-Reply-To: <63E0DAD7784FD21188310000F80824B302447345@zmpkdx02.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John C. Strassner" Hi Ken, sorry for the delay in responding, I've been down and out for the count with the flu. Than you very much for your thoughtful comments. I've taken the liberty to confer with Ed and Bob, and below please find comments that represent our views. regards, John (and Ed and Bob) At 04:20 PM 1/4/00 -0500, Ken Roberts wrote: >John, et al, >I'm very pleased to support the Last Call on the Policy CIM, subject to >some clarification. Thanks for the support. This is precisely why the Last Call message was issued. Your feedback is appreciated and incorporated. >The decision to remove contentious material in the name of consensus is a >time honoured standards tradition and is a useful tool to advance work - I >do not oppose its use here but do request for clarification "version 1" be >added to the RFC title. This is just to ensure that folks do not "assume" >the work is complete in all respects and go off to look at other >interesting things. Good suggestion. We will incorporate this. We could even add a small disclaimer in the Abstract and Intro that says something to the effect of: Please note: this is the first version of this document. It is being released in order to gain implementation experience. Comments (from you and the rest of the list, of course)? Please note that this is similar to the convention used for the rsvp documents' advancement on the standards track to Proposed Standard. The name of the primary RSVP RFC is Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Based on this precedent, we will re-title the subject document: Policy Framework Core Information Model -- Version 1 Specification >The model as it stands is fine for what it addresses, however there are >significant omissions notably but not exclusively what has been called the >"administrative aspects" of policy including such things as security, >audit, fault (i.e. violation detection/ resolution), et al, aspects. Agreed. The question is where to draw the line. The information model is concerned with the representation of knowledge about policies, abstracted into a set of classes and relationships. It was not intended to model security and other administrative aspects at this time, primarily because there has been little discussion about them and also because there is little agreement and definition as to their requirements and goals. In addition, administrative aspects such as those you mention tend to be vendor- and/or application-specific. So while we agree with your points, we also think that they involve a significant amount of extra information that would need to be merged into the model. The fine line we have to walk is whether these functions should be in this version of the model, or in a future version of the model. We have taken great pains to make this version of the model extensible, so that additional functions like those you have mentioned can be added. Our view is that such topics should be (and are being) addressed by other documents that are being produced by this working group. We are consciously trying to distinguish between modeling policy and modeling security, and think that the modeling of security should be done in other working groups (e.g., IPSP) whose focus and core expertise is security. Our charter was revised to work closely with such groups. As these documents advance, and as the work in other working groups related to these subjects advance, we can then actively incorporate their results into the appropriate versions of our documents (hence the Version 1 title of this document). Finally, we think that auditing, accounting, and other similar issues are out of scope of the charter that we have. We should try and first complete the work that we have, and then see if we want to recharter or form a new working group to solve these other issues. >Lastly indulge me in wishing all my colleagues a happy, safe and >prosperous New Year and I look forward to our discussions and meetings in 2000. Absolutely, we second the wish. And thanks for not calling it the start of the new millenium ;-) >-------------------------------------------------------------------------- >Regards, >Ken Roberts >INM Product Architecture >Nortel Networks >?ESN : 655-7844 ?Direct : 408-565-7844 >? Fax : 408-565-8226 >? email : kjr@nortelnetworks.com > >This message may contain information proprietary to Nortel Networks >Corporation so any >unauthorised disclosure, copying or distribution of its contents is >strictly prohibited. From majordomo@raleigh.ibm.com Mon Jan 10 13:24:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09877 for ; Mon, 10 Jan 2000 13:24:22 -0500 (EST) 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 NAA12514; Mon, 10 Jan 2000 13:19:07 -0500 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 NAA19530; Mon, 10 Jan 2000 13:19:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32658; Mon, 10 Jan 2000 13:02:17 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40330; Mon, 10 Jan 2000 13:02:14 -0500 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 NAA28032 for ; Mon, 10 Jan 2000 13:02:15 -0500 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA12484 for ; Mon, 10 Jan 2000 13:02:12 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Mon, 10 Jan 2000 12:02:22 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 12:01:43 -0600 Message-Id: <63E0DAD7784FD21188310000F80824B3024A7B64@zmpkdx02.us.nortel.com> From: "Ken Roberts" To: "John C. Strassner" , policy@raleigh.ibm.com Cc: johns@cisco.com, Ed_Ellesson@tivoli.com, remoore@us.ibm.com Subject: RE: Preparing the Policy Core Information Model for Last Call Date: Mon, 10 Jan 2000 12:01:39 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5B94.C0558702" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Roberts" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5B94.C0558702 Content-Type: text/plain; charset="iso-8859-1" John, I agree with your statements. My comment re audit etc. were not meant to imply the progression of the vers.1 document should be "held up" by work on those issues, I believe given the difficulties in getting this far vers.1 should proceed as it is - later versions is where this new work can/ should be folded in. Understand it is an "information" modelling document but it also is the "core" CIM and should reflect all informational aspects of the policy model and I certainly believe there are informational aspects to admin, security, audit, et al. Whether the Policy Framework group undertakes the work or not isn't especially relevant, although I'm surprised that identifying core components and their relationships isn't part of the group charter, the important point is that it gets done. So I think we may have another instance of "violent agreement" (another [im?]famous standards artefact. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. -----Original Message----- From: John C. Strassner [mailto:jstrassn@cisco.com] Sent: Saturday, January 08, 2000 10:41 AM To: Roberts, Ken [SC9:1O80:EXCH]; policy@raleigh.ibm.com Cc: johns@cisco.com; Ed_Ellesson@tivoli.com; remoore@us.ibm.com Subject: RE: Preparing the Policy Core Information Model for Last Call Hi Ken, sorry for the delay in responding, I've been down and out for the count with the flu. Than you very much for your thoughtful comments. I've taken the liberty to confer with Ed and Bob, and below please find comments that represent our views. regards, John (and Ed and Bob) At 04:20 PM 1/4/00 -0500, Ken Roberts wrote: >John, et al, >I'm very pleased to support the Last Call on the Policy CIM, subject to >some clarification. Thanks for the support. This is precisely why the Last Call message was issued. Your feedback is appreciated and incorporated. >The decision to remove contentious material in the name of consensus is a >time honoured standards tradition and is a useful tool to advance work - I >do not oppose its use here but do request for clarification "version 1" be >added to the RFC title. This is just to ensure that folks do not "assume" >the work is complete in all respects and go off to look at other >interesting things. Good suggestion. We will incorporate this. We could even add a small disclaimer in the Abstract and Intro that says something to the effect of: Please note: this is the first version of this document. It is being released in order to gain implementation experience. Comments (from you and the rest of the list, of course)? Please note that this is similar to the convention used for the rsvp documents' advancement on the standards track to Proposed Standard. The name of the primary RSVP RFC is Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Based on this precedent, we will re-title the subject document: Policy Framework Core Information Model -- Version 1 Specification >The model as it stands is fine for what it addresses, however there are >significant omissions notably but not exclusively what has been called the >"administrative aspects" of policy including such things as security, >audit, fault (i.e. violation detection/ resolution), et al, aspects. Agreed. The question is where to draw the line. The information model is concerned with the representation of knowledge about policies, abstracted into a set of classes and relationships. It was not intended to model security and other administrative aspects at this time, primarily because there has been little discussion about them and also because there is little agreement and definition as to their requirements and goals. In addition, administrative aspects such as those you mention tend to be vendor- and/or application-specific. So while we agree with your points, we also think that they involve a significant amount of extra information that would need to be merged into the model. The fine line we have to walk is whether these functions should be in this version of the model, or in a future version of the model. We have taken great pains to make this version of the model extensible, so that additional functions like those you have mentioned can be added. Our view is that such topics should be (and are being) addressed by other documents that are being produced by this working group. We are consciously trying to distinguish between modeling policy and modeling security, and think that the modeling of security should be done in other working groups (e.g., IPSP) whose focus and core expertise is security. Our charter was revised to work closely with such groups. As these documents advance, and as the work in other working groups related to these subjects advance, we can then actively incorporate their results into the appropriate versions of our documents (hence the Version 1 title of this document). Finally, we think that auditing, accounting, and other similar issues are out of scope of the charter that we have. We should try and first complete the work that we have, and then see if we want to recharter or form a new working group to solve these other issues. >Lastly indulge me in wishing all my colleagues a happy, safe and >prosperous New Year and I look forward to our discussions and meetings in 2000. Absolutely, we second the wish. And thanks for not calling it the start of the new millenium ;-) >-------------------------------------------------------------------------- >Regards, >Ken Roberts >INM Product Architecture >Nortel Networks >?ESN : 655-7844 ?Direct : 408-565-7844 >? Fax : 408-565-8226 >? email : kjr@nortelnetworks.com > >This message may contain information proprietary to Nortel Networks >Corporation so any >unauthorised disclosure, copying or distribution of its contents is >strictly prohibited. ------_=_NextPart_001_01BF5B94.C0558702 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Preparing the Policy Core Information Model for Last = Call

John,
I agree with your statements. My comment re audit = etc. were not meant to imply the progression of the vers.1 document = should be "held up" by work on those issues, I believe given = the difficulties in getting this far vers.1 should proceed as it is - = later versions is where this new work can/ should be folded = in.

Understand it is an "information" modelling = document but it also is the "core" CIM and should reflect all = informational aspects of the policy model and I certainly believe there = are informational aspects to admin, security, audit, et al. Whether the = Policy Framework group undertakes the work or not isn't especially = relevant, although I'm surprised that identifying core components and = their relationships isn't part of the group charter, the important = point is that it gets done.

So I think we may have another instance of = "violent agreement" (another [im?]famous standards = artefact.

---------------------------------------------------------------= -----------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   = :        = 655-7844        =         =         ?Direct  : = 408-565-7844
?  Fax    = :        408-565-8226
? email :      = kjr@nortelnetworks.com
 
This message may contain information proprietary to = Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.

 -----Original Message-----
From:   John C. Strassner [mailto:jstrassn@cisco.com] =
Sent:   Saturday, January 08, 2000 10:41 = AM
To:     Roberts, Ken = [SC9:1O80:EXCH]; policy@raleigh.ibm.com
Cc:     johns@cisco.com; = Ed_Ellesson@tivoli.com; remoore@us.ibm.com
Subject:        = RE: Preparing the Policy Core Information Model for Last Call

Hi Ken,

sorry for the delay in responding, I've been down and = out for the count
with the flu.

Than you very much for your thoughtful comments. I've = taken the liberty to
confer with Ed and Bob, and below please find = comments that represent our
views.

regards,
John (and Ed and Bob)

At 04:20 PM 1/4/00 -0500, Ken Roberts wrote:

>John, et al,
>I'm very pleased to support the Last Call on the = Policy CIM, subject to
>some clarification.

<jcs>
Thanks for the support. This is precisely why the = Last Call message
was issued. Your feedback is appreciated and = incorporated.
</jcs>
>The decision to remove contentious material in = the name of consensus is a
>time honoured standards tradition and is a = useful tool to advance work - I
>do not oppose its use here but do request for = clarification "version 1" be
>added to the RFC title. This is just to ensure = that folks do not "assume"
>the work is complete in all respects and go off = to look at other
>interesting things.

<jcs>
Good suggestion. We will incorporate this. We could = even add a small
disclaimer in the Abstract and Intro that says = something to the effect of:

     Please note: this is the = first version of this document.
    It is being released in order to = gain implementation
     experience.

Comments (from you and the rest of the list, of = course)?

Please note that this is similar to the convention = used for the rsvp
documents' advancement on the standards track to = Proposed Standard. The
name of the primary RSVP RFC is

    Resource ReSerVation Protocol = (RSVP) -- Version 1 Functional Specification

Based on this precedent, we will re-title the subject = document:

    Policy Framework Core Information = Model -- Version 1 Specification
</jcs>

>The model as it stands is fine for what it = addresses, however there are
>significant omissions notably but not = exclusively what has been called the
>"administrative aspects" of policy = including such things as security,
>audit, fault (i.e. violation detection/ = resolution), et al, aspects.

<jcs>
Agreed. The question is where to draw the line. The = information model is
concerned with the representation of knowledge about = policies, abstracted
into a set of classes and relationships. It was not = intended to model
security and other administrative aspects at this = time, primarily
because there has been little discussion about them = and also because there
is little agreement and definition as to their = requirements and goals. In
addition, administrative aspects such as those you = mention tend to be
vendor- and/or application-specific. So while we = agree with your points, we
also think that they involve a significant amount of = extra information that
would need to be merged into the model.

The fine line we have to walk is whether these = functions should be in this
version of the model, or in a future version of the = model. We have taken
great pains to make this version of the model = extensible, so that
additional functions like those you have mentioned = can be added.

Our view is that such topics should be (and are = being) addressed by other
documents that are being produced by this working = group. We are consciously
trying to distinguish between modeling policy and = modeling security, and
think that the modeling of security should be done = in other working groups
(e.g., IPSP) whose focus and core expertise is = security. Our charter was
revised to work closely with such groups. As these = documents advance, and
as the work in other working groups related to these = subjects advance, we
can then actively incorporate their results into the = appropriate versions
of our documents (hence the Version 1 title of this = document).

Finally, we think that auditing, accounting, and = other similar issues are
out of scope of the charter that we have. We should = try and first complete
the work that we have, and then see if we want to = recharter or form a new
working group to solve these other issues.
</jcs>

>Lastly indulge me in wishing all my colleagues a = happy, safe and
>prosperous New Year and I look forward to our = discussions and meetings in 2000.

<jcs>
Absolutely, we second the wish. And thanks for not = calling it the start of
the new millenium ;-)
</jcs>


>-----------------------------------------------------------= ---------------
>Regards,
>Ken Roberts
>INM Product Architecture
>Nortel Networks
>?ESN   = :        = 655-7844          &nbs= p;           &nbs= p; ?Direct  : 408-565-7844
>?  Fax    = :        408-565-8226
>? email :      = kjr@nortelnetworks.com
>
>This message may contain information proprietary = to Nortel Networks
>Corporation so any
>unauthorised disclosure, copying or distribution = of its contents is
>strictly prohibited.

------_=_NextPart_001_01BF5B94.C0558702-- From majordomo@raleigh.ibm.com Mon Jan 10 19:28:40 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15558 for ; Mon, 10 Jan 2000 19:28:39 -0500 (EST) 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 TAA19094; Mon, 10 Jan 2000 19:24:21 -0500 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 TAA33090; Mon, 10 Jan 2000 19:24:23 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45804; Mon, 10 Jan 2000 19:08:32 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45786; Mon, 10 Jan 2000 19:08:26 -0500 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 TAA30026 for ; Mon, 10 Jan 2000 19:08:30 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA27014 for ; Mon, 10 Jan 2000 19:08:25 -0500 Received: from jstrassn-lt (dhcp-j11-12-172.cisco.com [171.68.213.172]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA02116; Mon, 10 Jan 2000 16:07:12 -0800 (PST) Message-Id: <4.2.0.58.20000110132056.00d80b70@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Jan 2000 13:28:20 -0800 To: "Ken Roberts" , "John C. Strassner" , policy@raleigh.ibm.com From: "John C. Strassner" Subject: RE: Preparing the Policy Core Information Model for Last Call Cc: johns@cisco.com, Ed_Ellesson@tivoli.com, remoore@us.ibm.com In-Reply-To: <63E0DAD7784FD21188310000F80824B3024A7B64@zmpkdx02.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14786161==_.ALT" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John C. Strassner" --=====================_14786161==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ken, thanks for the note, I do agree that we are in violent agreement, and again want to thank you for the suggestions you made. regards, John At 12:01 PM 1/10/00 -0600, Ken Roberts wrote: >John, >I agree with your statements. My comment re audit etc. were not meant to >imply the progression of the vers.1 document should be "held up" by work >on those issues, I believe given the difficulties in getting this far >vers.1 should proceed as it is - later versions is where this new work >can/ should be folded in. > >Understand it is an "information" modelling document but it also is the >"core" CIM and should reflect all informational aspects of the policy >model and I certainly believe there are informational aspects to admin, >security, audit, et al. Whether the Policy Framework group undertakes the >work or not isn't especially relevant, although I'm surprised that >identifying core components and their relationships isn't part of the >group charter, the important point is that it gets done. > >So I think we may have another instance of "violent agreement" (another >[im?]famous standards artefact. > >-------------------------------------------------------------------------- >Regards, >Ken Roberts >INM Product Architecture >Nortel Networks >?ESN : 655-7844 ?Direct : 408-565-7844 >? Fax : 408-565-8226 >? email : kjr@nortelnetworks.com > >This message may contain information proprietary to Nortel Networks >Corporation so any >unauthorised disclosure, copying or distribution of its contents is >strictly prohibited. > > -----Original Message----- >From: John C. Strassner >[mailto:jstrassn@cisco.com] >Sent: Saturday, January 08, 2000 10:41 AM >To: Roberts, Ken [SC9:1O80:EXCH]; policy@raleigh.ibm.com >Cc: johns@cisco.com; Ed_Ellesson@tivoli.com; remoore@us.ibm.com >Subject: RE: Preparing the Policy Core Information Model for Last Call > >Hi Ken, > >sorry for the delay in responding, I've been down and out for the count >with the flu. > >Than you very much for your thoughtful comments. I've taken the liberty to >confer with Ed and Bob, and below please find comments that represent our >views. > >regards, >John (and Ed and Bob) > >At 04:20 PM 1/4/00 -0500, Ken Roberts wrote: > > >John, et al, > >I'm very pleased to support the Last Call on the Policy CIM, subject to > >some clarification. > > >Thanks for the support. This is precisely why the Last Call message >was issued. Your feedback is appreciated and incorporated. > > >The decision to remove contentious material in the name of consensus is a > >time honoured standards tradition and is a useful tool to advance work - I > >do not oppose its use here but do request for clarification "version 1" be > >added to the RFC title. This is just to ensure that folks do not "assume" > >the work is complete in all respects and go off to look at other > >interesting things. > > >Good suggestion. We will incorporate this. We could even add a small >disclaimer in the Abstract and Intro that says something to the effect of: > > Please note: this is the first version of this document. > It is being released in order to gain implementation > experience. > >Comments (from you and the rest of the list, of course)? > >Please note that this is similar to the convention used for the rsvp >documents' advancement on the standards track to Proposed Standard. The >name of the primary RSVP RFC is > > Resource ReSerVation Protocol (RSVP) -- Version 1 Functional > Specification > >Based on this precedent, we will re-title the subject document: > > Policy Framework Core Information Model -- Version 1 Specification > > > >The model as it stands is fine for what it addresses, however there are > >significant omissions notably but not exclusively what has been called the > >"administrative aspects" of policy including such things as security, > >audit, fault (i.e. violation detection/ resolution), et al, aspects. > > >Agreed. The question is where to draw the line. The information model is >concerned with the representation of knowledge about policies, abstracted >into a set of classes and relationships. It was not intended to model >security and other administrative aspects at this time, primarily >because there has been little discussion about them and also because there >is little agreement and definition as to their requirements and goals. In >addition, administrative aspects such as those you mention tend to be >vendor- and/or application-specific. So while we agree with your points, we >also think that they involve a significant amount of extra information that >would need to be merged into the model. > >The fine line we have to walk is whether these functions should be in this >version of the model, or in a future version of the model. We have taken >great pains to make this version of the model extensible, so that >additional functions like those you have mentioned can be added. > >Our view is that such topics should be (and are being) addressed by other >documents that are being produced by this working group. We are consciously >trying to distinguish between modeling policy and modeling security, and >think that the modeling of security should be done in other working groups >(e.g., IPSP) whose focus and core expertise is security. Our charter was >revised to work closely with such groups. As these documents advance, and >as the work in other working groups related to these subjects advance, we >can then actively incorporate their results into the appropriate versions >of our documents (hence the Version 1 title of this document). > >Finally, we think that auditing, accounting, and other similar issues are >out of scope of the charter that we have. We should try and first complete >the work that we have, and then see if we want to recharter or form a new >working group to solve these other issues. > > > >Lastly indulge me in wishing all my colleagues a happy, safe and > >prosperous New Year and I look forward to our discussions and meetings > in 2000. > > >Absolutely, we second the wish. And thanks for not calling it the start of >the new millenium ;-) > > > >-------------------------------------------------------------------------- > >Regards, > >Ken Roberts > >INM Product Architecture > >Nortel Networks > >?ESN : 655-7844 ?Direct : 408-565-7844 > >? Fax : 408-565-8226 > >? email : kjr@nortelnetworks.com > > > >This message may contain information proprietary to Nortel Networks > >Corporation so any > >unauthorised disclosure, copying or distribution of its contents is > >strictly prohibited. --=====================_14786161==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ken,

thanks for the note, I do agree that we are in violent agreement, and again want to thank you for the suggestions you made.

regards,
John

At 12:01 PM 1/10/00 -0600, Ken Roberts wrote:

John,
I agree with your statements. My comment re audit etc. were not meant to imply the progression of the vers.1 document should be "held up" by work on those issues, I believe given the difficulties in getting this far vers.1 should proceed as it is - later versions is where this new work can/ should be folded in.

Understand it is an "information" modelling document but it also is the "core" CIM and should reflect all informational aspects of the policy model and I certainly believe there are informational aspects to admin, security, audit, et al. Whether the Policy Framework group undertakes the work or not isn't especially relevant, although I'm surprised that identifying core components and their relationships isn't part of the group charter, the important point is that it gets done.

So I think we may have another instance of "violent agreement" (another [im?]famous standards artefact.

--------------------------------------------------------------------------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   :        655-7844                        ?Direct  : 408-565-7844
?  Fax    :        408-565-8226
? email :      kjr@nortelnetworks.com
 
This message may contain information proprietary to Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of its contents is strictly prohibited.

 -----Original Message-----
From:   John C. Strassner [mailto:jstrassn@cisco.com]
Sent:   Saturday, January 08, 2000 10:41 AM
To:     Roberts, Ken [SC9:1O80:EXCH]; policy@raleigh.ibm.com
Cc:     johns@cisco.com; Ed_Ellesson@tivoli.com; remoore@us.ibm.com
Subject:        RE: Preparing the Policy Core Information Model for Last Call

Hi Ken,

sorry for the delay in responding, I've been down and out for the count
with the flu.

Than you very much for your thoughtful comments. I've taken the liberty to
confer with Ed and Bob, and below please find comments that represent our
views.

regards,
John (and Ed and Bob)

At 04:20 PM 1/4/00 -0500, Ken Roberts wrote:

>John, et al,
>I'm very pleased to support the Last Call on the Policy CIM, subject to
>some clarification.

<jcs>
Thanks for the support. This is precisely why the Last Call message
was issued. Your feedback is appreciated and incorporated.
</jcs>
>The decision to remove contentious material in the name of consensus is a
>time honoured standards tradition and is a useful tool to advance work - I
>do not oppose its use here but do request for clarification "version 1" be
>added to the RFC title. This is just to ensure that folks do not "assume"
>the work is complete in all respects and go off to look at other
>interesting things.

<jcs>
Good suggestion. We will incorporate this. We could even add a small
disclaimer in the Abstract and Intro that says something to the effect of:

     Please note: this is the first version of this document.
    It is being released in order to gain implementation
     experience.

Comments (from you and the rest of the list, of course)?

Please note that this is similar to the convention used for the rsvp
documents' advancement on the standards track to Proposed Standard. The
name of the primary RSVP RFC is

    Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

Based on this precedent, we will re-title the subject document:

    Policy Framework Core Information Model -- Version 1 Specification
</jcs>

>The model as it stands is fine for what it addresses, however there are
>significant omissions notably but not exclusively what has been called the
>"administrative aspects" of policy including such things as security,
>audit, fault (i.e. violation detection/ resolution), et al, aspects.

<jcs>
Agreed. The question is where to draw the line. The information model is
concerned with the representation of knowledge about policies, abstracted
into a set of classes and relationships. It was not intended to model
security and other administrative aspects at this time, primarily
because there has been little discussion about them and also because there
is little agreement and definition as to their requirements and goals. In
addition, administrative aspects such as those you mention tend to be
vendor- and/or application-specific. So while we agree with your points, we
also think that they involve a significant amount of extra information that
would need to be merged into the model.

The fine line we have to walk is whether these functions should be in this
version of the model, or in a future version of the model. We have taken
great pains to make this version of the model extensible, so that
additional functions like those you have mentioned can be added.

Our view is that such topics should be (and are being) addressed by other
documents that are being produced by this working group. We are consciously
trying to distinguish between modeling policy and modeling security, and
think that the modeling of security should be done in other working groups
(e.g., IPSP) whose focus and core expertise is security. Our charter was
revised to work closely with such groups. As these documents advance, and
as the work in other working groups related to these subjects advance, we
can then actively incorporate their results into the appropriate versions
of our documents (hence the Version 1 title of this document).

Finally, we think that auditing, accounting, and other similar issues are
out of scope of the charter that we have. We should try and first complete
the work that we have, and then see if we want to recharter or form a new
working group to solve these other issues.
</jcs>

>Lastly indulge me in wishing all my colleagues a happy, safe and
>prosperous New Year and I look forward to our discussions and meetings in 2000.

<jcs>
Absolutely, we second the wish. And thanks for not calling it the start of
the new millenium ;-)
</jcs>

>--------------------------------------------------------------------------
>Regards,
>Ken Roberts
>INM Product Architecture
>Nortel Networks
>?ESN   :        655-7844                        ?Direct  : 408-565-7844
>?  Fax    :        408-565-8226
>? email :      kjr@nortelnetworks.com
>
>This message may contain information proprietary to Nortel Networks
>Corporation so any
>unauthorised disclosure, copying or distribution of its contents is
>strictly prohibited.
--=====================_14786161==_.ALT-- From majordomo@raleigh.ibm.com Wed Jan 12 11:48:03 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19318 for ; Wed, 12 Jan 2000 11:47:59 -0500 (EST) 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 LAA29946; Wed, 12 Jan 2000 11:43:13 -0500 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 LAA26928; Wed, 12 Jan 2000 11:43:18 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38350; Wed, 12 Jan 2000 11:20:59 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52660; Wed, 12 Jan 2000 11:20:54 -0500 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 LAA20486 for ; Wed, 12 Jan 2000 11:20:56 -0500 Received: from mercure.IRO.UMontreal.CA (IDENT:root@mercure.IRO.UMontreal.CA [132.204.24.67]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25036 for ; Wed, 12 Jan 2000 11:20:44 -0500 Received: from nil.IRO.UMontreal.CA (nil.IRO.UMontreal.CA [132.204.26.100]) by mercure.IRO.UMontreal.CA (8.9.3/8.9.3) with ESMTP id LAA06198; Wed, 12 Jan 2000 11:20:50 -0500 Received: from iro.umontreal.ca (localhost [127.0.0.1]) by nil.IRO.UMontreal.CA (8.9.3/8.9.3) with ESMTP id LAA16330; Wed, 12 Jan 2000 11:20:44 -0500 (EST) Message-Id: <387CA9DC.60FCE4BD@iro.umontreal.ca> Date: Wed, 12 Jan 2000 11:20:44 -0500 From: Diefadima Dioubate X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.7 sun4m) X-Accept-Language: en Mime-Version: 1.0 To: confmgt@ops.ietf.org, policy@raleigh.ibm.com Subject: COPS API or COPS Server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Diefadima Dioubate Content-Transfer-Encoding: 7bit Hi everyone, For my research project I have to write a java "client" for a COPS server but don't have any server yet. Does anyone know where can I find a free server copy or COPS API? Any help will be appreciated. Diefadima D. From majordomo@raleigh.ibm.com Thu Jan 20 13:31:07 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11299 for ; Thu, 20 Jan 2000 13:31:05 -0500 (EST) 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 NAA30476; Thu, 20 Jan 2000 13:26:10 -0500 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 NAA21662; Thu, 20 Jan 2000 13:26:06 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15542; Thu, 20 Jan 2000 13:00:50 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21418; Thu, 20 Jan 2000 13:00:47 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA30194 for ; Thu, 20 Jan 2000 13:00:49 -0500 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id MAA08092; Thu, 20 Jan 2000 12:00:49 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625686C.0062F4F0 ; Thu, 20 Jan 2000 12:00:52 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Cc: johns@cisco.com, wijnen@vnet.ibm.com, randy@psg.com Message-Id: <8625686C.0062EFE6.00@tivmta4.tivoli.com> Date: Thu, 20 Jan 2000 12:58:04 -0500 Subject: WG Last Call: draft-ietf-policy-core-info-model-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com PURPOSE: The purpose of this message is to initiate the Policy Framework WG last call on the "Policy Framework Core Information Model -- Version 1 Specification" document: draft-ietf-policy-core-info-model-03.txt LAST CALL: Unless there are strong objections, we would like to consider this draft of the document to be the final one, before moving it forward for proposed standard status. Please send any such objections, as well as statements of support, to the mailing list, during the last call period. SCHEDULE: The last call starts today (Thursday, January 20, 2000) and will last approximately two weeks. It will end on Thursday, February 03, 2000. Thank you, John Strassner and Ed Ellesson, your humble co-chairs From majordomo@raleigh.ibm.com Thu Jan 20 14:01:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12197 for ; Thu, 20 Jan 2000 14:01:34 -0500 (EST) 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 NAA33238; Thu, 20 Jan 2000 13:57:01 -0500 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 NAA27288; Thu, 20 Jan 2000 13:56:59 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36994; Thu, 20 Jan 2000 13:32:54 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25976; Thu, 20 Jan 2000 13:32:50 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA14924 for ; Thu, 20 Jan 2000 13:32:54 -0500 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id MAA16266 for ; Thu, 20 Jan 2000 12:32:53 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625686C.0065E146 ; Thu, 20 Jan 2000 12:32:48 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <8625686C.0065E01C.00@tivmta4.tivoli.com> Date: Thu, 20 Jan 2000 13:30:10 -0500 Subject: I-D ACTION:draft-ietf-policy-core-info-model-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on 01/20/2000 01:28 PM --------------------------- Please respond to Internet-Drafts@ietf.org To: IETF-Announce: ; cc: policy@raleigh.ibm.com Subject: I-D ACTION:draft-ietf-policy-core-info-model-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Policy Framework Core Information Model Version 1 Specification Author(s) : E. Ellesson, J. Strassner, B. Moore Filename : draft-ietf-policy-core-info-model-03.txt Pages : 64 Date : 19-Jan-00 This document presents the object-oriented information model for representing policy information currently under joint development in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. A companion document 'Policy Framework Core LDAP Schema' [9] defines the mapping of this information model to a directory that uses LDAPv3 as its access protocol. The components of the CIM v2.2 schema are available via links on the following DMTF web page: http://www.dmtf.org/spec/cim_schema_v22.html. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-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-core-info-model-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-core-info-model-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. mailto:mailserv@ietf.org ftp://ftp.ietf.org/internet-drafts/draft-ietf-policy-core-info-model-03.txt From majordomo@raleigh.ibm.com Tue Jan 25 14:39:06 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06679 for ; Tue, 25 Jan 2000 14:39:06 -0500 (EST) 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 OAA19454; Tue, 25 Jan 2000 14:33:22 -0500 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 OAA05500; Tue, 25 Jan 2000 14:33:22 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43362; Tue, 25 Jan 2000 14:08:57 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47958; Tue, 25 Jan 2000 14:08:53 -0500 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 OAA35658 for ; Tue, 25 Jan 2000 14:08:57 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA19810 for ; Tue, 25 Jan 2000 14:08:42 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 14:08:03 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF01911544@rerun.lucentctc.com> From: "Weiss, Walter" To: policy@raleigh.ibm.com Subject: Policy issues: definition of Roles Date: Tue, 25 Jan 2000 14:08:02 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" At the last IETF, numerous conversations resulted in a number of new issues that deserve discussion and consensus. I would like to start addressing these issues from easiest to hardest with a desire to have them all resolved prior to the next meeting. My intent is to serialize these discussions to give each topic a fair hearing. However, if we run out of time, I will start initiating parallel threads. The first issue is one I eluded to in my presentation. There are apparently two definitions for Role: 1. A role is a list of targets for a policy to be applied to. In other words, if the policy conditions and actions describe some interaction with or within an interface, the role lists the interfaces that the policy is applicable to. If the policy describes some OSPF related rules, then the role is the list of OSPF instances. This definition is more applicable to how policies are distributed 2. A role describes the binding between the set of attributes used in a policy and the actual attributes that exist in a device or service. For example, a policy that prevents new flows when total bandwidth for that flow type exceeds 30% of all traffic, may need an explicit binding of the bandwidth counter attribute and the flow type definition to a particular instance of a queue. This definition speaks more to how a policy is interpreted. My take is that these two definitions are nearly the same. However, if a role is assumed to be associated with the rule, I would be inclined to favor definition 1. The reason is that I anticipate the possibility of policy rules that either interact with multiple instances of the same time (If Gold Traffic exceeds a threshold, lower bandwidth allocation for Silver Service) or transcend service domains (When a new DHCP accounting user is validated install a packet filter granting access to the accounting network). In the first example a role listing the queues/services to which this policy is applicable is reasonable. However, a role binding of the rule to a particular set of queues/services is ambiguous because the gold service queue and the silver service queue would each interpret the rule as "If MY traffic exceeds this threshold reduce MY bandwidth." What we really want is "If MY traffic exceeds this threshold reduce the OTHER bandwidth." In the second example, according to definition 1 of role, the policy server would determine that the role is applicable to the DHCP service and the filters on edge interfaces of the accounting network. Under definition 2, the attribute binding is confusing because the DHCP service has no packet forwarding service and the routers don't (usually) have a DHCP service. Therefore a subset of the attributes are ambiguous. The only way to disambiguate this type of rule is to qualify the attribute: DHCPService.NewUserAddress and AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute qualification, the value of roles under definition 2 seems almost irrelevant. Comments? regards, -Walter From majordomo@raleigh.ibm.com Tue Jan 25 15:21:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07308 for ; Tue, 25 Jan 2000 15:21:04 -0500 (EST) 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 PAA33538; Tue, 25 Jan 2000 15:16:47 -0500 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 PAA13114; Tue, 25 Jan 2000 15:16:44 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47480; Tue, 25 Jan 2000 14:53:06 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46188; Tue, 25 Jan 2000 14:53:02 -0500 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 OAA23526 for ; Tue, 25 Jan 2000 14:53:06 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA23200 for ; Tue, 25 Jan 2000 14:53:02 -0500 Received: from bnatale (frederick15.acec.com [38.177.115.54]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id OAA00653; Tue, 25 Jan 2000 14:51:28 -0500 (EST) Message-Id: <4.2.2.20000125144542.00ae7908@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 14:55:08 -0500 To: "Weiss, Walter" From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <75ADD7496F0BD211ADC000104B8846CF01911544@rerun.lucentctc.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/25/2000:02:08 PM, Weiss, Walter wrote: Hi Walter, ><...> >1. A role is a list of targets for a policy to be applied to. In other >words, if the policy conditions and actions describe some interaction with >or within an interface, the role lists the interfaces that the policy is >applicable to. If the policy describes some OSPF related rules, then the >role is the list of OSPF instances. This definition is more applicable to >how policies are distributed > >2. A role describes the binding between the set of attributes used in a >policy and the actual attributes that exist in a device or service. For >example, a policy that prevents new flows when total bandwidth for that flow >type exceeds 30% of all traffic, may need an explicit binding of the >bandwidth counter attribute and the flow type definition to a particular >instance of a queue. This definition speaks more to how a policy is >interpreted. > >My take is that these two definitions are nearly the same. However, if a >role is assumed to be associated with the rule, I would be inclined to favor >definition 1. ><...> >Comments? I don't see much need for interpretation #2. I favor the association of roles with rules and, therefore, I favor definition #1. I really don't have much to add to your rationale, but would like to see consensus quickly form around the Def #1 use of "role" and see us move on to resolution of additonal issues. Thanks. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Tue Jan 25 18:06:53 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09383 for ; Tue, 25 Jan 2000 18:06:53 -0500 (EST) 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 SAA30834; Tue, 25 Jan 2000 18:00:24 -0500 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 SAA34356; Tue, 25 Jan 2000 18:00:25 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29256; Tue, 25 Jan 2000 17:37:48 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52790; Tue, 25 Jan 2000 17:37:43 -0500 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 RAA29654 for ; Tue, 25 Jan 2000 17:37:38 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA28564 for ; Tue, 25 Jan 2000 17:37:30 -0500 Received: from eh6mq5 ([10.100.1.4]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id RAA13608 for ; Tue, 25 Jan 2000 17:36:13 -0500 From: "Jon Sjoberg" To: Subject: Policy Framework Core Information Model -- Version 1 Date: Tue, 25 Jan 2000 17:45:37 -0800 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: "Jon Sjoberg" Content-Transfer-Encoding: 7bit A few comments the draft: "Policy Framework Core Information Model -- Version 1 Specification". 1.) The general view that I get from the draft is that policy (as currently being focused on by this WG, not in the most general sense) is being made to apply to the aggregation of a client and some network behavior. The following statement, from the draft, sums up the "feeling" that I get: "Service policies describe services available in the network. Usage policies describe the particular binding of a client of the network to services available in the network." Often the draft uses examples like "so-and-so gets gold service" or "use this scheme on this interface." I appreciate these are only examples, but they also further my opinion that this draft focuses on a simple aggregation. What I'm looking at is policies such as: All HTTP traffic from paying_customers for landsend.com gets priority network treatment from special_servers. All HTTP traffic from browsing_customers for landsend.com gets priority network treatment from unwashed_masses_servers. All FTP retr traffic for landsend.com gets bulk-transfer network treatment from unwashed_masses_servers. All FTP stor traffic for landsend.com gets denied network treatment. Clearly these can be represented as condition/action policy rules. What I'm not so clear on is all the other stuff that goes around these policy rules. What policy keywords or roles are appropriate for these policies? Where does the definition of HTTP, paying_cutomers, FTP, etc. fit into the repository or do they (I think I remember one incarnation of this draft or the LDAP schema that sort of addressed this)? Can some one enlighten me! Thanks. 2.) Usage of the CIM notation seems to add to the complexity of the problem domain and to the complexity of this draft. A conservative estimate of 15 percent of the document is devoted to describing CIM work-arounds, CIM attributes that add no direct value (my opinion) to the problem domain, and CIM "quarks". Given that our intended protocol is LDAP, is there enough value to the CIM notation to use it instead of some other more robust OO representation (UML, Shlear-Mellor, etc.)? I'm not suggesting holding up last call over this (least I get shot), but perhaps we could re-work the draft to track tighter to the essential complexity of the problem? Jon From majordomo@raleigh.ibm.com Tue Jan 25 18:08:11 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09412 for ; Tue, 25 Jan 2000 18:08:10 -0500 (EST) 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 SAA27104; Tue, 25 Jan 2000 18:00:31 -0500 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 SAA29516; Tue, 25 Jan 2000 18:00:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52810; Tue, 25 Jan 2000 17:37:49 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52800; Tue, 25 Jan 2000 17:37:44 -0500 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 RAA13182 for ; Tue, 25 Jan 2000 17:37:44 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA21658 for ; Tue, 25 Jan 2000 17:37:38 -0500 Received: from eh6mq5 ([10.100.1.4]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id RAA13611 for ; Tue, 25 Jan 2000 17:36:16 -0500 From: "Jon Sjoberg" To: Subject: RE: Policy issues: definition of Roles Date: Tue, 25 Jan 2000 17:45:40 -0800 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: <75ADD7496F0BD211ADC000104B8846CF01911544@rerun.lucentctc.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit Not to seem too ignorant, but where did these definitions come from? There is a definition of roles in "Policy Framework Core Information Model -- Version 1 Specification", section 5.2, which I can't quite match to either of the E-mailed definitions. In this draft a role is defined as: "a policy administrator assigns each resource to one or more roles, and then specifies the policies for each of these roles." Then, further on, this draft states: "Roles are represented in the Core Policy Schema by values of the Policy Keywords property." Of which, section 6.1.2 further enumerates to be: "This document defines the following keywords: "UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and "EVENT"." The best I can see is if we take definition number 1, and generalize it out several orders, we sorta match the PFCIM definition. Any insight to help me? Thanks, Jon -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter Sent: Tuesday, January 25, 2000 11:08 AM To: policy@raleigh.ibm.com Subject: Policy issues: definition of Roles At the last IETF, numerous conversations resulted in a number of new issues that deserve discussion and consensus. I would like to start addressing these issues from easiest to hardest with a desire to have them all resolved prior to the next meeting. My intent is to serialize these discussions to give each topic a fair hearing. However, if we run out of time, I will start initiating parallel threads. The first issue is one I eluded to in my presentation. There are apparently two definitions for Role: 1. A role is a list of targets for a policy to be applied to. In other words, if the policy conditions and actions describe some interaction with or within an interface, the role lists the interfaces that the policy is applicable to. If the policy describes some OSPF related rules, then the role is the list of OSPF instances. This definition is more applicable to how policies are distributed 2. A role describes the binding between the set of attributes used in a policy and the actual attributes that exist in a device or service. For example, a policy that prevents new flows when total bandwidth for that flow type exceeds 30% of all traffic, may need an explicit binding of the bandwidth counter attribute and the flow type definition to a particular instance of a queue. This definition speaks more to how a policy is interpreted. My take is that these two definitions are nearly the same. However, if a role is assumed to be associated with the rule, I would be inclined to favor definition 1. The reason is that I anticipate the possibility of policy rules that either interact with multiple instances of the same time (If Gold Traffic exceeds a threshold, lower bandwidth allocation for Silver Service) or transcend service domains (When a new DHCP accounting user is validated install a packet filter granting access to the accounting network). In the first example a role listing the queues/services to which this policy is applicable is reasonable. However, a role binding of the rule to a particular set of queues/services is ambiguous because the gold service queue and the silver service queue would each interpret the rule as "If MY traffic exceeds this threshold reduce MY bandwidth." What we really want is "If MY traffic exceeds this threshold reduce the OTHER bandwidth." In the second example, according to definition 1 of role, the policy server would determine that the role is applicable to the DHCP service and the filters on edge interfaces of the accounting network. Under definition 2, the attribute binding is confusing because the DHCP service has no packet forwarding service and the routers don't (usually) have a DHCP service. Therefore a subset of the attributes are ambiguous. The only way to disambiguate this type of rule is to qualify the attribute: DHCPService.NewUserAddress and AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute qualification, the value of roles under definition 2 seems almost irrelevant. Comments? regards, -Walter From majordomo@raleigh.ibm.com Wed Jan 26 07:57:43 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02838 for ; Wed, 26 Jan 2000 07:57:43 -0500 (EST) 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 HAA18536; Wed, 26 Jan 2000 07:52:46 -0500 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 HAA31874; Wed, 26 Jan 2000 07:52:45 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40650; Wed, 26 Jan 2000 07:34:11 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34996; Wed, 26 Jan 2000 07:34:07 -0500 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 HAA31088 for ; Wed, 26 Jan 2000 07:34:08 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA40534 for ; Wed, 26 Jan 2000 07:34:06 -0500 Received: from mediaone.net (1Cust96.tnt1.knoxville.tn.da.uu.net [63.10.97.96]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA27727; Wed, 26 Jan 2000 07:34:04 -0500 (EST) Message-Id: <388EE9C7.3445C8AD@mediaone.net> Date: Wed, 26 Jan 2000 07:34:15 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: Jon Sjoberg Cc: policy@raleigh.ibm.com Subject: Re: Policy Framework Core Information Model -- Version 1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Jon Sjoberg Wrote: > > 2.) > Usage of the CIM notation seems to add to the complexity of the problem > domain and to the complexity of this draft. A conservative estimate of 15 > percent of the document is devoted to describing CIM work-arounds, CIM > attributes that add no direct value (my opinion) to the problem domain, and > CIM "quarks". Given that our intended protocol is LDAP, is there enough > value to the CIM notation to use it instead of some other more robust OO > representation (UML, Shlear-Mellor, etc.)? I'm not suggesting holding up > last call over this (least I get shot), but perhaps we could re-work the > draft to track tighter to the essential complexity of the problem? > > Jon One of the reasons I like your suggestion (especially about UML) are that there are some very good tools around that generate UML and for some of us at least, would help with design code and other reasons. /jon From majordomo@raleigh.ibm.com Wed Jan 26 08:14:41 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03387 for ; Wed, 26 Jan 2000 08:14:41 -0500 (EST) 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 IAA26808; Wed, 26 Jan 2000 08:08:51 -0500 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 IAA28560; Wed, 26 Jan 2000 08:08:50 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53720; Wed, 26 Jan 2000 07:48:34 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30672; Wed, 26 Jan 2000 07:48:31 -0500 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 HAA20680 for ; Wed, 26 Jan 2000 07:48:34 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA19340 for ; Wed, 26 Jan 2000 07:48:32 -0500 Received: from mediaone.net (1Cust96.tnt1.knoxville.tn.da.uu.net [63.10.97.96]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA01247; Wed, 26 Jan 2000 07:48:27 -0500 (EST) Message-Id: <388EED27.36690522@mediaone.net> Date: Wed, 26 Jan 2000 07:48:39 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <75ADD7496F0BD211ADC000104B8846CF01911544@rerun.lucentctc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Walter, I like your second role definition better as well. I had always imagined, even before this work started, of a hierarchy of rules (policies) which would take precedence under some circumstances. One reasonable one you gave is over subscription. Another I frequently worry about is failure (which can look like over subsciption). In a sense I am suggesting a way of interrelating rules. /jon "Weiss, Walter" wrote: > > The first issue is one I eluded to in my presentation. There are apparently > two definitions for Role: > > 1. A role is a list of targets for a policy to be applied to. In other > words, if the policy conditions and actions describe some interaction with > or within an interface, the role lists the interfaces that the policy is > applicable to. If the policy describes some OSPF related rules, then the > role is the list of OSPF instances. This definition is more applicable to > how policies are distributed > > 2. A role describes the binding between the set of attributes used in a > policy and the actual attributes that exist in a device or service. For > example, a policy that prevents new flows when total bandwidth for that flow > type exceeds 30% of all traffic, may need an explicit binding of the > bandwidth counter attribute and the flow type definition to a particular > instance of a queue. This definition speaks more to how a policy is > interpreted. > > My take is that these two definitions are nearly the same. However, if a > role is assumed to be associated with the rule, I would be inclined to favor > definition 1. The reason is that I anticipate the possibility of policy > rules that either interact with multiple instances of the same time (If Gold > Traffic exceeds a threshold, lower bandwidth allocation for Silver Service) > or transcend service domains (When a new DHCP accounting user is validated > install a packet filter granting access to the accounting network). In the > first example a role listing the queues/services to which this policy is > applicable is reasonable. However, a role binding of the rule to a > particular set of queues/services is ambiguous because the gold service > queue and the silver service queue would each interpret the rule as "If MY > traffic exceeds this threshold reduce MY bandwidth." What we really want is > "If MY traffic exceeds this threshold reduce the OTHER bandwidth." In the > second example, according to definition 1 of role, the policy server would > determine that the role is applicable to the DHCP service and the filters on > edge interfaces of the accounting network. Under definition 2, the attribute > binding is confusing because the DHCP service has no packet forwarding > service and the routers don't (usually) have a DHCP service. Therefore a > subset of the attributes are ambiguous. The only way to disambiguate this > type of rule is to qualify the attribute: DHCPService.NewUserAddress and > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > qualification, the value of roles under definition 2 seems almost > irrelevant. > > Comments? > > regards, > > -Walter From majordomo@raleigh.ibm.com Wed Jan 26 08:43:45 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04032 for ; Wed, 26 Jan 2000 08:43:45 -0500 (EST) 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 IAA19048; Wed, 26 Jan 2000 08:39:32 -0500 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 IAA29646; Wed, 26 Jan 2000 08:39:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43186; Wed, 26 Jan 2000 08:23:28 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57258; Wed, 26 Jan 2000 08:23:25 -0500 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 IAA02210 for ; Wed, 26 Jan 2000 08:23:28 -0500 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA24452 for ; Wed, 26 Jan 2000 08:23:25 -0500 Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Wed, 26 Jan 2000 07:23:09 -0600 Received: by zsc4c002.corpwest.baynetworks.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 05:23:02 -0800 Message-Id: From: "Ken Birtwistle" To: "'policy@raleigh.ibm.com'" Date: Wed, 26 Jan 2000 05:23:02 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6800.7831CBA2" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Birtwistle" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6800.7831CBA2 Content-Type: text/plain; charset="ISO-8859-1" unsubscribe kbirtwis@nortelnetworks.com ------_=_NextPart_001_01BF6800.7831CBA2 Content-Type: text/html; charset="ISO-8859-1"

unsubscribe kbirtwis@nortelnetworks.com

------_=_NextPart_001_01BF6800.7831CBA2-- From majordomo@raleigh.ibm.com Wed Jan 26 11:33:59 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06480 for ; Wed, 26 Jan 2000 11:33:59 -0500 (EST) 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 LAA24814; Wed, 26 Jan 2000 11:27:19 -0500 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 LAA36312; Wed, 26 Jan 2000 11:27:18 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53346; Wed, 26 Jan 2000 11:12:52 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35674; Wed, 26 Jan 2000 11:12:49 -0500 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 LAA30760 for ; Wed, 26 Jan 2000 11:12:52 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25056 for ; Wed, 26 Jan 2000 11:12:49 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 11:12:15 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF01911547@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Saperia'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Wed, 26 Jan 2000 11:12:14 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Jon (Saperia), Are you suggesting that a given policy should be restricted to a single class (the policy equivalent of a PIB/MIB row) and that a collection/hierarchy of policies be used to implement the example policies I cited? regards, -Walter > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Wednesday, January 26, 2000 7:49 AM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: Re: Policy issues: definition of Roles > > > Walter, I like your second role definition better as well. I > had always > imagined, even before this work started, of a hierarchy of rules > (policies) which would take precedence under some circumstances. One > reasonable one you gave is over subscription. Another I > frequently worry > about is failure (which can look like over subsciption). In a sense I > am suggesting a way of interrelating rules. > /jon > "Weiss, Walter" wrote: > > > > > The first issue is one I eluded to in my presentation. > There are apparently > > two definitions for Role: > > > > 1. A role is a list of targets for a policy to be applied > to. In other > > words, if the policy conditions and actions describe some > interaction with > > or within an interface, the role lists the interfaces that > the policy is > > applicable to. If the policy describes some OSPF related > rules, then the > > role is the list of OSPF instances. This definition is more > applicable to > > how policies are distributed > > > > 2. A role describes the binding between the set of > attributes used in a > > policy and the actual attributes that exist in a device or > service. For > > example, a policy that prevents new flows when total > bandwidth for that flow > > type exceeds 30% of all traffic, may need an explicit binding of the > > bandwidth counter attribute and the flow type definition to > a particular > > instance of a queue. This definition speaks more to how a policy is > > interpreted. > > > > My take is that these two definitions are nearly the same. > However, if a > > role is assumed to be associated with the rule, I would be > inclined to favor > > definition 1. The reason is that I anticipate the > possibility of policy > > rules that either interact with multiple instances of the > same time (If Gold > > Traffic exceeds a threshold, lower bandwidth allocation for > Silver Service) > > or transcend service domains (When a new DHCP accounting > user is validated > > install a packet filter granting access to the accounting > network). In the > > first example a role listing the queues/services to which > this policy is > > applicable is reasonable. However, a role binding of the rule to a > > particular set of queues/services is ambiguous because the > gold service > > queue and the silver service queue would each interpret the > rule as "If MY > > traffic exceeds this threshold reduce MY bandwidth." What > we really want is > > "If MY traffic exceeds this threshold reduce the OTHER > bandwidth." In the > > second example, according to definition 1 of role, the > policy server would > > determine that the role is applicable to the DHCP service > and the filters on > > edge interfaces of the accounting network. Under definition > 2, the attribute > > binding is confusing because the DHCP service has no packet > forwarding > > service and the routers don't (usually) have a DHCP > service. Therefore a > > subset of the attributes are ambiguous. The only way to > disambiguate this > > type of rule is to qualify the attribute: > DHCPService.NewUserAddress and > > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > > qualification, the value of roles under definition 2 seems almost > > irrelevant. > > > > Comments? > > > > regards, > > > > -Walter > From majordomo@raleigh.ibm.com Wed Jan 26 11:36:03 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06523 for ; Wed, 26 Jan 2000 11:36:01 -0500 (EST) 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 LAA26686; Wed, 26 Jan 2000 11:31:46 -0500 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 LAA07182; Wed, 26 Jan 2000 11:27:22 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56642; Wed, 26 Jan 2000 11:08:29 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29750; Wed, 26 Jan 2000 11:08:26 -0500 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 LAA27580 for ; Wed, 26 Jan 2000 11:08:29 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25362 for ; Wed, 26 Jan 2000 11:08:26 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 11:07:54 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF01911546@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Sjoberg'" , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Wed, 26 Jan 2000 11:07:53 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Jon, To answer your question, Roles were first proposed in the context of PIBS. In this context, a PIB row, or subset thereof, was associated with a group of one or more services/components. In this context definition 2 is perfectly reasonable because a PIB row is always unambiguous, even if it is applied to a set of instances. In policy, this concept (and definition 2) was inherited. However, attributes that will not be part of the same PIB row will often coexist in the same policy. As I said in my first message, I noticed this confusion during discussions with other folks at the last IETF. regards, -Walter > -----Original Message----- > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > Sent: Tuesday, January 25, 2000 8:46 PM > To: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Not to seem too ignorant, but where did these definitions > come from? There > is a definition of roles in "Policy Framework Core > Information Model -- > Version 1 Specification", section 5.2, which I can't quite > match to either > of the E-mailed definitions. > > In this draft a role is defined as: > "a policy administrator assigns each resource to one or more > roles, and then > specifies the policies for each of these roles." > > Then, further on, this draft states: > "Roles are represented in the Core Policy Schema by values of > the Policy > Keywords property." > > Of which, section 6.1.2 further enumerates to be: > "This document defines the following keywords: "UNKNOWN", > "CONFIGURATION", > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and > "EVENT"." > > The best I can see is if we take definition number 1, and > generalize it out > several orders, we sorta match the PFCIM definition. Any > insight to help > me? > > Thanks, > Jon > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > Sent: Tuesday, January 25, 2000 11:08 AM > To: policy@raleigh.ibm.com > Subject: Policy issues: definition of Roles > > > At the last IETF, numerous conversations resulted in a number > of new issues > that deserve discussion and consensus. I would like to start > addressing > these issues from easiest to hardest with a desire to have > them all resolved > prior to the next meeting. My intent is to serialize these > discussions to > give each topic a fair hearing. However, if we run out of > time, I will start > initiating parallel threads. > > The first issue is one I eluded to in my presentation. There > are apparently > two definitions for Role: > > 1. A role is a list of targets for a policy to be applied to. In other > words, if the policy conditions and actions describe some > interaction with > or within an interface, the role lists the interfaces that > the policy is > applicable to. If the policy describes some OSPF related > rules, then the > role is the list of OSPF instances. This definition is more > applicable to > how policies are distributed > > 2. A role describes the binding between the set of attributes > used in a > policy and the actual attributes that exist in a device or > service. For > example, a policy that prevents new flows when total > bandwidth for that flow > type exceeds 30% of all traffic, may need an explicit binding of the > bandwidth counter attribute and the flow type definition to a > particular > instance of a queue. This definition speaks more to how a policy is > interpreted. > > My take is that these two definitions are nearly the same. > However, if a > role is assumed to be associated with the rule, I would be > inclined to favor > definition 1. The reason is that I anticipate the possibility > of policy > rules that either interact with multiple instances of the > same time (If Gold > Traffic exceeds a threshold, lower bandwidth allocation for > Silver Service) > or transcend service domains (When a new DHCP accounting user > is validated > install a packet filter granting access to the accounting > network). In the > first example a role listing the queues/services to which > this policy is > applicable is reasonable. However, a role binding of the rule to a > particular set of queues/services is ambiguous because the > gold service > queue and the silver service queue would each interpret the > rule as "If MY > traffic exceeds this threshold reduce MY bandwidth." What we > really want is > "If MY traffic exceeds this threshold reduce the OTHER > bandwidth." In the > second example, according to definition 1 of role, the policy > server would > determine that the role is applicable to the DHCP service and > the filters on > edge interfaces of the accounting network. Under definition > 2, the attribute > binding is confusing because the DHCP service has no packet forwarding > service and the routers don't (usually) have a DHCP service. > Therefore a > subset of the attributes are ambiguous. The only way to > disambiguate this > type of rule is to qualify the attribute: > DHCPService.NewUserAddress and > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > qualification, the value of roles under definition 2 seems almost > irrelevant. > > Comments? > > regards, > > -Walter > > > From majordomo@raleigh.ibm.com Wed Jan 26 11:54:39 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06658 for ; Wed, 26 Jan 2000 11:54:38 -0500 (EST) 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 LAA17782; Wed, 26 Jan 2000 11:50:05 -0500 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 LAA25498; Wed, 26 Jan 2000 11:48:02 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45202; Wed, 26 Jan 2000 11:25:25 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42890; Wed, 26 Jan 2000 11:25:22 -0500 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 LAA29452 for ; Wed, 26 Jan 2000 11:25:25 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA31978 for ; Wed, 26 Jan 2000 11:25:21 -0500 Received: from jsjobergnt (dyn146.TopLayer.com [199.103.238.146]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id LAA22906; Wed, 26 Jan 2000 11:24:45 -0500 From: "Jon Sjoberg" To: "Weiss, Walter" , Subject: RE: Policy issues: definition of Roles Date: Wed, 26 Jan 2000 11:22:21 -0500 Message-Id: <000701bf6819$857c7320$92ee67c7@blazenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <75ADD7496F0BD211ADC000104B8846CF01911546@rerun.lucentctc.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit So the term "role" which you wished to get clarified is separate from the term "role" defined in the PFCIM document, correct? If these terms are different we should probably get the terms altered a bit to remove yet a third point of confusion from your list. If these terms are the same would you mind holding my hand a little to show me how they are the same? Thanks, Jon > -----Original Message----- > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > Sent: Wednesday, January 26, 2000 11:08 AM > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Jon, > > To answer your question, Roles were first proposed in the context of PIBS. > In this context, a PIB row, or subset thereof, was associated with a group > of one or more services/components. In this context definition 2 is > perfectly reasonable because a PIB row is always unambiguous, > even if it is > applied to a set of instances. In policy, this concept (and definition 2) > was inherited. However, attributes that will not be part of the > same PIB row > will often coexist in the same policy. As I said in my first message, I > noticed this confusion during discussions with other folks at the > last IETF. > > regards, > > -Walter > > > -----Original Message----- > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > Sent: Tuesday, January 25, 2000 8:46 PM > > To: policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Not to seem too ignorant, but where did these definitions > > come from? There > > is a definition of roles in "Policy Framework Core > > Information Model -- > > Version 1 Specification", section 5.2, which I can't quite > > match to either > > of the E-mailed definitions. > > > > In this draft a role is defined as: > > "a policy administrator assigns each resource to one or more > > roles, and then > > specifies the policies for each of these roles." > > > > Then, further on, this draft states: > > "Roles are represented in the Core Policy Schema by values of > > the Policy > > Keywords property." > > > > Of which, section 6.1.2 further enumerates to be: > > "This document defines the following keywords: "UNKNOWN", > > "CONFIGURATION", > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and > > "EVENT"." > > > > The best I can see is if we take definition number 1, and > > generalize it out > > several orders, we sorta match the PFCIM definition. Any > > insight to help > > me? > > > > Thanks, > > Jon > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > Sent: Tuesday, January 25, 2000 11:08 AM > > To: policy@raleigh.ibm.com > > Subject: Policy issues: definition of Roles > > > > > > At the last IETF, numerous conversations resulted in a number > > of new issues > > that deserve discussion and consensus. I would like to start > > addressing > > these issues from easiest to hardest with a desire to have > > them all resolved > > prior to the next meeting. My intent is to serialize these > > discussions to > > give each topic a fair hearing. However, if we run out of > > time, I will start > > initiating parallel threads. > > > > The first issue is one I eluded to in my presentation. There > > are apparently > > two definitions for Role: > > > > 1. A role is a list of targets for a policy to be applied to. In other > > words, if the policy conditions and actions describe some > > interaction with > > or within an interface, the role lists the interfaces that > > the policy is > > applicable to. If the policy describes some OSPF related > > rules, then the > > role is the list of OSPF instances. This definition is more > > applicable to > > how policies are distributed > > > > 2. A role describes the binding between the set of attributes > > used in a > > policy and the actual attributes that exist in a device or > > service. For > > example, a policy that prevents new flows when total > > bandwidth for that flow > > type exceeds 30% of all traffic, may need an explicit binding of the > > bandwidth counter attribute and the flow type definition to a > > particular > > instance of a queue. This definition speaks more to how a policy is > > interpreted. > > > > My take is that these two definitions are nearly the same. > > However, if a > > role is assumed to be associated with the rule, I would be > > inclined to favor > > definition 1. The reason is that I anticipate the possibility > > of policy > > rules that either interact with multiple instances of the > > same time (If Gold > > Traffic exceeds a threshold, lower bandwidth allocation for > > Silver Service) > > or transcend service domains (When a new DHCP accounting user > > is validated > > install a packet filter granting access to the accounting > > network). In the > > first example a role listing the queues/services to which > > this policy is > > applicable is reasonable. However, a role binding of the rule to a > > particular set of queues/services is ambiguous because the > > gold service > > queue and the silver service queue would each interpret the > > rule as "If MY > > traffic exceeds this threshold reduce MY bandwidth." What we > > really want is > > "If MY traffic exceeds this threshold reduce the OTHER > > bandwidth." In the > > second example, according to definition 1 of role, the policy > > server would > > determine that the role is applicable to the DHCP service and > > the filters on > > edge interfaces of the accounting network. Under definition > > 2, the attribute > > binding is confusing because the DHCP service has no packet forwarding > > service and the routers don't (usually) have a DHCP service. > > Therefore a > > subset of the attributes are ambiguous. The only way to > > disambiguate this > > type of rule is to qualify the attribute: > > DHCPService.NewUserAddress and > > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > > qualification, the value of roles under definition 2 seems almost > > irrelevant. > > > > Comments? > > > > regards, > > > > -Walter > > > > > > > From majordomo@raleigh.ibm.com Wed Jan 26 12:34:53 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07338 for ; Wed, 26 Jan 2000 12:34:53 -0500 (EST) 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 MAA32766; Wed, 26 Jan 2000 12:25:40 -0500 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 MAA02066; Wed, 26 Jan 2000 12:25:38 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51574; Wed, 26 Jan 2000 12:12:19 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52846; Wed, 26 Jan 2000 12:12:16 -0500 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 MAA05828 for ; Wed, 26 Jan 2000 12:12:20 -0500 Received: from daystrom.abatis-sys.com ([216.13.164.98]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA22584 for ; Wed, 26 Jan 2000 12:11:58 -0500 Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 09:05:20 -0800 Message-Id: <811670B03A7DD211A2730008C709C2096A41AC@daystrom.abatissys.com> From: "Lipari, Steve" To: policy@raleigh.ibm.com Date: Wed, 26 Jan 2000 09:05:09 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lipari, Steve" unsubsribe From majordomo@raleigh.ibm.com Wed Jan 26 12:53:47 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07687 for ; Wed, 26 Jan 2000 12:53:45 -0500 (EST) 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 MAA26534; Wed, 26 Jan 2000 12:49:20 -0500 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 MAA33672; Wed, 26 Jan 2000 12:49:02 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55644; Wed, 26 Jan 2000 12:33:56 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42580; Wed, 26 Jan 2000 12:33:48 -0500 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 MAA29846 for ; Wed, 26 Jan 2000 12:33:51 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA29412 for ; Wed, 26 Jan 2000 12:33:09 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 12:31:26 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF01911549@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Sjoberg'" , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Wed, 26 Jan 2000 12:31:25 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Jon (Sjoberg), I believe that PFCIM currently uses definition 1. "Resources" in this context appear to me to be the equivalent of PIB/MIB rows and or classes in an information model. However, I would defer to the authors for their interpretation. If it is indeed definition 1 they were considering, we may need to rethink it. As I suggested previously, this approach while sound for COPS/SNMP places potentially sever restrictions on the types of policies that can be constructed. regards, -Walter > -----Original Message----- > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > Sent: Wednesday, January 26, 2000 11:22 AM > To: Weiss, Walter; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > So the term "role" which you wished to get clarified is > separate from the > term "role" defined in the PFCIM document, correct? > > If these terms are different we should probably get the terms > altered a bit > to remove yet a third point of confusion from your list. > > If these terms are the same would you mind holding my hand a > little to show > me how they are the same? > > Thanks, > Jon > > > -----Original Message----- > > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > > Sent: Wednesday, January 26, 2000 11:08 AM > > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Jon, > > > > To answer your question, Roles were first proposed in the > context of PIBS. > > In this context, a PIB row, or subset thereof, was > associated with a group > > of one or more services/components. In this context definition 2 is > > perfectly reasonable because a PIB row is always unambiguous, > > even if it is > > applied to a set of instances. In policy, this concept (and > definition 2) > > was inherited. However, attributes that will not be part of the > > same PIB row > > will often coexist in the same policy. As I said in my > first message, I > > noticed this confusion during discussions with other folks at the > > last IETF. > > > > regards, > > > > -Walter > > > > > -----Original Message----- > > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > > Sent: Tuesday, January 25, 2000 8:46 PM > > > To: policy@raleigh.ibm.com > > > Subject: RE: Policy issues: definition of Roles > > > > > > > > > Not to seem too ignorant, but where did these definitions > > > come from? There > > > is a definition of roles in "Policy Framework Core > > > Information Model -- > > > Version 1 Specification", section 5.2, which I can't quite > > > match to either > > > of the E-mailed definitions. > > > > > > In this draft a role is defined as: > > > "a policy administrator assigns each resource to one or more > > > roles, and then > > > specifies the policies for each of these roles." > > > > > > Then, further on, this draft states: > > > "Roles are represented in the Core Policy Schema by values of > > > the Policy > > > Keywords property." > > > > > > Of which, section 6.1.2 further enumerates to be: > > > "This document defines the following keywords: "UNKNOWN", > > > "CONFIGURATION", > > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", > "INSTALLATION", and > > > "EVENT"." > > > > > > The best I can see is if we take definition number 1, and > > > generalize it out > > > several orders, we sorta match the PFCIM definition. Any > > > insight to help > > > me? > > > > > > Thanks, > > > Jon > > > -----Original Message----- > > > From: policy-owner@raleigh.ibm.com > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > > Sent: Tuesday, January 25, 2000 11:08 AM > > > To: policy@raleigh.ibm.com > > > Subject: Policy issues: definition of Roles > > > > > > > > > At the last IETF, numerous conversations resulted in a number > > > of new issues > > > that deserve discussion and consensus. I would like to start > > > addressing > > > these issues from easiest to hardest with a desire to have > > > them all resolved > > > prior to the next meeting. My intent is to serialize these > > > discussions to > > > give each topic a fair hearing. However, if we run out of > > > time, I will start > > > initiating parallel threads. > > > > > > The first issue is one I eluded to in my presentation. There > > > are apparently > > > two definitions for Role: > > > > > > 1. A role is a list of targets for a policy to be applied > to. In other > > > words, if the policy conditions and actions describe some > > > interaction with > > > or within an interface, the role lists the interfaces that > > > the policy is > > > applicable to. If the policy describes some OSPF related > > > rules, then the > > > role is the list of OSPF instances. This definition is more > > > applicable to > > > how policies are distributed > > > > > > 2. A role describes the binding between the set of attributes > > > used in a > > > policy and the actual attributes that exist in a device or > > > service. For > > > example, a policy that prevents new flows when total > > > bandwidth for that flow > > > type exceeds 30% of all traffic, may need an explicit > binding of the > > > bandwidth counter attribute and the flow type definition to a > > > particular > > > instance of a queue. This definition speaks more to how a > policy is > > > interpreted. > > > > > > My take is that these two definitions are nearly the same. > > > However, if a > > > role is assumed to be associated with the rule, I would be > > > inclined to favor > > > definition 1. The reason is that I anticipate the possibility > > > of policy > > > rules that either interact with multiple instances of the > > > same time (If Gold > > > Traffic exceeds a threshold, lower bandwidth allocation for > > > Silver Service) > > > or transcend service domains (When a new DHCP accounting user > > > is validated > > > install a packet filter granting access to the accounting > > > network). In the > > > first example a role listing the queues/services to which > > > this policy is > > > applicable is reasonable. However, a role binding of the rule to a > > > particular set of queues/services is ambiguous because the > > > gold service > > > queue and the silver service queue would each interpret the > > > rule as "If MY > > > traffic exceeds this threshold reduce MY bandwidth." What we > > > really want is > > > "If MY traffic exceeds this threshold reduce the OTHER > > > bandwidth." In the > > > second example, according to definition 1 of role, the policy > > > server would > > > determine that the role is applicable to the DHCP service and > > > the filters on > > > edge interfaces of the accounting network. Under definition > > > 2, the attribute > > > binding is confusing because the DHCP service has no > packet forwarding > > > service and the routers don't (usually) have a DHCP service. > > > Therefore a > > > subset of the attributes are ambiguous. The only way to > > > disambiguate this > > > type of rule is to qualify the attribute: > > > DHCPService.NewUserAddress and > > > AccountingEdgeInterfaces.SrcAddrFilter. With this level > of attribute > > > qualification, the value of roles under definition 2 seems almost > > > irrelevant. > > > > > > Comments? > > > > > > regards, > > > > > > -Walter > > > > > > > > > > > > From majordomo@raleigh.ibm.com Wed Jan 26 13:35:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08934 for ; Wed, 26 Jan 2000 13:34:59 -0500 (EST) 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 NAA23674; Wed, 26 Jan 2000 13:26:55 -0500 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 NAA29264; Wed, 26 Jan 2000 13:26:56 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56590; Wed, 26 Jan 2000 13:14:23 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43270; Wed, 26 Jan 2000 13:14:20 -0500 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 NAA33756 for ; Wed, 26 Jan 2000 13:14:25 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA23732 for ; Wed, 26 Jan 2000 13:14:20 -0500 Received: from mediaone.net ([192.147.145.184]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id NAA20503; Wed, 26 Jan 2000 13:14:15 -0500 (EST) Message-Id: <388F397F.51B9807B@mediaone.net> Date: Wed, 26 Jan 2000 13:14:23 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <75ADD7496F0BD211ADC000104B8846CF01911547@rerun.lucentctc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit "Weiss, Walter" wrote: > > Jon (Saperia), > > Are you suggesting that a given policy should be restricted to a single > class (the policy equivalent of a PIB/MIB row) and that a > collection/hierarchy of policies be used to implement the example policies I > cited? > > regards, > > -Walter Actually no - I do not think that all policies must necessarily be limited to a single class. I think there should be a class of policies which can span what you would call single client types. I had mentioned this a while ago. It seems logical to me that in some cases policies are modified by others. It is possible that a collection of policies could reasonably be implemented as a hierarchy or in other relationships. It might be fun to use something like rational rose to model real world policies and see the relationships and shared data elements. /jon From majordomo@raleigh.ibm.com Wed Jan 26 14:40:39 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10268 for ; Wed, 26 Jan 2000 14:40:39 -0500 (EST) 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 OAA23558; Wed, 26 Jan 2000 14:34:06 -0500 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 OAA24126; Wed, 26 Jan 2000 14:34:05 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50998; Wed, 26 Jan 2000 14:17:07 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32030; Wed, 26 Jan 2000 14:17:03 -0500 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 OAA26496 for ; Wed, 26 Jan 2000 14:17:07 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA33568 for ; Wed, 26 Jan 2000 14:17:02 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 14:16:31 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Saperia'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Wed, 26 Jan 2000 14:16:31 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" I fear we are on different wavelengths. Perhaps it is just terminology. Can you tell me what you mean by "client types" in your last comment? Thanks, -Walter > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Wednesday, January 26, 2000 1:14 PM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: Re: Policy issues: definition of Roles > > > "Weiss, Walter" wrote: > > > > Jon (Saperia), > > > > Are you suggesting that a given policy should be restricted > to a single > > class (the policy equivalent of a PIB/MIB row) and that a > > collection/hierarchy of policies be used to implement the > example policies I > > cited? > > > > regards, > > > > -Walter > > Actually no - I do not think that all policies must necessarily be > limited to a single class. I think there should be a class of policies > which can span what you would call single client types. I > had mentioned > this a while ago. It seems logical to me that in some cases policies > are modified by others. It is possible that a collection of policies > could reasonably be implemented as a hierarchy or in other > relationships. It might be fun to use something like rational rose to > model real world policies and see the relationships and > shared data elements. > > /jon > From majordomo@raleigh.ibm.com Wed Jan 26 16:06:13 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11456 for ; Wed, 26 Jan 2000 16:06:12 -0500 (EST) 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 QAA27036; Wed, 26 Jan 2000 16:00:34 -0500 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 PAA06784; Wed, 26 Jan 2000 15:57:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48938; Wed, 26 Jan 2000 15:39:13 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50974; Wed, 26 Jan 2000 15:39:08 -0500 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 PAA27618 for ; Wed, 26 Jan 2000 15:39:14 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA36354 for ; Wed, 26 Jan 2000 15:39:08 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 26 Jan 2000 15:38:38 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191154C@rerun.lucentctc.com> From: "Weiss, Walter" To: policy@raleigh.ibm.com Subject: RE: WG Last Call: PCIM (Issue 2) Date: Wed, 26 Jan 2000 15:38:37 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" I was originally planning on dealing with this issue later. However, since PCIM so blatantly raises it and we want to get through last call quickly, I will bring it up now to give adequate time for discussion. In reference to the following text: 2.2. Declarative versus Procedural Model The Policy Core Information Model is declarative, not procedural. Given that standardization efforts in policy should address policy definitions at the role level, the next issue is to decide on a language framework to define policies. There are several design considerations and trade-offs to make in this respect. 1. On one hand, we would like a policy definition language to be reasonably human-friendly for ease of definitions and diagnostics. On the other hand, given the diversity of devices (in terms of their processing capabilities) which could act as policy decision points, we would like to keep the language somewhat machine-friendly, i.e., relatively simple to automate the parsing and processing in network elements. 2. An important decision to make is the semantic style of the language, procedural or declarative. o The procedural approach would model network behavior that is to be regulated through policy in terms of states and pertinent events. In this model, policy directives are statements that control the state transitions and thereby regulate the network behavior. An example of state is installing or removal of packet classification filters and the appropriate configuration actions for traffic conditioning. Examples of events include device boot-up, packet arrival, etc. o The declarative approach would simply describe the desired network behavior in terms of certain actions that should happen when specific conditions hold. For example, a policy directive that states that packets matching a specific traffic profile must be conditioned in a certain way is formulated in terms of conditions that describe the traffic profile and actions that describe the traffic conditioning behavior. A policy rule in this approach is written as "if (policy condition) then ." The declarative approach has the benefit of simplicity, and facilitates hiding implementation differences, making it a suitable candidate for the policy definition language standard. This text raises an interesting question although the terms strike me as somewhat misleading. Therefore, I will first discuss the use of terms and see where we end up. In my understanding of the definitions of procedural and declarative are somewhat different from those used in the text above: Declarative: A set of actions triggered by a well known (possibly canned) condition. Procedural: Any execution stream. The main justification of declarative over procedural was that atomic actions are easier to implement. In addition, simple actions can be grouped to identify and arbitrate conflicts. In contrast, a procedural policy could nest policies (or conditions) within other policies and describe more complicated interactions at the expense of making conflict detection more difficult if not impossible. However, the PCIM text above takes a completely different slant. Declarative is described as a high level behavior of the system while procedural is described as an interaction with the system. So before we go any farther, lets agree on definitions for each of these concepts. I would prefer that we stick with the original definition of declarative and procedural as discussed in previous meetings (and as I have described them in this message). Then we can create terms for the possible ways to represent a policy. If we can agree on my (or someone else's) definitions, we can start on the next set of issues with this text. In the PCIM text as described under declarative, I would suggest the term "Behavioral Simulation Policy." In essence, the policy attempts to simulate the behavior of a system at some high level. In the example given in the declarative section of PCIM above, if a forwarding engine were to interpret this policy directly, it would process the policy on a packet by packet basis (just like an instruction stream). In the PCIM text as described under procedural, I would suggest the term "System Interaction Policy." In this approach, the policy would interact with the system to achieve a global objective. Using the same objective, the policy would use a set specific values in the profile components and traffic conditioning components of the forwarding engine. However, from the policy's perspective, these components are black boxes. Comments... -Walter From majordomo@raleigh.ibm.com Wed Jan 26 21:53:11 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15875 for ; Wed, 26 Jan 2000 21:53:10 -0500 (EST) 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 VAA38678; Wed, 26 Jan 2000 21:49:51 -0500 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 VAA23502; Wed, 26 Jan 2000 21:49:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35876; Wed, 26 Jan 2000 19:02:11 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42756; Wed, 26 Jan 2000 19:02:03 -0500 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 TAA22624 for ; Wed, 26 Jan 2000 19:02:03 -0500 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id TAA32352 for ; Wed, 26 Jan 2000 19:02:00 -0500 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jan 26 19:00:48 EST 2000 Received: from dnrc.bell-labs.com ([202.246.11.136]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA01917 for ; Wed, 26 Jan 2000 19:00:43 -0500 (EST) Message-Id: <388F8A07.7BB9E74F@dnrc.bell-labs.com> Date: Thu, 27 Jan 2000 08:57:59 +0900 From: Kiyoshi Kodama X-Mailer: Mozilla 4.7 [ja] (WinNT; I) X-Accept-Language: ja Mime-Version: 1.0 To: policy@raleigh.ibm.com Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Kiyoshi Kodama Content-Transfer-Encoding: 7bit unsubsribe From majordomo@raleigh.ibm.com Thu Jan 27 10:34:33 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07580 for ; Thu, 27 Jan 2000 10:34:32 -0500 (EST) 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 KAA24200; Thu, 27 Jan 2000 10:30:51 -0500 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 KAA33258; Thu, 27 Jan 2000 10:25:50 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21788; Thu, 27 Jan 2000 09:59:01 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28352; Thu, 27 Jan 2000 09:58:53 -0500 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 IAA33690 for ; Thu, 27 Jan 2000 08:52:45 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA08484 for ; Thu, 27 Jan 2000 08:52:40 -0500 Received: from mediaone.net (1Cust143.tnt1.knoxville.tn.da.uu.net [63.10.97.143]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id GAA25277; Thu, 27 Jan 2000 06:22:11 -0500 (EST) Message-Id: <38902A72.264F071@mediaone.net> Date: Thu, 27 Jan 2000 06:22:25 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit "Weiss, Walter" wrote: > > I fear we are on different wavelengths. Perhaps it is just terminology. Can > you tell me what you mean by "client types" in your last comment? > Sure, that is one of the problems in work like this. What I mean by client types are for example, a COPS differentiated services client type or a security client type - that that has not been talked about as much. My point being that in some cases it is helpful for 'policy' to cross what has come to be accepted as clear divisions of function. I might want my quality of service policy to be modified by an outage policy which says that if the case of a failure, which of the 32 policies for quality of service (where policy in this case translates to a customer) do i want to 'protect' and which am I willing to sacrifice. In this sense, under some conditions a policy is modified by another policy. In my view it is not possible to effectively write a policy that covers every possible interaction so some will have to interact. /jon From majordomo@raleigh.ibm.com Thu Jan 27 11:02:51 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08243 for ; Thu, 27 Jan 2000 11:02:50 -0500 (EST) 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 KAA22728; Thu, 27 Jan 2000 10:58:27 -0500 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 KAA32888; Thu, 27 Jan 2000 10:58:27 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27928; Thu, 27 Jan 2000 10:37:39 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21954; Thu, 27 Jan 2000 10:37:31 -0500 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 KAA05384 for ; Thu, 27 Jan 2000 10:37:31 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAB20772 for ; Thu, 27 Jan 2000 10:37:30 -0500 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 10:35:19 -0500 Message-Id: <6399122981E1D211AB490090271E0AA33C9C41@BMAILNJ> From: Francis Reichmeyer -NJ To: "'Weiss, Walter'" , "'Jon Sjoberg'" , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Thu, 27 Jan 2000 10:35:12 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Francis Reichmeyer -NJ Hi Walter, I think definition #1 is the better of the two with respect to the concept of roles as introduced in the PIB (though I'm not sure a list of interfaces is the best example of a role, you can certainly do it that way). I don't fully understand definition #2 and so I'm having trouble seeing how you are describing that definition in the context of PIB. Just looking at the definition, what is the "role" in the example (preventing new flows) you gave? This would help with understanding, I think. Thanks, -Fran > -----Original Message----- > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > Sent: Wednesday, January 26, 2000 11:08 AM > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Jon, > > To answer your question, Roles were first proposed in the > context of PIBS. > In this context, a PIB row, or subset thereof, was associated > with a group > of one or more services/components. In this context definition 2 is > perfectly reasonable because a PIB row is always unambiguous, > even if it is > applied to a set of instances. In policy, this concept (and > definition 2) > was inherited. However, attributes that will not be part of > the same PIB row > will often coexist in the same policy. As I said in my first > message, I > noticed this confusion during discussions with other folks at > the last IETF. > > regards, > > -Walter > > > -----Original Message----- > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > Sent: Tuesday, January 25, 2000 8:46 PM > > To: policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Not to seem too ignorant, but where did these definitions > > come from? There > > is a definition of roles in "Policy Framework Core > > Information Model -- > > Version 1 Specification", section 5.2, which I can't quite > > match to either > > of the E-mailed definitions. > > > > In this draft a role is defined as: > > "a policy administrator assigns each resource to one or more > > roles, and then > > specifies the policies for each of these roles." > > > > Then, further on, this draft states: > > "Roles are represented in the Core Policy Schema by values of > > the Policy > > Keywords property." > > > > Of which, section 6.1.2 further enumerates to be: > > "This document defines the following keywords: "UNKNOWN", > > "CONFIGURATION", > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and > > "EVENT"." > > > > The best I can see is if we take definition number 1, and > > generalize it out > > several orders, we sorta match the PFCIM definition. Any > > insight to help > > me? > > > > Thanks, > > Jon > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > Sent: Tuesday, January 25, 2000 11:08 AM > > To: policy@raleigh.ibm.com > > Subject: Policy issues: definition of Roles > > > > > > At the last IETF, numerous conversations resulted in a number > > of new issues > > that deserve discussion and consensus. I would like to start > > addressing > > these issues from easiest to hardest with a desire to have > > them all resolved > > prior to the next meeting. My intent is to serialize these > > discussions to > > give each topic a fair hearing. However, if we run out of > > time, I will start > > initiating parallel threads. > > > > The first issue is one I eluded to in my presentation. There > > are apparently > > two definitions for Role: > > > > 1. A role is a list of targets for a policy to be applied > to. In other > > words, if the policy conditions and actions describe some > > interaction with > > or within an interface, the role lists the interfaces that > > the policy is > > applicable to. If the policy describes some OSPF related > > rules, then the > > role is the list of OSPF instances. This definition is more > > applicable to > > how policies are distributed > > > > 2. A role describes the binding between the set of attributes > > used in a > > policy and the actual attributes that exist in a device or > > service. For > > example, a policy that prevents new flows when total > > bandwidth for that flow > > type exceeds 30% of all traffic, may need an explicit binding of the > > bandwidth counter attribute and the flow type definition to a > > particular > > instance of a queue. This definition speaks more to how a policy is > > interpreted. > > > > My take is that these two definitions are nearly the same. > > However, if a > > role is assumed to be associated with the rule, I would be > > inclined to favor > > definition 1. The reason is that I anticipate the possibility > > of policy > > rules that either interact with multiple instances of the > > same time (If Gold > > Traffic exceeds a threshold, lower bandwidth allocation for > > Silver Service) > > or transcend service domains (When a new DHCP accounting user > > is validated > > install a packet filter granting access to the accounting > > network). In the > > first example a role listing the queues/services to which > > this policy is > > applicable is reasonable. However, a role binding of the rule to a > > particular set of queues/services is ambiguous because the > > gold service > > queue and the silver service queue would each interpret the > > rule as "If MY > > traffic exceeds this threshold reduce MY bandwidth." What we > > really want is > > "If MY traffic exceeds this threshold reduce the OTHER > > bandwidth." In the > > second example, according to definition 1 of role, the policy > > server would > > determine that the role is applicable to the DHCP service and > > the filters on > > edge interfaces of the accounting network. Under definition > > 2, the attribute > > binding is confusing because the DHCP service has no packet > forwarding > > service and the routers don't (usually) have a DHCP service. > > Therefore a > > subset of the attributes are ambiguous. The only way to > > disambiguate this > > type of rule is to qualify the attribute: > > DHCPService.NewUserAddress and > > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > > qualification, the value of roles under definition 2 seems almost > > irrelevant. > > > > Comments? > > > > regards, > > > > -Walter > > > > > > > From majordomo@raleigh.ibm.com Thu Jan 27 14:35:32 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13022 for ; Thu, 27 Jan 2000 14:35:27 -0500 (EST) 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 OAA33200; Thu, 27 Jan 2000 14:28:45 -0500 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 OAA26602; Thu, 27 Jan 2000 14:28:44 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21874; Thu, 27 Jan 2000 14:03:35 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43626; Thu, 27 Jan 2000 14:03:32 -0500 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 OAA31834 for ; Thu, 27 Jan 2000 14:03:33 -0500 Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28526 for ; Thu, 27 Jan 2000 14:03:30 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 27 Jan 2000 13:03:55 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 13:03:09 -0600 Message-Id: <63E0DAD7784FD21188310000F80824B30267360B@zmpkdx02.us.nortel.com> From: "Ken Roberts" To: "Weiss, Walter" , policy@raleigh.ibm.com Subject: RE: WG Last Call: PCIM (Issue 2) Date: Thu, 27 Jan 2000 13:03:02 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF68F9.26CC89EC" X-Orig: Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Roberts" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF68F9.26CC89EC Content-Type: text/plain; charset="iso-8859-1" Walter, You raise some interesting thoughts. If I may digress the debate between procedural and declarative I've been through it before. The solution in the past has been to NOT mandate one over the other but to standardize the interface used to request information etc. In this way individuals aren't "limited" and vendors may build machines using whatever technology they think is viable to "answer" the question. The question of course is whether the proposed action/ state change/ etc is consistent with the policies in force at the time. All sorts of possibilities exist to implement the "engine" using all sorts of technologies. I would be disappointed if everyone had to use one, and only one, technology. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. -----Original Message----- From: Weiss, Walter [mailto:WWeiss@lucentctc.com] Sent: Wednesday, January 26, 2000 12:39 PM To: policy@raleigh.ibm.com Subject: RE: WG Last Call: PCIM (Issue 2) I was originally planning on dealing with this issue later. However, since PCIM so blatantly raises it and we want to get through last call quickly, I will bring it up now to give adequate time for discussion. In reference to the following text: 2.2. Declarative versus Procedural Model The Policy Core Information Model is declarative, not procedural. Given that standardization efforts in policy should address policy definitions at the role level, the next issue is to decide on a language framework to define policies. There are several design considerations and trade-offs to make in this respect. 1. On one hand, we would like a policy definition language to be reasonably human-friendly for ease of definitions and diagnostics. On the other hand, given the diversity of devices (in terms of their processing capabilities) which could act as policy decision points, we would like to keep the language somewhat machine-friendly, i.e., relatively simple to automate the parsing and processing in network elements. 2. An important decision to make is the semantic style of the language, procedural or declarative. o The procedural approach would model network behavior that is to be regulated through policy in terms of states and pertinent events. In this model, policy directives are statements that control the state transitions and thereby regulate the network behavior. An example of state is installing or removal of packet classification filters and the appropriate configuration actions for traffic conditioning. Examples of events include device boot-up, packet arrival, etc. o The declarative approach would simply describe the desired network behavior in terms of certain actions that should happen when specific conditions hold. For example, a policy directive that states that packets matching a specific traffic profile must be conditioned in a certain way is formulated in terms of conditions that describe the traffic profile and actions that describe the traffic conditioning behavior. A policy rule in this approach is written as "if (policy condition) then ." The declarative approach has the benefit of simplicity, and facilitates hiding implementation differences, making it a suitable candidate for the policy definition language standard. This text raises an interesting question although the terms strike me as somewhat misleading. Therefore, I will first discuss the use of terms and see where we end up. In my understanding of the definitions of procedural and declarative are somewhat different from those used in the text above: Declarative: A set of actions triggered by a well known (possibly canned) condition. Procedural: Any execution stream. The main justification of declarative over procedural was that atomic actions are easier to implement. In addition, simple actions can be grouped to identify and arbitrate conflicts. In contrast, a procedural policy could nest policies (or conditions) within other policies and describe more complicated interactions at the expense of making conflict detection more difficult if not impossible. However, the PCIM text above takes a completely different slant. Declarative is described as a high level behavior of the system while procedural is described as an interaction with the system. So before we go any farther, lets agree on definitions for each of these concepts. I would prefer that we stick with the original definition of declarative and procedural as discussed in previous meetings (and as I have described them in this message). Then we can create terms for the possible ways to represent a policy. If we can agree on my (or someone else's) definitions, we can start on the next set of issues with this text. In the PCIM text as described under declarative, I would suggest the term "Behavioral Simulation Policy." In essence, the policy attempts to simulate the behavior of a system at some high level. In the example given in the declarative section of PCIM above, if a forwarding engine were to interpret this policy directly, it would process the policy on a packet by packet basis (just like an instruction stream). In the PCIM text as described under procedural, I would suggest the term "System Interaction Policy." In this approach, the policy would interact with the system to achieve a global objective. Using the same objective, the policy would use a set specific values in the profile components and traffic conditioning components of the forwarding engine. However, from the policy's perspective, these components are black boxes. Comments... -Walter ------_=_NextPart_001_01BF68F9.26CC89EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: PCIM (Issue 2)

Walter,
You raise some interesting thoughts. If I may = digress the debate between procedural and declarative I've been through = it before. The solution in the past has been to NOT mandate one over = the other but to standardize the interface used to request information = etc. In this way individuals aren't "limited" and vendors may = build machines using whatever technology they think is viable to = "answer" the question. The question of course is whether the = proposed action/ state change/ etc is consistent with the policies in = force at the time.

All sorts of possibilities exist to implement the = "engine" using all sorts of technologies. I would be = disappointed if everyone had to use one, and only one, = technology.

---------------------------------------------------------------= -----------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   = :        = 655-7844        =         =         ?Direct  : = 408-565-7844
?  Fax    = :        408-565-8226
? email :      = kjr@nortelnetworks.com
 
This message may contain information proprietary to = Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.

 -----Original Message-----
From:   Weiss, Walter [mailto:WWeiss@lucentctc.com] =
Sent:   Wednesday, January 26, 2000 12:39 = PM
To:     = policy@raleigh.ibm.com
Subject:        = RE: WG Last Call: PCIM (Issue 2)

I was originally planning on dealing with this issue = later. However, since
PCIM so blatantly raises it and we want to get = through last call quickly, I
will bring it up now to give adequate time for = discussion. In reference to
the following text:

<PCIM>
2.2. Declarative versus Procedural Model

   The Policy Core Information Model is = declarative, not procedural.
   Given that standardization efforts in = policy should address policy
   definitions at the role level, the next = issue is to decide on a
   language framework to define = policies.  There are several design
   considerations and trade-offs to make = in this respect.

   1.  On one hand, we would like a = policy definition language to be
       reasonably = human-friendly for ease of definitions and
       = diagnostics.  On the other hand, given the diversity of devices
       (in terms of = their processing capabilities) which could act as
       policy decision = points, we would like to keep the language
       somewhat = machine-friendly, i.e., relatively simple to automate
       the parsing and = processing in network elements.

  2.  An important decision to make is the = semantic style of the
       language, = procedural or declarative.

       o  The = procedural approach would model network behavior that is
           = to be regulated through policy in terms of states and
           = pertinent events.  In this model, policy directives are
           = statements that control the state transitions and thereby
           = regulate the network behavior.  An example of state is
           = installing or removal of packet classification filters  and
           = the appropriate configuration actions for traffic
           = conditioning.  Examples of events include device boot-up,
           = packet arrival, etc.

       o  The = declarative approach would simply describe the desired
           = network behavior in terms of certain actions that should
           = happen when specific conditions hold.  For example, a = policy
           = directive that states that packets matching a specific traffic
           = profile must be conditioned in a certain way is formulated in
           = terms of conditions that describe the traffic profile and
           = actions that describe the traffic conditioning behavior.  A
           = policy rule in this approach is written as "if (policy
           = condition) then <policy action>."

       The declarative = approach has the benefit of simplicity, and
       facilitates = hiding implementation differences, making it a
       suitable = candidate for the policy definition language standard.
</PCIM>

This text raises an interesting question although the = terms strike me as
somewhat misleading. Therefore, I will first discuss = the use of terms and
see where we end up. In my understanding of the = definitions of procedural
and declarative are somewhat different from those = used in the text above:

Declarative: A set of actions triggered by a well = known (possibly canned)
condition.
Procedural: Any execution stream.

The main justification of declarative over procedural = was that atomic
actions are easier to implement. In addition, simple = actions can be grouped
to identify and arbitrate conflicts. In contrast, a = procedural policy could
nest policies (or conditions) within other policies = and describe more
complicated interactions at the expense of making = conflict detection more
difficult if not impossible.

However, the PCIM text above takes a completely = different slant. Declarative
is described as a high level behavior of the system = while procedural is
described as an interaction with the system. So = before we go any farther,
lets agree on definitions for each of these = concepts. I would prefer that we
stick with the original definition of declarative = and procedural as
discussed in previous meetings (and as I have = described them in this
message). Then we can create terms for the possible = ways to represent a
policy. If we can agree on my (or someone else's) = definitions, we can start
on the next set of issues with this text.

In the PCIM text as described under declarative, I = would suggest the term
"Behavioral Simulation Policy." In = essence, the policy attempts to simulate
the behavior of a system at some high level. In the = example given in the
declarative section of PCIM above, if a forwarding = engine were to interpret
this policy directly, it would process the policy on = a packet by packet
basis (just like an instruction stream).

In the PCIM text as described under procedural, I = would suggest the term
"System Interaction Policy." In this = approach, the policy would interact
with the system to achieve a global objective. Using = the same objective, the
policy would use a set specific values in the = profile components and traffic
conditioning components of the forwarding engine. = However, from the policy's
perspective, these components are black = boxes.

Comments...

-Walter

------_=_NextPart_001_01BF68F9.26CC89EC-- From majordomo@raleigh.ibm.com Thu Jan 27 18:22:54 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16699 for ; Thu, 27 Jan 2000 18:22:53 -0500 (EST) 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 SAA21900; Thu, 27 Jan 2000 18:12:56 -0500 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 SAA27428; Thu, 27 Jan 2000 18:12:44 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22008; Thu, 27 Jan 2000 17:53:08 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57070; Thu, 27 Jan 2000 17:53:05 -0500 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 RAA29656 for ; Thu, 27 Jan 2000 17:53:06 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA26754 for ; Thu, 27 Jan 2000 17:52:22 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 17:39:50 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191155A@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Saperia'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Thu, 27 Jan 2000 17:39:46 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Jon, The notion of policy hierarchies bleeds a bit into the other thread I posted yesterday. In the context of declarative policies (as I defined them), there was some debate during the meetings over whether policy nesting or even ordering should be allowed due to the additional complexity (particularly in conflict detection). I would also point out that you have sliced the problem a little differently from the way I sliced it in my original message. I suggested that it is possible to have a single policy that crossed resource/technology/client type boundaries. You on the other hand suggested that a policy be restricted to within a single resource but that another policy could bind two resource specific policies together. These two alternative approaches are also well worth discussing (if you want). However, I would suggest a separate thread because I would like to close on the terminology in this one. regards, -Walter > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Thursday, January 27, 2000 6:22 AM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: Re: Policy issues: definition of Roles > > > "Weiss, Walter" wrote: > > > > I fear we are on different wavelengths. Perhaps it is just > terminology. Can > > you tell me what you mean by "client types" in your last comment? > > > Sure, that is one of the problems in work like this. What I mean by > client types are for example, a COPS differentiated services > client type > or a security client type - that that has not been talked > about as much. > My point being that in some cases it is helpful for 'policy' to cross > what has come to be accepted as clear divisions of function. I might > want my quality of service policy to be modified by an outage policy > which says that if the case of a failure, which of the 32 policies for > quality of service (where policy in this case translates to a > customer) > do i want to 'protect' and which am I willing to sacrifice. In this > sense, under some conditions a policy is modified by another policy. > > In my view it is not possible to effectively write a policy > that covers > every possible interaction so some will have to interact. > > /jon > From majordomo@raleigh.ibm.com Thu Jan 27 18:22:56 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16709 for ; Thu, 27 Jan 2000 18:22:55 -0500 (EST) 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 SAA21438; Thu, 27 Jan 2000 18:13:26 -0500 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 SAA07194; Thu, 27 Jan 2000 18:13:09 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38314; Thu, 27 Jan 2000 17:51:52 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38304; Thu, 27 Jan 2000 17:51:49 -0500 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 RAA21604 for ; Thu, 27 Jan 2000 17:51:50 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA32678 for ; Thu, 27 Jan 2000 17:51:42 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 17:03:09 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF01911558@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Francis Reichmeyer -NJ'" , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Thu, 27 Jan 2000 17:03:02 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Fran, I believe poor definitions for terms is exactly why we are having so much trouble making progress. Hence, I applaud the work you folks are doing in the terminology draft. So let's try to work on the question you posed. In many of the discussions I have been in (and presentations I have seen), I have seen roles used for two distinct objectives. In one case a role is used as a means for determining the policy targets (i.e., the set of components or services that the policy will either be influenced by or influence). In the more explicit interpretation of role, there has been a desire to provide a binding between the attributes expressed in the policy and the actual attributes in the component or service interacting with (influenced or being influenced by) policies. Now, in PIBs and MIBs the binding between the attribute values in the message and the actual attributes in the device is implicit because the attributes are grouped together is such a way that all the attributes are easily bound. Let's consider a hypothetical case where we constructed a MIB or PIB that contained the two dropping thresholds for two different queues without specifying the queue. In this case, there would be no way to determine which threshold was for which queue. However, we don't do this in MIBs or PIBs. In practice, we create separate row for each specific queue with a set of attributes for that queue. This way, we specify the queue number is specified once in the message and we know that all remaining attributes are for the queue. The identification of the queue we are interested in is just like definition 2 of a role in that it binds a set of values to a specific instance of a queue. In policy, as I have pointed out earlier, it is quite common for policy to be too broadly defined so that a binding to specific attributes at the policy level is insufficient for the proper interpretation of the policy. A simple example: Set Queue2's drop threshold to Queue1's drop threshold. If you said that the role for the policy was Queue1 and Queue2, you still don't know which instance of a threshold to assign to which other threshold. You need a more explicit binding in the policy itself (Queue1.DropThreshold = Queue2.DropThreshold). The concept of a role is still valuable because you can provide a larger context for the policy such as "for this set of interfaces on this set of switches." This is why I would like to prevent the definition of role from implying attribute level bindings in policies (Hence my opposition to definition 2). Hope I am becoming clearer. regards, -Walter > -----Original Message----- > From: Francis Reichmeyer -NJ [mailto:FranR@iphighway.com] > Sent: Thursday, January 27, 2000 10:35 AM > To: 'Weiss, Walter'; 'Jon Sjoberg'; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Hi Walter, > > I think definition #1 is the better of the two with respect > to the concept of roles as introduced in the PIB (though I'm > not sure a list of interfaces is the best example of a role, > you can certainly do it that way). > > I don't fully understand definition #2 and so I'm having > trouble seeing how you are describing that definition in > the context of PIB. Just looking at the definition, what is > the "role" in the example (preventing new flows) you gave? > This would help with understanding, I think. > > Thanks, > -Fran > > > > -----Original Message----- > > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > > Sent: Wednesday, January 26, 2000 11:08 AM > > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Jon, > > > > To answer your question, Roles were first proposed in the > > context of PIBS. > > In this context, a PIB row, or subset thereof, was associated > > with a group > > of one or more services/components. In this context definition 2 is > > perfectly reasonable because a PIB row is always unambiguous, > > even if it is > > applied to a set of instances. In policy, this concept (and > > definition 2) > > was inherited. However, attributes that will not be part of > > the same PIB row > > will often coexist in the same policy. As I said in my first > > message, I > > noticed this confusion during discussions with other folks at > > the last IETF. > > > > regards, > > > > -Walter > > > > > -----Original Message----- > > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > > Sent: Tuesday, January 25, 2000 8:46 PM > > > To: policy@raleigh.ibm.com > > > Subject: RE: Policy issues: definition of Roles > > > > > > > > > Not to seem too ignorant, but where did these definitions > > > come from? There > > > is a definition of roles in "Policy Framework Core > > > Information Model -- > > > Version 1 Specification", section 5.2, which I can't quite > > > match to either > > > of the E-mailed definitions. > > > > > > In this draft a role is defined as: > > > "a policy administrator assigns each resource to one or more > > > roles, and then > > > specifies the policies for each of these roles." > > > > > > Then, further on, this draft states: > > > "Roles are represented in the Core Policy Schema by values of > > > the Policy > > > Keywords property." > > > > > > Of which, section 6.1.2 further enumerates to be: > > > "This document defines the following keywords: "UNKNOWN", > > > "CONFIGURATION", > > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", > "INSTALLATION", and > > > "EVENT"." > > > > > > The best I can see is if we take definition number 1, and > > > generalize it out > > > several orders, we sorta match the PFCIM definition. Any > > > insight to help > > > me? > > > > > > Thanks, > > > Jon > > > -----Original Message----- > > > From: policy-owner@raleigh.ibm.com > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > > Sent: Tuesday, January 25, 2000 11:08 AM > > > To: policy@raleigh.ibm.com > > > Subject: Policy issues: definition of Roles > > > > > > > > > At the last IETF, numerous conversations resulted in a number > > > of new issues > > > that deserve discussion and consensus. I would like to start > > > addressing > > > these issues from easiest to hardest with a desire to have > > > them all resolved > > > prior to the next meeting. My intent is to serialize these > > > discussions to > > > give each topic a fair hearing. However, if we run out of > > > time, I will start > > > initiating parallel threads. > > > > > > The first issue is one I eluded to in my presentation. There > > > are apparently > > > two definitions for Role: > > > > > > 1. A role is a list of targets for a policy to be applied > > to. In other > > > words, if the policy conditions and actions describe some > > > interaction with > > > or within an interface, the role lists the interfaces that > > > the policy is > > > applicable to. If the policy describes some OSPF related > > > rules, then the > > > role is the list of OSPF instances. This definition is more > > > applicable to > > > how policies are distributed > > > > > > 2. A role describes the binding between the set of attributes > > > used in a > > > policy and the actual attributes that exist in a device or > > > service. For > > > example, a policy that prevents new flows when total > > > bandwidth for that flow > > > type exceeds 30% of all traffic, may need an explicit > binding of the > > > bandwidth counter attribute and the flow type definition to a > > > particular > > > instance of a queue. This definition speaks more to how a > policy is > > > interpreted. > > > > > > My take is that these two definitions are nearly the same. > > > However, if a > > > role is assumed to be associated with the rule, I would be > > > inclined to favor > > > definition 1. The reason is that I anticipate the possibility > > > of policy > > > rules that either interact with multiple instances of the > > > same time (If Gold > > > Traffic exceeds a threshold, lower bandwidth allocation for > > > Silver Service) > > > or transcend service domains (When a new DHCP accounting user > > > is validated > > > install a packet filter granting access to the accounting > > > network). In the > > > first example a role listing the queues/services to which > > > this policy is > > > applicable is reasonable. However, a role binding of the rule to a > > > particular set of queues/services is ambiguous because the > > > gold service > > > queue and the silver service queue would each interpret the > > > rule as "If MY > > > traffic exceeds this threshold reduce MY bandwidth." What we > > > really want is > > > "If MY traffic exceeds this threshold reduce the OTHER > > > bandwidth." In the > > > second example, according to definition 1 of role, the policy > > > server would > > > determine that the role is applicable to the DHCP service and > > > the filters on > > > edge interfaces of the accounting network. Under definition > > > 2, the attribute > > > binding is confusing because the DHCP service has no packet > > forwarding > > > service and the routers don't (usually) have a DHCP service. > > > Therefore a > > > subset of the attributes are ambiguous. The only way to > > > disambiguate this > > > type of rule is to qualify the attribute: > > > DHCPService.NewUserAddress and > > > AccountingEdgeInterfaces.SrcAddrFilter. With this level > of attribute > > > qualification, the value of roles under definition 2 seems almost > > > irrelevant. > > > > > > Comments? > > > > > > regards, > > > > > > -Walter > > > > > > > > > > > > From majordomo@raleigh.ibm.com Thu Jan 27 18:41:34 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16828 for ; Thu, 27 Jan 2000 18:41:33 -0500 (EST) 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 SAA44708; Thu, 27 Jan 2000 18:36:23 -0500 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 SAA26712; Thu, 27 Jan 2000 18:33:27 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39824; Thu, 27 Jan 2000 18:13:59 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54916; Thu, 27 Jan 2000 18:13:56 -0500 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 SAA35564 for ; Thu, 27 Jan 2000 18:13:55 -0500 Received: from bmail.brm.com ([199.203.56.248]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA25276 for ; Thu, 27 Jan 2000 18:13:35 -0500 Received: from bfw.brm.com (199.203.56.254 [199.203.56.254]) by bmail.brm.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DW5A8C5X; Fri, 28 Jan 2000 00:24:21 +0200 Message-Id: <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 27 Jan 2000 17:04:58 -0500 To: Jon Saperia , "Weiss, Walter" From: Shai Herzog Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <38902A72.264F071@mediaone.net> References: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Shai Herzog At 06:22 AM 01/27/2000, Jon Saperia wrote: >In my view it is not possible to effectively write a policy that covers >every possible interaction so some will have to interact. > >/jon I tend to agree. I think this is the reason for the Client-Type separation, however it is important to note that this limitation is one for the PEP only, and not for the PDP. While we can't predict and write all combination of standard policies that cross client type boundaries, the PDP in its "proprietary logic" could figure out what to do and send it to the PEP as two sets of instructions, one for each client type. (This is where the differentiation factors between vendors may spark ingenuity.) As for the definition of Roles, I hate to say it, but I think that neither 1 or 2 are true definitions because they are tied down to specific implementation (PIB/Rule binding, etc.). I think that a Role is a more general concept and the definition should reflect it. Perhaps a definition should look something like: "A Role represent an attribute of a network node or an interface that reflect physical or logical functionality. Those attribute may be used by policy systems to determine the appropriate policy that should be constructed for that node or interface." And role combination: "A set of one or more Roles that are grouped together as a basic atomic unit for which policy instructions are needed". What do you think? Shai __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Main: (508) 620-1141 Framingham, MA 01701 Fax : (212) 656-1006 From majordomo@raleigh.ibm.com Thu Jan 27 18:51:03 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16881 for ; Thu, 27 Jan 2000 18:51:02 -0500 (EST) 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 SAA27080; Thu, 27 Jan 2000 18:46:17 -0500 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 SAA27400; Thu, 27 Jan 2000 18:46:16 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52182; Thu, 27 Jan 2000 18:26:18 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57036; Thu, 27 Jan 2000 18:26:15 -0500 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 SAA35266 for ; Thu, 27 Jan 2000 18:26:17 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA32110 for ; Thu, 27 Jan 2000 18:25:48 -0500 Received: from bnatale (dhcpeast2.acec.com [192.152.208.45]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id SAA14122; Thu, 27 Jan 2000 18:08:08 -0500 (EST) Message-Id: <4.2.2.20000127180750.01fb6290@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 18:11:57 -0500 To: "Ken Roberts" From: Bob Natale Subject: RE: WG Last Call: PCIM (Issue 2) Cc: policy@raleigh.ibm.com In-Reply-To: <63E0DAD7784FD21188310000F80824B30267360B@zmpkdx02.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/27/2000:02:03 PM, Ken Roberts wrote: Hi Ken, >All sorts of possibilities exist to implement the "engine" using all sorts of technologies. >I would be disappointed if everyone had to use one, and only one, technology. I couldn't agree with you more. And this latter mistake -- i.e., mandating (deliberately or inadvertently) one particular interpretation or implementation choice over all others -- was something that was assidiously avoided in past successful IETF work...but seems to be slipping into more and more WG outputs in recent times. I hope we can reverse that trend. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Thu Jan 27 21:24:54 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17882 for ; Thu, 27 Jan 2000 21:24:53 -0500 (EST) 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 VAA17552; Thu, 27 Jan 2000 21:19:57 -0500 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 VAA27098; Thu, 27 Jan 2000 21:19:56 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56748; Thu, 27 Jan 2000 21:02:13 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56732; Thu, 27 Jan 2000 21:02:09 -0500 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 VAA25274 for ; Thu, 27 Jan 2000 21:02:10 -0500 Received: from 21cn.com ([202.104.32.241]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id VAA40938 for ; Thu, 27 Jan 2000 21:01:44 -0500 Received: from 21cn.com([10.1.0.101]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/1/jm7038910624; Fri, 28 Jan 2000 02:02:08 -0000 Received: from fwns1.raleigh.ibm.com([204.146.167.235]) by 21cn.com(JetMail 2.3.2.1) with SMTP id /aimcque/jmail.rcv/1/jm63890762b; Thu, 27 Jan 2000 16:00:52 -0000 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 KAA24862; Thu, 27 Jan 2000 10:58:44 -0500 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 KAA27268; Thu, 27 Jan 2000 10:58:42 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27928; Thu, 27 Jan 2000 10:37:39 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21954; Thu, 27 Jan 2000 10:37:31 -0500 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 KAA05384 for ; Thu, 27 Jan 2000 10:37:31 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAB20772 for ; Thu, 27 Jan 2000 10:37:30 -0500 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 10:35:19 -0500 Message-Id: <6399122981E1D211AB490090271E0AA33C9C41@BMAILNJ> From: Francis Reichmeyer -NJ To: "'Weiss, Walter'" , "'Jon Sjoberg'" , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Thu, 27 Jan 2000 10:35:12 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Francis Reichmeyer -NJ Hi Walter, I think definition #1 is the better of the two with respect to the concept of roles as introduced in the PIB (though I'm not sure a list of interfaces is the best example of a role, you can certainly do it that way). I don't fully understand definition #2 and so I'm having trouble seeing how you are describing that definition in the context of PIB. Just looking at the definition, what is the "role" in the example (preventing new flows) you gave? This would help with understanding, I think. Thanks, -Fran > -----Original Message----- > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > Sent: Wednesday, January 26, 2000 11:08 AM > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Jon, > > To answer your question, Roles were first proposed in the > context of PIBS. > In this context, a PIB row, or subset thereof, was associated > with a group > of one or more services/components. In this context definition 2 is > perfectly reasonable because a PIB row is always unambiguous, > even if it is > applied to a set of instances. In policy, this concept (and > definition 2) > was inherited. However, attributes that will not be part of > the same PIB row > will often coexist in the same policy. As I said in my first > message, I > noticed this confusion during discussions with other folks at > the last IETF. > > regards, > > -Walter > > > -----Original Message----- > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > Sent: Tuesday, January 25, 2000 8:46 PM > > To: policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Not to seem too ignorant, but where did these definitions > > come from? There > > is a definition of roles in "Policy Framework Core > > Information Model -- > > Version 1 Specification", section 5.2, which I can't quite > > match to either > > of the E-mailed definitions. > > > > In this draft a role is defined as: > > "a policy administrator assigns each resource to one or more > > roles, and then > > specifies the policies for each of these roles." > > > > Then, further on, this draft states: > > "Roles are represented in the Core Policy Schema by values of > > the Policy > > Keywords property." > > > > Of which, section 6.1.2 further enumerates to be: > > "This document defines the following keywords: "UNKNOWN", > > "CONFIGURATION", > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and > > "EVENT"." > > > > The best I can see is if we take definition number 1, and > > generalize it out > > several orders, we sorta match the PFCIM definition. Any > > insight to help > > me? > > > > Thanks, > > Jon > > -----Original Message----- > > From: policy-owner@raleigh.ibm.com > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > Sent: Tuesday, January 25, 2000 11:08 AM > > To: policy@raleigh.ibm.com > > Subject: Policy issues: definition of Roles > > > > > > At the last IETF, numerous conversations resulted in a number > > of new issues > > that deserve discussion and consensus. I would like to start > > addressing > > these issues from easiest to hardest with a desire to have > > them all resolved > > prior to the next meeting. My intent is to serialize these > > discussions to > > give each topic a fair hearing. However, if we run out of > > time, I will start > > initiating parallel threads. > > > > The first issue is one I eluded to in my presentation. There > > are apparently > > two definitions for Role: > > > > 1. A role is a list of targets for a policy to be applied > to. In other > > words, if the policy conditions and actions describe some > > interaction with > > or within an interface, the role lists the interfaces that > > the policy is > > applicable to. If the policy describes some OSPF related > > rules, then the > > role is the list of OSPF instances. This definition is more > > applicable to > > how policies are distributed > > > > 2. A role describes the binding between the set of attributes > > used in a > > policy and the actual attributes that exist in a device or > > service. For > > example, a policy that prevents new flows when total > > bandwidth for that flow > > type exceeds 30% of all traffic, may need an explicit binding of the > > bandwidth counter attribute and the flow type definition to a > > particular > > instance of a queue. This definition speaks more to how a policy is > > interpreted. > > > > My take is that these two definitions are nearly the same. > > However, if a > > role is assumed to be associated with the rule, I would be > > inclined to favor > > definition 1. The reason is that I anticipate the possibility > > of policy > > rules that either interact with multiple instances of the > > same time (If Gold > > Traffic exceeds a threshold, lower bandwidth allocation for > > Silver Service) > > or transcend service domains (When a new DHCP accounting user > > is validated > > install a packet filter granting access to the accounting > > network). In the > > first example a role listing the queues/services to which > > this policy is > > applicable is reasonable. However, a role binding of the rule to a > > particular set of queues/services is ambiguous because the > > gold service > > queue and the silver service queue would each interpret the > > rule as "If MY > > traffic exceeds this threshold reduce MY bandwidth." What we > > really want is > > "If MY traffic exceeds this threshold reduce the OTHER > > bandwidth." In the > > second example, according to definition 1 of role, the policy > > server would > > determine that the role is applicable to the DHCP service and > > the filters on > > edge interfaces of the accounting network. Under definition > > 2, the attribute > > binding is confusing because the DHCP service has no packet > forwarding > > service and the routers don't (usually) have a DHCP service. > > Therefore a > > subset of the attributes are ambiguous. The only way to > > disambiguate this > > type of rule is to qualify the attribute: > > DHCPService.NewUserAddress and > > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute > > qualification, the value of roles under definition 2 seems almost > > irrelevant. > > > > Comments? > > > > regards, > > > > -Walter > > > > > > > From majordomo@raleigh.ibm.com Thu Jan 27 23:52:12 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21024 for ; Thu, 27 Jan 2000 23:52:11 -0500 (EST) 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 XAA32648; Thu, 27 Jan 2000 23:48:34 -0500 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 XAA25746; Thu, 27 Jan 2000 23:48:35 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43768; Thu, 27 Jan 2000 23:27:53 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39920; Thu, 27 Jan 2000 23:27:50 -0500 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 XAA27278 for ; Thu, 27 Jan 2000 23:27:53 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA41024 for ; Thu, 27 Jan 2000 23:27:49 -0500 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id ; Thu, 27 Jan 2000 23:25:38 -0500 Message-Id: <6399122981E1D211AB490090271E0AA33C9C4F@BMAILNJ> From: Francis Reichmeyer -NJ To: "'Weiss, Walter'" , Francis Reichmeyer -NJ , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Thu, 27 Jan 2000 23:25:35 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Francis Reichmeyer -NJ Walter, > -----Original Message----- > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > Sent: Thursday, January 27, 2000 5:03 PM > To: 'Francis Reichmeyer -NJ'; policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Fran, > > I believe poor definitions for terms is exactly why we are > having so much > trouble making progress. Hence, I applaud the work you folks > are doing in > the terminology draft. So let's try to work on the question you posed. I'd say the trouble lies more in 'overloaded' definitions, rather than 'poor' ones, but I agree (just different terminology ;^) Also, discussions and threads like this should go a long way towrards helping to close the gap between some different conceptions. > > In many of the discussions I have been in (and presentations > I have seen), I > have seen roles used for two distinct objectives. In one case > a role is used > as a means for determining the policy targets (i.e., the set > of components > or services that the policy will either be influenced by or > influence). In > the more explicit interpretation of role, there has been a > desire to provide > a binding between the attributes expressed in the policy and > the actual > attributes in the component or service interacting with > (influenced or being > influenced by) policies. Now, in PIBs and MIBs the binding between the > attribute values in the message and the actual attributes in > the device is > implicit because the attributes are grouped together is such > a way that all > the attributes are easily bound. Let's consider a > hypothetical case where we > constructed a MIB or PIB that contained the two dropping > thresholds for two > different queues without specifying the queue. In this case, > there would be > no way to determine which threshold was for which queue. > However, we don't > do this in MIBs or PIBs. In practice, we create separate row for each > specific queue with a set of attributes for that queue. This > way, we specify > the queue number is specified once in the message and we know that all > remaining attributes are for the queue. The identification of > the queue we > are interested in is just like definition 2 of a role in that > it binds a set > of values to a specific instance of a queue. > > In policy, as I have pointed out earlier, it is quite common > for policy to > be too broadly defined so that a binding to specific attributes at the > policy level is insufficient for the proper interpretation of > the policy. A > simple example: > > Set Queue2's drop threshold to Queue1's drop threshold. > > If you said that the role for the policy was Queue1 and > Queue2, you > still don't know which instance of a threshold to assign to > which other > threshold. You need a more explicit binding in the policy itself > (Queue1.DropThreshold = Queue2.DropThreshold). The concept of > a role is > still valuable because you can provide a larger context for > the policy such > as "for this set of interfaces on this set of switches." Right, agreed. The role for a policy like the one in your example should not be "Queue1 and Queue2". However, the role could be "all interfaces that support Queue1 and Queue2", which I think is basically what you are saying. Thanks, -Fran > > This is why I would like to prevent the definition of role > from implying > attribute level bindings in policies (Hence my opposition to > definition 2). > Hope I am becoming clearer. > > regards, > > -Walter > > > -----Original Message----- > > From: Francis Reichmeyer -NJ [mailto:FranR@iphighway.com] > > Sent: Thursday, January 27, 2000 10:35 AM > > To: 'Weiss, Walter'; 'Jon Sjoberg'; policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > > > > > > Hi Walter, > > > > I think definition #1 is the better of the two with respect > > to the concept of roles as introduced in the PIB (though I'm > > not sure a list of interfaces is the best example of a role, > > you can certainly do it that way). > > > > I don't fully understand definition #2 and so I'm having > > trouble seeing how you are describing that definition in > > the context of PIB. Just looking at the definition, what is > > the "role" in the example (preventing new flows) you gave? > > This would help with understanding, I think. > > > > Thanks, > > -Fran > > > > > > > -----Original Message----- > > > From: Weiss, Walter [mailto:WWeiss@lucentctc.com] > > > Sent: Wednesday, January 26, 2000 11:08 AM > > > To: 'Jon Sjoberg'; policy@raleigh.ibm.com > > > Subject: RE: Policy issues: definition of Roles > > > > > > > > > Jon, > > > > > > To answer your question, Roles were first proposed in the > > > context of PIBS. > > > In this context, a PIB row, or subset thereof, was associated > > > with a group > > > of one or more services/components. In this context > definition 2 is > > > perfectly reasonable because a PIB row is always unambiguous, > > > even if it is > > > applied to a set of instances. In policy, this concept (and > > > definition 2) > > > was inherited. However, attributes that will not be part of > > > the same PIB row > > > will often coexist in the same policy. As I said in my first > > > message, I > > > noticed this confusion during discussions with other folks at > > > the last IETF. > > > > > > regards, > > > > > > -Walter > > > > > > > -----Original Message----- > > > > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > > > > Sent: Tuesday, January 25, 2000 8:46 PM > > > > To: policy@raleigh.ibm.com > > > > Subject: RE: Policy issues: definition of Roles > > > > > > > > > > > > Not to seem too ignorant, but where did these definitions > > > > come from? There > > > > is a definition of roles in "Policy Framework Core > > > > Information Model -- > > > > Version 1 Specification", section 5.2, which I can't quite > > > > match to either > > > > of the E-mailed definitions. > > > > > > > > In this draft a role is defined as: > > > > "a policy administrator assigns each resource to one or more > > > > roles, and then > > > > specifies the policies for each of these roles." > > > > > > > > Then, further on, this draft states: > > > > "Roles are represented in the Core Policy Schema by values of > > > > the Policy > > > > Keywords property." > > > > > > > > Of which, section 6.1.2 further enumerates to be: > > > > "This document defines the following keywords: "UNKNOWN", > > > > "CONFIGURATION", > > > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", > > "INSTALLATION", and > > > > "EVENT"." > > > > > > > > The best I can see is if we take definition number 1, and > > > > generalize it out > > > > several orders, we sorta match the PFCIM definition. Any > > > > insight to help > > > > me? > > > > > > > > Thanks, > > > > Jon > > > > -----Original Message----- > > > > From: policy-owner@raleigh.ibm.com > > > > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Weiss, Walter > > > > Sent: Tuesday, January 25, 2000 11:08 AM > > > > To: policy@raleigh.ibm.com > > > > Subject: Policy issues: definition of Roles > > > > > > > > > > > > At the last IETF, numerous conversations resulted in a number > > > > of new issues > > > > that deserve discussion and consensus. I would like to start > > > > addressing > > > > these issues from easiest to hardest with a desire to have > > > > them all resolved > > > > prior to the next meeting. My intent is to serialize these > > > > discussions to > > > > give each topic a fair hearing. However, if we run out of > > > > time, I will start > > > > initiating parallel threads. > > > > > > > > The first issue is one I eluded to in my presentation. There > > > > are apparently > > > > two definitions for Role: > > > > > > > > 1. A role is a list of targets for a policy to be applied > > > to. In other > > > > words, if the policy conditions and actions describe some > > > > interaction with > > > > or within an interface, the role lists the interfaces that > > > > the policy is > > > > applicable to. If the policy describes some OSPF related > > > > rules, then the > > > > role is the list of OSPF instances. This definition is more > > > > applicable to > > > > how policies are distributed > > > > > > > > 2. A role describes the binding between the set of attributes > > > > used in a > > > > policy and the actual attributes that exist in a device or > > > > service. For > > > > example, a policy that prevents new flows when total > > > > bandwidth for that flow > > > > type exceeds 30% of all traffic, may need an explicit > > binding of the > > > > bandwidth counter attribute and the flow type definition to a > > > > particular > > > > instance of a queue. This definition speaks more to how a > > policy is > > > > interpreted. > > > > > > > > My take is that these two definitions are nearly the same. > > > > However, if a > > > > role is assumed to be associated with the rule, I would be > > > > inclined to favor > > > > definition 1. The reason is that I anticipate the possibility > > > > of policy > > > > rules that either interact with multiple instances of the > > > > same time (If Gold > > > > Traffic exceeds a threshold, lower bandwidth allocation for > > > > Silver Service) > > > > or transcend service domains (When a new DHCP accounting user > > > > is validated > > > > install a packet filter granting access to the accounting > > > > network). In the > > > > first example a role listing the queues/services to which > > > > this policy is > > > > applicable is reasonable. However, a role binding of > the rule to a > > > > particular set of queues/services is ambiguous because the > > > > gold service > > > > queue and the silver service queue would each interpret the > > > > rule as "If MY > > > > traffic exceeds this threshold reduce MY bandwidth." What we > > > > really want is > > > > "If MY traffic exceeds this threshold reduce the OTHER > > > > bandwidth." In the > > > > second example, according to definition 1 of role, the policy > > > > server would > > > > determine that the role is applicable to the DHCP service and > > > > the filters on > > > > edge interfaces of the accounting network. Under definition > > > > 2, the attribute > > > > binding is confusing because the DHCP service has no packet > > > forwarding > > > > service and the routers don't (usually) have a DHCP service. > > > > Therefore a > > > > subset of the attributes are ambiguous. The only way to > > > > disambiguate this > > > > type of rule is to qualify the attribute: > > > > DHCPService.NewUserAddress and > > > > AccountingEdgeInterfaces.SrcAddrFilter. With this level > > of attribute > > > > qualification, the value of roles under definition 2 > seems almost > > > > irrelevant. > > > > > > > > Comments? > > > > > > > > regards, > > > > > > > > -Walter > > > > > > > > > > > > > > > > > > From majordomo@raleigh.ibm.com Fri Jan 28 01:17:07 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22414 for ; Fri, 28 Jan 2000 01:17:06 -0500 (EST) 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 BAA21790; Fri, 28 Jan 2000 01:13:14 -0500 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 BAA24242; Fri, 28 Jan 2000 01:13:13 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56276; Fri, 28 Jan 2000 00:52:56 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54986; Fri, 28 Jan 2000 00:52:52 -0500 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 AAA28876 for ; Fri, 28 Jan 2000 00:52:55 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA26218 for ; Fri, 28 Jan 2000 00:52:51 -0500 Received: from bnatale (dhcppm7.acec.com [38.249.211.229]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id AAA15295; Fri, 28 Jan 2000 00:51:09 -0500 (EST) Message-Id: <4.2.2.20000128004836.00b196b8@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 00:55:03 -0500 To: Shai Herzog From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> References: <38902A72.264F071@mediaone.net> <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/27/2000:05:04 PM, Shai Herzog wrote: Hi Shai, ><...> >I think that a Role is a more general concept and the definition >should reflect it. I agree (true of most defintions in efforts such as these). >Perhaps a definition should look something like: > >"A Role represent an attribute of a network node or an interface >that reflect physical or logical functionality. Those attribute may be >used by policy systems to determine the appropriate policy that >should be constructed for that node or interface." > >And role combination: > >"A set of one or more Roles that are grouped together as a basic >atomic unit for which policy instructions are needed". > >What do you think? I like them, except that I would change "A Role represents an attribute of a network node or an interface..." to "A Role is a representation of a policy target..." or "...of a policy object..." or some other similar generic abstract term. I would try to avoid pining the language to specific device types or categories (esp. since software entities might also be the targets of policy enforcement). Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Fri Jan 28 03:28:10 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04318 for ; Fri, 28 Jan 2000 03:28:09 -0500 (EST) 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 DAA33012; Fri, 28 Jan 2000 03:22:03 -0500 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 DAA24282; Fri, 28 Jan 2000 03:22:03 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35056; Fri, 28 Jan 2000 03:01:37 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39606; Fri, 28 Jan 2000 03:01:32 -0500 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 DAA26272 for ; Fri, 28 Jan 2000 03:01:36 -0500 Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA45732 for ; Fri, 28 Jan 2000 03:01:32 -0500 Received: from vulture.cisco.com (vulture.cisco.com [171.69.198.245]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id AAA12764; Fri, 28 Jan 2000 00:19:14 -0800 (PST) Received: (mfine@localhost) by vulture.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id AAA29779; Fri, 28 Jan 2000 00:00:17 -0800 (PST) Date: Fri, 28 Jan 2000 00:00:17 -0800 (PST) Message-Id: <200001280800.AAA29779@vulture.cisco.com> From: Michael Fine Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shai Herzog Cc: Jon Saperia , "Weiss, Walter" , policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> <38902A72.264F071@mediaone.net> <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Michael Fine Content-Transfer-Encoding: 7bit Shai Herzog writes: > > As for the definition of Roles, I hate to say it, but I think that > neither 1 or 2 are true definitions because they are tied down to > specific implementation (PIB/Rule binding, etc.). > I think that a Role is a more general concept and the definition > should reflect it. Perhaps a definition should look something like: > > "A Role represent an attribute of a network node or an interface > that reflect physical or logical functionality. Those attribute may be > used by policy systems to determine the appropriate policy that > should be constructed for that node or interface." > I agree completely. I do not understand either of the original definitions. But this definition captures precisely my understanding of a role. To be repetitive, a role simply represents some attribute or characteristic of some (logical or physical) network entities. It stands on its own independent of any policy system, PIB or MIB. The PIB happens to make use of roles to bind policy to network entities without specifying those entities explicitly. > And role combination: > > "A set of one or more Roles that are grouped together as a basic > atomic unit for which policy instructions are needed". Here I differ. A role combination, in my mind, is simply the set of roles of a network entity. Again it stands on its own, independent of policy, PIBs, MIBs. In the PIB we happen to associate role combos with units of policy and made the rule that a unit of policy is applied to a network entity if and only if the role combo of the policy and that of the entity are identical. But we could have made some other rule; for instance the rule could be that the role combo of the policy be a subset of the role combo of the entity. Bob Natale writes: > > I like them, except that I would change "A Role represents an > attribute of a network node or an interface..." to "A Role is > a representation of a policy target..." or "...of a policy > object..." or some other similar generic abstract term. I would > try to avoid pining the language to specific device types or > categories (esp. since software entities might also be the > targets of policy enforcement). > I agree that node and interface is too restrictive. But I don't agree with the alternative "A role is a representation of a policy target". Can't we just replace node and interface with the nebulous "entity". Michael From majordomo@raleigh.ibm.com Fri Jan 28 03:56:34 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04492 for ; Fri, 28 Jan 2000 03:56:31 -0500 (EST) 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 DAA40336; Fri, 28 Jan 2000 03:46:32 -0500 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 DAA15910; Fri, 28 Jan 2000 03:46:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55934; Fri, 28 Jan 2000 03:29:30 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45634; Fri, 28 Jan 2000 03:28:58 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA31946 for ; Fri, 28 Jan 2000 03:29:03 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id CAA28929; Fri, 28 Jan 2000 02:28:50 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256874.002E961D ; Fri, 28 Jan 2000 02:28:50 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: "Jon Sjoberg" Cc: policy@raleigh.ibm.com Message-Id: <86256874.002E9518.00@tivmta4.tivoli.com> Date: Fri, 28 Jan 2000 03:00:51 -0500 Subject: Re: Policy Framework Core Information Model -- Version 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com Jon, >..... >What policy keywords or roles are appropriate for these policies? Where >does the definition of HTTP, paying_cutomers, FTP, etc. fit into the >repository or do they (I think I remember one incarnation of this draft or >the LDAP schema that sort of addressed this)? Can some one enlighten me! The term "roles" as we were using them in PCIM, had to do with identifying the policies by what resources they applied to....please see my other post on the question of roles. The identification of the traffic streams is done via the conditions part of the policy rules. If you have modeled objects that characterize these conditions, you can link to them using the ConditionSubject and ConditionTarget associations. I expect there will be more on this topic in subsequent QOS submissions to this list. >Usage of the CIM notation seems to add to the complexity of the problem >domain and to the complexity of this draft.... >Given that our intended protocol is LDAP, is there enough >value to the CIM notation to use it instead of some other more robust OO >representation (UML, Shlear-Mellor, etc.)? >... The CIM notation is, indeed, UML, with some added conventions. If we did not use CIM, we would have to invent a bunch of conventions to use for applying UML to this problem space. Why not use a bunch of conventions that have already been formulated and exercised? CIM is repository-independent, and that's what we wanted. That leaves us free to use an LDAP-accessible repository now, and something else later. Anyway, I don't think it's worth re-doing the draft to make it non-CIM UML. We would have to anticipate the problems that CIM has already addressed. Sure, with the advantage of hindsight, we might be able to invent a better set of conventions, but I don't think that is what we want to spend our time on in this working group. (There is also value, I think, in being able to easily link to other CIM-based models that can take advantage of our policy model.) Ed From majordomo@raleigh.ibm.com Fri Jan 28 03:58:26 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04518 for ; Fri, 28 Jan 2000 03:58:19 -0500 (EST) 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 DAA22420; Fri, 28 Jan 2000 03:46:33 -0500 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 DAA33824; Fri, 28 Jan 2000 03:46:30 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA56902; Fri, 28 Jan 2000 03:29:21 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37656; Fri, 28 Jan 2000 03:28:55 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA07858 for ; Fri, 28 Jan 2000 03:28:58 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id CAA28932; Fri, 28 Jan 2000 02:28:50 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256874.002E95EA ; Fri, 28 Jan 2000 02:28:50 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: "Weiss, Walter" Cc: Shai Herzog , policy@raleigh.ibm.com Message-Id: <86256874.002E9431.00@tivmta4.tivoli.com> Date: Fri, 28 Jan 2000 02:30:09 -0500 Subject: Re: Policy issues: definition of Roles Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com Walter, (Sorry about taking several days to reply. We had a small problem here with a once-in-a-hundred-years snow accumulation, which caused some communications problems.) In your note of Jan. 25, you wrote, in part: >....There are apparently two definitions for Role: >.... In response: The first definition, if I understand it's intent, is the one I think we had in mind for the PCIM document. It seems to me that you are arguing in favor of keeping that definition, and I agree with that. I also think that the words we have in the PCIM document already capture the essence of that definition: A role represents a capability that operates at the point where a policy is applied. Examples of roles include Frame Relay interface, BGP-capable router, web server, and firewall. The policy we store in the policy repository has always, from the very start of the policy framework working group, been intended to be device-independent. Therefore, the policy we put into the policy repository cannot be constrained by a role concept that is device-specific, as it is in definition #2. Definition #2 defines device-specific configuration. Of course, the config needs to carry out the policy, so the two have to be mapped, which is where the PDP function comes in. I agree with Shai's comment on this, in his note dated Jan. 27. You are right to point out the misunderstanding between the two groups of authors. Do you have a suggestion regarding a way to differentiate the two concepts? Perhaps, PCIM could use the term "functional role", and the PIB authors could use a term like "configuration role"? Ideas? Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 From majordomo@raleigh.ibm.com Fri Jan 28 03:58:58 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04540 for ; Fri, 28 Jan 2000 03:58:58 -0500 (EST) 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 DAA40568; Fri, 28 Jan 2000 03:46:30 -0500 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 DAA30274; Fri, 28 Jan 2000 03:46:30 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39380; Fri, 28 Jan 2000 03:29:15 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49408; Fri, 28 Jan 2000 03:28:51 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA09386 for ; Fri, 28 Jan 2000 03:28:55 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id CAA28926; Fri, 28 Jan 2000 02:28:50 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256874.002E9846 ; Fri, 28 Jan 2000 02:28:56 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: Jon Saperia Cc: "Weiss, Walter" , policy@raleigh.ibm.com Message-Id: <86256874.002E95A1.00@tivmta4.tivoli.com> Date: Fri, 28 Jan 2000 03:23:50 -0500 Subject: Re: Policy issues: definition of Roles Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com Jon, >.....I think there should be a class of policies >which can span what you would call single client types. I had mentioned >this a while ago. It seems logical to me that in some cases policies >are modified by others.... We have tried to be consistent in the application of an important principle: Policies are relatively static, compared to changes in state in the network. That is, we expect policies to change on a human time scale, and that they will typically changed by human beings, rather than procedural execution of code or scripts. This has fewer limitations than you might, at first, think, and it saves alot of headaches in conflict resolution. To quote from your later reply to Walter: >I might want my quality of service policy to be modified by an outage >policy which says that if the case of a failure, which of the 32 policies for >quality of service (where policy in this case translates to a customer) >do i want to 'protect' and which am I willing to sacrifice. In this >sense, under some conditions a policy is modified by another policy. I think you can deal with this in a structured way using the current model, and using the structure has significant benefits. To deal with the case where a network failure affects a qos policy, one approach is to apply policy priority in the model. That is, if you match on a failure mode condition in the network, you can kick in backup policies by making them a higher priority than the normal policy rules for qos. If you don't already have these higher priority rules pre-defined, then I would say you need to involve a human to define them in any case, in order for the network administrator to know what to expect when the failure mode is present, and the backup policies are activated. Policies modifying policies sounds like a recipe for an indeterminant result, to me, at least until we get more experience with mass configuration of network devices controlled by policies. Please see my posting on procedural vs. declarative. We may want to tackle this rich problem space in the future, but I think this is a case where caution and simplicity are the better part of valor ("walk before run" concept). Ed From majordomo@raleigh.ibm.com Fri Jan 28 04:03:51 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04616 for ; Fri, 28 Jan 2000 04:03:49 -0500 (EST) 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 DAA46222; Fri, 28 Jan 2000 03:46:32 -0500 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 DAA23330; Fri, 28 Jan 2000 03:46:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39632; Fri, 28 Jan 2000 03:29:13 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38136; Fri, 28 Jan 2000 03:28:51 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA20192 for ; Fri, 28 Jan 2000 03:28:54 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id CAA28938; Fri, 28 Jan 2000 02:28:51 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256874.002E9571 ; Fri, 28 Jan 2000 02:28:49 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: "Weiss, Walter" Cc: policy@raleigh.ibm.com Message-Id: <86256874.002E93AD.00@tivmta4.tivoli.com> Date: Fri, 28 Jan 2000 01:13:15 -0500 Subject: Re: Policy issues: definition of Roles Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com Walter, (Sorry about taking several days to reply. We had a small problem here with a once-in-a-hundred-years snow accumulation, which caused some communications problems.) In your note of Jan. 25, you wrote, in part: >....There are apparently two definitions for Role: >.... In response: The first definition, if I understand it's intent, is the one I think we had in mind for the PCIM document. It seems to me that you are arguing in favor of keeping that definition, and I agree with that. I also think that the words we have in the PCIM document already capture the essence of that definition: A role represents a capability that operates at the point where a policy is applied. Examples of roles include Frame Relay interface, BGP-capable router, web server, and firewall. The policy we store in the policy repository has always, from the very start of the policy framework working group, been intended to be device-independent. Therefore, the policy we put into the policy repository cannot be constrained by a role concept that is device-specific, as it is in definition #2. Definition #2 defines device-specific configuration. Of course, the config needs to carry out the policy, so the two have to be mapped, which is where the PDP function comes in. I agree with Shai's comment on this, in his note dated Jan. 27. You are right to point out the misunderstanding between the two groups of authors. Do you have a suggestion regarding a way to differentiate the two concepts? Perhaps, PCIM could use the term "functional role", and the PIB authors could use a term like "configuration role"? Ideas? Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 From majordomo@raleigh.ibm.com Fri Jan 28 04:30:33 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04726 for ; Fri, 28 Jan 2000 04:30:33 -0500 (EST) 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 EAA23574; Fri, 28 Jan 2000 04:27:14 -0500 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 EAA27796; Fri, 28 Jan 2000 04:27:15 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47518; Fri, 28 Jan 2000 03:46:40 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47454; Fri, 28 Jan 2000 03:46:35 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA34658 for ; Fri, 28 Jan 2000 03:46:38 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id CAA28935; Fri, 28 Jan 2000 02:28:50 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256874.002E95B4 ; Fri, 28 Jan 2000 02:28:49 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: "Weiss, Walter" Cc: "Ken Roberts" , policy@raleigh.ibm.com Message-Id: <86256874.002E9431.00@tivmta4.tivoli.com> Date: Fri, 28 Jan 2000 02:28:01 -0500 Subject: RE: WG Last Call: PCIM (Issue 2) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com Walter, You wrote, in part: >The main justification of declarative over procedural was that atomic >actions are easier to implement. In addition, simple actions can be grouped >to identify and arbitrate conflicts. In contrast, a procedural policy could >nest policies (or conditions) within other policies and describe more >complicated interactions at the expense of making conflict detection more >difficult if not impossible. Agreed. There was also the "let's walk before we run" justification. I don't think we need to put all of this in the text of the PCIM, though. Maybe the easiest way to deal with this issue, is to just delete the justification and just state that what we have defined is a declarative model, and state what that means. Otherwise, I am afraid we will end up arguing about the justification, and I think we are way beyond that now. >In the PCIM text as described under declarative, I would suggest the term >"Behavioral Simulation Policy."..... >In the PCIM text as described under procedural, I would suggest the term >"System Interaction Policy." . . . . . I would prefer to just leave the above paragraphs out entirely, since they evidently do not contribute to their objective, which was to justify the use of the declarative approach. Regarding your suggested defintions: >Declarative: A set of actions triggered by a well known (possibly canned) >condition. >Procedural: Any execution stream. How about this: (I have taken the liberty of paraphrasing the following from a book titled "UML and C++, A Practical Guide to Object-Oriented Development", by Richard C. Lee and William M. Tepfenhart, Prentice Hall, 1997.) Declarative approach: Characterized by a data-driven expression of invariants, constraints, and rules (situation-action heuristics). Distinguished from procedural in that the sequence of steps for doing the processing of declarative statements tends to be left to the implementor (although we have provided for the option of expressing the desired order of action execution in this policy info model, and for expressing whether the order is mandatory or not). Procedural approach: Characterized by a set of instructions which are always executed in a specified sequence (as in a program or script). To quote Ken Roberts, in his note of Jan. 27: >...The solution in the past has been to NOT mandate one over the other ... [declarative vs. procedural] >...vendors may build machines using whatever technology they >think is viable I agree with Ken, that we should not dictate implementation technology, but I don't think we are doing that, when we say that the model is declarative. We are simply saying that the implementor is free to order the actions in any way that makes sense for the given conditions being tested. Taking a procedural approach would require that we specify the condition testing sequence, and the action sequence, in the policy repository, which would, indeed, constrain the implementor. So, I would argue that we have, indeed, satisfied the spirit of what Ken is requesting, by saying our policy model is a declarative one. In the end, this all gets implemented in code. What we are talking about, when we say "declarative", instead of "procedural", I think, is the style of how we express the rule semantics in the policy repository. How you implement what executes the rules is up to you. Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-254-4115 From majordomo@raleigh.ibm.com Fri Jan 28 07:51:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07435 for ; Fri, 28 Jan 2000 07:51:24 -0500 (EST) 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 HAA31080; Fri, 28 Jan 2000 07:47:49 -0500 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 HAA28378; Fri, 28 Jan 2000 07:47:48 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48920; Fri, 28 Jan 2000 07:30:17 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52226; Fri, 28 Jan 2000 07:30:14 -0500 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 HAA05804 for ; Fri, 28 Jan 2000 07:30:19 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA34734 for ; Fri, 28 Jan 2000 07:30:16 -0500 Received: from mediaone.net (1Cust211.tnt1.knoxville.tn.da.uu.net [63.10.97.211]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA08295; Fri, 28 Jan 2000 07:30:13 -0500 (EST) Message-Id: <38918BE6.E271F038@mediaone.net> Date: Fri, 28 Jan 2000 07:30:30 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: ellesson@raleigh.ibm.com Cc: "Weiss, Walter" , policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <86256874.002E95A1.00@tivmta4.tivoli.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Ed_Ellesson@tivoli.com wrote: > I think you can deal with this in a structured way using the current model, > and using the structure has significant benefits. To deal with the case where > a network failure affects a qos policy, one approach is to apply policy priority > in the model. That is, if you match on a failure mode condition in the network, > you can kick in backup policies by making them a higher priority than the normal > policy rules for qos. If you don't already have these higher priority rules > pre-defined, then I would say you need to involve a human to define them in any > case, in order for the network administrator to know what to expect when the > failure mode is present, and the backup policies are activated. > > Policies modifying policies sounds like a recipe for an indeterminant result, > to me, at least until we get more experience with mass configuration of network > devices controlled by policies. Please see my posting on procedural vs. > declarative. > We may want to tackle this rich problem space in the future, but I think this is > a case where caution and simplicity are the better part of valor ("walk before > run" > concept). > Ed, I will use this to consolidate all responses to a couple of messages. First with regard to the definition of Role. There seems to be consensus that a role is an attribute. People know what an attribute is, say interface speed, or ability to do WFQ, etc. Given this adding another term, role, does not add anything in my view. If we mean attribute say that. A role is a combination of attributes (what some people already call role combination). I really do not worry too much about this, it just seems like an extra level of indirection. With regard to nested policies. I was not suggesting policies dynamically changing others. In a sense they are pre-defined. Can you tell me how we would accomplish what you suggest in the first paragraph above. That is how the failure condition would be expressed and related to the other policies? Thanks /jon From majordomo@raleigh.ibm.com Fri Jan 28 08:04:40 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07935 for ; Fri, 28 Jan 2000 08:04:39 -0500 (EST) 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 IAA26072; Fri, 28 Jan 2000 08:01:17 -0500 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 IAA16038; Fri, 28 Jan 2000 08:01:18 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54830; Fri, 28 Jan 2000 07:44:13 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42022; Fri, 28 Jan 2000 07:44:10 -0500 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 HAA33160 for ; Fri, 28 Jan 2000 07:44:16 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA40774 for ; Fri, 28 Jan 2000 07:44:12 -0500 Received: from bnatale (ppp10.acec.com [38.249.211.63]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id HAA16069; Fri, 28 Jan 2000 07:42:47 -0500 (EST) Message-Id: <4.2.2.20000128073608.00ab7888@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 07:46:40 -0500 To: Michael Fine From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <200001280800.AAA29779@vulture.cisco.com> References: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> <38902A72.264F071@mediaone.net> <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/28/2000:03:00 AM, Michael Fine wrote: Hi Michael, ><...> > > And role combination: > > > > "A set of one or more Roles that are grouped together as a basic > > atomic unit for which policy instructions are needed". > >Here I differ. A role combination, in my mind, is simply the set of >roles of a network entity. Again it stands on its own, independent of >policy, PIBs, MIBs. Hmmm. I can see where a given role combination *could* be *the* set of roles applicable to one or more entities..but more commonly would be some *subset* of the range of roles applicable to one or more entities...? >In the PIB we happen to associate role combos with units of policy and >made the rule that a unit of policy is applied to a network entity >if and only if the role combo of the policy and that of the entity are >identical. But we could have made some other rule; for instance the >rule could be that the role combo of the policy be a subset of the >role combo of the entity. Yes....I think your last sentence in that paragraph addresses my concern here. >Bob Natale writes: > > > > I like them, except that I would change "A Role represents an > > attribute of a network node or an interface..." to "A Role is > > a representation of a policy target..." or "...of a policy > > object..." or some other similar generic abstract term. I would > > try to avoid pining the language to specific device types or > > categories (esp. since software entities might also be the > > targets of policy enforcement). > >I agree that node and interface is too restrictive. But I don't agree >with the alternative "A role is a representation of a policy target". >Can't we just replace node and interface with the nebulous "entity". Yes, that would be an improvement (IMHO) that would suffice for me. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Fri Jan 28 08:12:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08229 for ; Fri, 28 Jan 2000 08:12:23 -0500 (EST) 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 IAA28056; Fri, 28 Jan 2000 08:06:17 -0500 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 IAA09546; Fri, 28 Jan 2000 08:06:16 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47142; Fri, 28 Jan 2000 07:52:54 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57118; Fri, 28 Jan 2000 07:52:52 -0500 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 HAA05822 for ; Fri, 28 Jan 2000 07:52:58 -0500 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA24640 for ; Fri, 28 Jan 2000 07:52:56 -0500 Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 28 Jan 2000 06:52:45 -0600 Received: by zsc4c002.corpwest.baynetworks.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 04:52:38 -0800 Message-Id: From: "Ken Birtwistle" To: "'diffserv@ietf.org'" , "'iptel@lists.research.bell-labs.com'" , "'mpls@UU.NET'" , "'pint@lists.research.bell-labs.com'" , "'policy@raleigh.ibm.com'" , "'rap@iphighway.com'" , "'rsvp@ISI.EDU'" Date: Fri, 28 Jan 2000 04:52:31 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF698E.8E625628" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Birtwistle" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF698E.8E625628 Content-Type: text/plain; charset="ISO-8859-1" unsubscribe kbirtwis@nortelnetworks.com ------_=_NextPart_001_01BF698E.8E625628 Content-Type: text/html; charset="ISO-8859-1"

unsubscribe kbirtwis@nortelnetworks.com

------_=_NextPart_001_01BF698E.8E625628-- From majordomo@raleigh.ibm.com Fri Jan 28 08:47:27 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09936 for ; Fri, 28 Jan 2000 08:47:25 -0500 (EST) 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 IAA12384; Fri, 28 Jan 2000 08:40:20 -0500 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 IAA30334; Fri, 28 Jan 2000 08:40:15 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37498; Fri, 28 Jan 2000 08:24:59 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46940; Fri, 28 Jan 2000 08:24:55 -0500 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 IAA23206 for ; Fri, 28 Jan 2000 08:25:01 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA42410 for ; Fri, 28 Jan 2000 08:24:57 -0500 Received: from bnatale (ppp10.acec.com [38.249.211.63]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id IAA16171; Fri, 28 Jan 2000 08:23:04 -0500 (EST) Message-Id: <4.2.2.20000128081328.00b1d188@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 08:26:57 -0500 To: Jon Saperia From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <38918BE6.E271F038@mediaone.net> References: <86256874.002E95A1.00@tivmta4.tivoli.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/28/2000:07:30 AM, Jon Saperia wrote: Hi Jon, >Ed, I will use this to consolidate all responses to a couple of >messages. First with regard to the definition of Role. There seems to be >consensus that a role is an attribute. People know what an attribute is, >say interface speed, or ability to do WFQ, etc. Given this adding >another term, role, does not add anything in my view. If we mean >attribute say that. A role is a combination of attributes (what some >people already call role combination). I really do not worry too much >about this, it just seems like an extra level of indirection. Hmmm. Yes, it is a level of indirection...bet one designed to serve a purpose...a "Role" is an abstranction that serves to map one or more physical or logical attributes of (rarely) one or (typically) more network entities into a generic policy behavior. At least that's how I see it as one who is reading (in catch-up mode!) and considering this stuff from the perspective of one who would like to put these concepts to work in the future w/o trying necessarily to be one who plays a big role in defining it all...so, I hope it's clear that I am just trying to contribute to consensus idenfication and not trying to change any course that's already been agreed to...thanks. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Fri Jan 28 09:14:18 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11312 for ; Fri, 28 Jan 2000 09:14:14 -0500 (EST) 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 JAA27414; Fri, 28 Jan 2000 09:05:42 -0500 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 JAA22778; Fri, 28 Jan 2000 09:02:54 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29858; Fri, 28 Jan 2000 08:47:13 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32124; Fri, 28 Jan 2000 08:47:07 -0500 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 IAA04100 for ; Fri, 28 Jan 2000 08:47:13 -0500 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA40868 for ; Fri, 28 Jan 2000 08:47:08 -0500 Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id FAA11329; Fri, 28 Jan 2000 05:45:45 -0800 (PST) Message-Id: <4.1.20000127143233.00b4be00@diablo.cisco.com> Message-Id: <4.1.20000127143233.00b4be00@diablo.cisco.com> Message-Id: <4.1.20000127143233.00b4be00@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 28 Jan 2000 08:42:25 -0500 To: ellesson@raleigh.ibm.com, policy@raleigh.ibm.com From: John Schnizlein Subject: Re: WG Last Call: draft-ietf-policy-core-info-model-03.txt Cc: johns@cisco.com In-Reply-To: <8625686C.0062EFE6.00@tivmta4.tivoli.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 03:58 PM 01/20/2000 -0500, Ed_Ellesson@tivoli.com wrote: > >Unless there are strong objections, we would like to consider >this draft of the document to be the final one, before moving it >forward for proposed standard status. One problem is that this draft references an expired draft: draft-strassner-policy-terms-02.txt according to an IETF.org query. Page 4: One way to think of a policy-controlled network is to first model the network as a state machine and then use policy to control which state a policy-controlled device should be in or is allowed to be in at any given time. Given this approach, policy is applied using a set of policy rules. The state-machine model was repudiated when questions were asked as to how the information model relates to the state transition table. What is the relationship between the "policy rules" and the states and transitions of a state machine? Pages 6 & 7: Policies represent business goals and objectives. A translation must be made between these goals and objectives and their realization in the network. An example of this could be a Service Level Agreement (SLA), and its objectives and metrics (Service Level Objectives, or SLOs), that are used to specify services that the network will provide for a given client [8]. The SLA will usually be written in high-level business terminology. SLOs address more specific metrics in support of the SLA. These high-level descriptions of network services and metrics must be translated into lower-level, but also vendor- and device- independent specifications. The Policy Core Information Model classes are intended to serve as the foundation for these vendor- and device- independent specifications. This terminology does not reflect the distinction between SLA and SLS negotiated in the diffserv WG draft-ietf-diffserv-new-terms-01.txt. More significantly, it is still not clear how policy specifications are translated into device configuration specifications or how the nature of the network devices or their interconnection interacts with policy in this translation. While the distinction between procedural and declarative forms are explored, compelling justification is not given for the "if (condition) then " form of rules. Might we be better served by extending the style of rule already used in Steven Bellovin's Distributed Firewalls paper? http://www.research.att.com/%7Esmb/papers/distfw.html Rules like this might ease coordination with the Security Policy WG. Instead of either procudural or declarative program statements, a form more analogous to "invariant" statements would reflect the situation that the policy is intended to maintain. The tradition of invariant statements in program verification suggests that this form might help with the difficult task of verifying that a set of rules specifies what is intended. Page 13: Why is over a page devoted to the distinction between "rule specific" and "reusable" policy conditions and actions despite the assertion that "There is no inherent difference between a rule-specific condition or action and a reusable one. " Page 15: Roles The concept of role is central to the design of the entire Policy Framework. But, as was pointed out in the Policy Terms BOF in Washington, roles are associated with principals rather than with resources in much of the security policy discussion. The isolation (indirect reference) of "roles" as arbitrary strings associated with resources (interfaces in many discussions) is presented as a virtue. But it seems that hiding the particular abilities of policy enforcement points makes it harder to determine if policy is in effect. Does this "role" really facilitate building a policy system? An architectural diagram diagram is included in this draft proposed for standards track despite the controversy that has delayed progress on a framework document. Would passing "last call" on this document imply approval of the archicture we have not agreed on in the framework? As a related question, what happened to the apparent consensus of the room that we should agree on terms, policy use cases, and requirements before progressing a model that supposedly addresses them? Pages 20 - 59: CIM Data Types No justification is provided for the host of decisions made in CIM, and reflected in the detailed specification of its classes and attributes. In particular, why is a different representation of time periods used than in (standards track) RFC 2445? This begs the question if (which of) the attribute syntaxes correspond to syntax already specified as standard in the IETF. This line of questions leads to the more general concern that a lot of detailed specification is proposed for IETF standards track on little more than the indication that the CIM group of the DMTF developed it. It is still not clear if this facilitates or hinders mutual support policy configuration efforts across areas of IETF interest. John From majordomo@raleigh.ibm.com Fri Jan 28 10:20:20 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14798 for ; Fri, 28 Jan 2000 10:20:19 -0500 (EST) 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 KAA42518; Fri, 28 Jan 2000 10:16:05 -0500 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 JAA29032; Fri, 28 Jan 2000 09:42:25 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA57336; Fri, 28 Jan 2000 09:26:32 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45284; Fri, 28 Jan 2000 09:26:28 -0500 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 JAA36326 for ; Fri, 28 Jan 2000 09:26:26 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA32500 for ; Fri, 28 Jan 2000 09:25:59 -0500 Received: from SHAI (ppp-34.ts-24-bay.nyc.idt.net [169.132.220.178]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMSRYKR1; Fri, 28 Jan 2000 09:23:24 -0500 Message-Id: <4.2.0.58.20000128092005.016fbea8@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 28 Jan 2000 09:25:33 -0500 To: Michael Fine From: Shai Herzog Subject: Re: Policy issues: definition of Roles Cc: Jon Saperia , "Weiss, Walter" , policy@raleigh.ibm.com In-Reply-To: <200001280800.AAA29779@vulture.cisco.com> References: <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> <38902A72.264F071@mediaone.net> <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Shai Herzog Given the feedback, here's a second version: "A Role represent an attribute of a logical or physical network entity that reflects some functionality. Those attribute may be used by policy systems to determine the appropriate policy that should be constructed for that network entity" And role combination: "A set comprising of all the Roles associated a single network entity". Shai At 12:00 AM 01/28/2000, Michael Fine wrote: >Shai Herzog writes: > > > > As for the definition of Roles, I hate to say it, but I think that > > neither 1 or 2 are true definitions because they are tied down to > > specific implementation (PIB/Rule binding, etc.). > > I think that a Role is a more general concept and the definition > > should reflect it. Perhaps a definition should look something like: > > > > "A Role represent an attribute of a network node or an interface > > that reflect physical or logical functionality. Those attribute may be > > used by policy systems to determine the appropriate policy that > > should be constructed for that node or interface." > > > >I agree completely. I do not understand either of the original >definitions. But this definition captures precisely my understanding >of a role. > >To be repetitive, a role simply represents some attribute or >characteristic of some (logical or physical) network entities. It >stands on its own independent of any policy system, PIB or MIB. The >PIB happens to make use of roles to bind policy to network entities >without specifying those entities explicitly. > > > > And role combination: > > > > "A set of one or more Roles that are grouped together as a basic > > atomic unit for which policy instructions are needed". > >Here I differ. A role combination, in my mind, is simply the set of >roles of a network entity. Again it stands on its own, independent of >policy, PIBs, MIBs. > >In the PIB we happen to associate role combos with units of policy and >made the rule that a unit of policy is applied to a network entity >if and only if the role combo of the policy and that of the entity are >identical. But we could have made some other rule; for instance the >rule could be that the role combo of the policy be a subset of the >role combo of the entity. > > >Bob Natale writes: > > > > I like them, except that I would change "A Role represents an > > attribute of a network node or an interface..." to "A Role is > > a representation of a policy target..." or "...of a policy > > object..." or some other similar generic abstract term. I would > > try to avoid pining the language to specific device types or > > categories (esp. since software entities might also be the > > targets of policy enforcement). > > > >I agree that node and interface is too restrictive. But I don't agree >with the alternative "A role is a representation of a policy target". >Can't we just replace node and interface with the nebulous "entity". > >Michael __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Main: (508) 620-1141 Framingham, MA 01701 Fax : (212) 656-1006 From majordomo@raleigh.ibm.com Fri Jan 28 10:45:08 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15989 for ; Fri, 28 Jan 2000 10:45:04 -0500 (EST) 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 KAA38092; Fri, 28 Jan 2000 10:41:06 -0500 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 KAA34936; Fri, 28 Jan 2000 10:40:52 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54876; Fri, 28 Jan 2000 10:29:36 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40276; Fri, 28 Jan 2000 10:29:33 -0500 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 KAA36332 for ; Fri, 28 Jan 2000 10:29:39 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA42678 for ; Fri, 28 Jan 2000 10:29:36 -0500 Received: from jsjobergnt (dyn146.TopLayer.com [199.103.238.146]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id KAA01966; Fri, 28 Jan 2000 10:27:15 -0500 From: "Jon Sjoberg" To: "Shai Herzog" , "Michael Fine" Cc: "Jon Saperia" , "Weiss, Walter" , Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 10:24:55 -0500 Message-Id: <001701bf69a3$d43bd560$92ee67c7@blazenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <4.2.0.58.20000128092005.016fbea8@209.3.6.76> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit This, in my opinion, is the best yet. > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Shai Herzog > Sent: Friday, January 28, 2000 9:26 AM > To: Michael Fine > Cc: Jon Saperia; Weiss, Walter; policy@raleigh.ibm.com > Subject: Re: Policy issues: definition of Roles > > > Given the feedback, here's a second version: > > "A Role represent an attribute of a logical or physical network entity > that reflects some functionality. Those attribute may be used by > policy systems to determine the appropriate policy that > should be constructed for that network entity" > > And role combination: > > "A set comprising of all the Roles associated a single network entity". > > Shai > > > At 12:00 AM 01/28/2000, Michael Fine wrote: > > >Shai Herzog writes: > > > > > > As for the definition of Roles, I hate to say it, but I think that > > > neither 1 or 2 are true definitions because they are tied down to > > > specific implementation (PIB/Rule binding, etc.). > > > I think that a Role is a more general concept and the definition > > > should reflect it. Perhaps a definition should look something like: > > > > > > "A Role represent an attribute of a network node or an interface > > > that reflect physical or logical functionality. Those > attribute may be > > > used by policy systems to determine the appropriate policy that > > > should be constructed for that node or interface." > > > > > > >I agree completely. I do not understand either of the original > >definitions. But this definition captures precisely my understanding > >of a role. > > > >To be repetitive, a role simply represents some attribute or > >characteristic of some (logical or physical) network entities. It > >stands on its own independent of any policy system, PIB or MIB. The > >PIB happens to make use of roles to bind policy to network entities > >without specifying those entities explicitly. > > > > > > > And role combination: > > > > > > "A set of one or more Roles that are grouped together as a basic > > > atomic unit for which policy instructions are needed". > > > >Here I differ. A role combination, in my mind, is simply the set of > >roles of a network entity. Again it stands on its own, independent of > >policy, PIBs, MIBs. > > > >In the PIB we happen to associate role combos with units of policy and > >made the rule that a unit of policy is applied to a network entity > >if and only if the role combo of the policy and that of the entity are > >identical. But we could have made some other rule; for instance the > >rule could be that the role combo of the policy be a subset of the > >role combo of the entity. > > > > > >Bob Natale writes: > > > > > > I like them, except that I would change "A Role represents an > > > attribute of a network node or an interface..." to "A Role is > > > a representation of a policy target..." or "...of a policy > > > object..." or some other similar generic abstract term. I would > > > try to avoid pining the language to specific device types or > > > categories (esp. since software entities might also be the > > > targets of policy enforcement). > > > > > > >I agree that node and interface is too restrictive. But I don't agree > >with the alternative "A role is a representation of a policy target". > >Can't we just replace node and interface with the nebulous "entity". > > > >Michael > > > __________________________________________________________________ > Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 > 55 New York Avenue Main: (508) 620-1141 > Framingham, MA 01701 Fax : (212) 656-1006 > > > > > > From majordomo@raleigh.ibm.com Fri Jan 28 10:47:14 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16073 for ; Fri, 28 Jan 2000 10:47:11 -0500 (EST) 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 KAA37770; Fri, 28 Jan 2000 10:42:34 -0500 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 KAA35304; Fri, 28 Jan 2000 10:40:54 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52342; Fri, 28 Jan 2000 10:20:04 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32110; Fri, 28 Jan 2000 10:20:01 -0500 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 KAA25688 for ; Fri, 28 Jan 2000 10:20:01 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA37806 for ; Fri, 28 Jan 2000 10:19:55 -0500 Received: from jsjobergnt (dyn146.TopLayer.com [199.103.238.146]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id KAA01775; Fri, 28 Jan 2000 10:18:19 -0500 From: "Jon Sjoberg" To: "Shai Herzog" , "Jon Saperia" , "Weiss, Walter" Cc: Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 10:15:59 -0500 Message-Id: <001601bf69a2$94eb72e0$92ee67c7@blazenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit I like Shai's definition, with one minor tweak: > "A Role represent an attribute of a network node or an interface > that reflect physical or logical functionality. Those attribute may be > used by policy systems to determine the appropriate policy that > should be constructed for that node or interface." > Or : "A Role represents an attribute of a network element that reflects physical or logical functionality...should be constructed for that network element." An element could be as low level as an interface or as high level as a firewall. In fact, it seems that a high level role could be defined by an aggregation of role combinations. From majordomo@raleigh.ibm.com Fri Jan 28 11:34:18 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17988 for ; Fri, 28 Jan 2000 11:34:12 -0500 (EST) 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 LAA17846; Fri, 28 Jan 2000 11:30:14 -0500 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 LAA33186; Fri, 28 Jan 2000 11:28:50 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42008; Fri, 28 Jan 2000 11:12:08 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25104; Fri, 28 Jan 2000 11:12:05 -0500 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 LAA29508 for ; Fri, 28 Jan 2000 11:12:12 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA32838 for ; Fri, 28 Jan 2000 11:12:10 -0500 Received: from bnatale (ppp10.acec.com [38.249.211.63]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id LAA17318; Fri, 28 Jan 2000 11:10:09 -0500 (EST) Message-Id: <4.2.2.20000128110001.00b1cef0@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 11:13:55 -0500 To: Shai Herzog From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.0.58.20000128092005.016fbea8@209.3.6.76> References: <200001280800.AAA29779@vulture.cisco.com> <75ADD7496F0BD211ADC000104B8846CF0191154A@rerun.lucentctc.com> <38902A72.264F071@mediaone.net> <4.2.0.58.20000127165149.02d4f5a0@209.3.6.76> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/28/2000:09:25 AM, Shai Herzog wrote: Hi Shai, >Given the feedback, here's a second version: > >"A Role represent an attribute of a logical or physical network entity >that reflects some functionality. Those attribute may be used by >policy systems to determine the appropriate policy that >should be constructed for that network entity" That's good. >And role combination: > >"A set comprising of all the Roles associated a single network entity". I cannot understand the inclusion of "all" here...can you explain the rationale to me? I also cannot understand the significance of the "single" qualifier in that defintion either...? Am I wrong in thinking that a major purpose of "Role" is to abstract entity-specific functionality into some more generic policy-addressable functionality which might apply uniformly to a set of entities that might implement the functionality in (possibly) different, entity-specific ways...? Alternatively, what's wrong with the following definition for "Role Combination": "A set consisting of two or more other Roles."...? Then, of course, those who might be suggesting that no definition for "Role Comibnation" is required would be right, since the definition of "Role" might just as well include the possibility that a given Role might contain one or more other Roles...? I will appreciate any explanation of your rationale behind these two qualifiers ("all" and "single") that you care to provide. Thanks. [I hope that at least some of the others on this list are finding some value in this thread...I feel that I am understanding a bit more with each message or two...but I can see where this line of discussion could be seen as tedious to some.] Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Fri Jan 28 13:31:57 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22811 for ; Fri, 28 Jan 2000 13:31:52 -0500 (EST) 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 NAA45800; Fri, 28 Jan 2000 13:26:23 -0500 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 NAA34932; Fri, 28 Jan 2000 13:23:13 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41474; Fri, 28 Jan 2000 12:59:48 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41720; Fri, 28 Jan 2000 12:59:44 -0500 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 MAA27456 for ; Fri, 28 Jan 2000 12:59:44 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA07170 for ; Fri, 28 Jan 2000 12:59:39 -0500 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 12:57:24 -0500 Message-Id: <6399122981E1D211AB490090271E0AA33C9C56@BMAILNJ> From: Francis Reichmeyer -NJ To: "'Jon Sjoberg'" , Shai Herzog - NJ , Jon Saperia , "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 12:57:21 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Francis Reichmeyer -NJ Hi Jon, > > I like Shai's definition, with one minor tweak: > > > "A Role represent an attribute of a network node or an interface > > that reflect physical or logical functionality. Those > attribute may be > > used by policy systems to determine the appropriate policy that > > should be constructed for that node or interface." > > > Or : > "A Role represents an attribute of a network element that > reflects physical > or logical functionality...should be constructed for that > network element." > An element could be as low level as an interface or as high level as a > firewall. In fact, it seems that a high level role could be > defined by an > aggregation of role combinations. With regards to your tweak: By "high level role" do you mean a role that represents what you are calling a high level element or are you implying there are different types of roles: low level and high level, plus role combinations? Thanks, -Fran From majordomo@raleigh.ibm.com Fri Jan 28 13:52:10 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23475 for ; Fri, 28 Jan 2000 13:52:03 -0500 (EST) 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 NAA26698; Fri, 28 Jan 2000 13:46:01 -0500 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 NAA30104; Fri, 28 Jan 2000 13:45:54 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45572; Fri, 28 Jan 2000 13:25:52 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43000; Fri, 28 Jan 2000 13:25:48 -0500 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 NAA30280 for ; Fri, 28 Jan 2000 13:25:49 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA10950 for ; Fri, 28 Jan 2000 13:25:40 -0500 Received: from jsjobergnt (dyn146.TopLayer.com [199.103.238.146]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id NAA06368; Fri, 28 Jan 2000 13:19:25 -0500 From: "Jon Sjoberg" To: "Francis Reichmeyer -NJ" , "Shai Herzog - NJ" , "Jon Saperia" , "Weiss, Walter" Cc: Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 13:17:05 -0500 Message-Id: <001a01bf69bb$e169ee80$92ee67c7@blazenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <6399122981E1D211AB490090271E0AA33C9C56@BMAILNJ> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit Sorry, mixed my terms. By "high level role" I meant a complex role. It occurs to me that we talk about general roles such as "security" and "QoS", but these could actually be composites of more specific roles. So "security" could be a composite of roles such as "Intrusion Detection", "Authentication", "Authorization", "Traffic Filter", etc. The role of "QoS" could likewise contain composites, including "Traffic Filter". Just a thought. > -----Original Message----- > From: Francis Reichmeyer -NJ [mailto:FranR@iphighway.com] > Sent: Friday, January 28, 2000 12:57 PM > To: 'Jon Sjoberg'; Shai Herzog - NJ; Jon Saperia; Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Hi Jon, > > > > > I like Shai's definition, with one minor tweak: > > > > > "A Role represent an attribute of a network node or an interface > > > that reflect physical or logical functionality. Those > > attribute may be > > > used by policy systems to determine the appropriate policy that > > > should be constructed for that node or interface." > > > > > Or : > > "A Role represents an attribute of a network element that > > reflects physical > > or logical functionality...should be constructed for that > > network element." > > An element could be as low level as an interface or as high level as a > > firewall. In fact, it seems that a high level role could be > > defined by an > > aggregation of role combinations. > > With regards to your tweak: > By "high level role" do you mean a role that represents what you are > calling a high level element or are you implying there are different > types of roles: low level and high level, plus role combinations? > > Thanks, > -Fran > From majordomo@raleigh.ibm.com Fri Jan 28 22:29:22 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02550 for ; Fri, 28 Jan 2000 22:29:20 -0500 (EST) 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 WAA26144; Fri, 28 Jan 2000 22:24:38 -0500 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 WAA32344; Fri, 28 Jan 2000 22:24:38 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55008; Fri, 28 Jan 2000 18:49:45 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51416; Fri, 28 Jan 2000 18:49:42 -0500 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 SAA29862 for ; Fri, 28 Jan 2000 18:49:44 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28004 for ; Fri, 28 Jan 2000 18:49:40 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 16:32:46 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0142A6E5@rerun.lucentctc.com> From: "Weiss, Walter" To: ellesson@raleigh.ibm.com Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 16:32:44 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Ed, > Policies are relatively static, compared to changes in state > in the network. > That is, we expect policies to change on a human time scale, > and that they > will typically changed by human beings, rather than > procedural execution of > code or scripts. This has fewer limitations than you might, > at first, think, > and it saves alot of headaches in conflict resolution. I think you are mixing up concepts again. You are confusing simplicity and the static nature of policies with possible approaches for defining policies. CLI is a prime example of a script that is both simple and static. The only thing it is not is box independent. regards, -Walter From majordomo@raleigh.ibm.com Fri Jan 28 22:35:18 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03522 for ; Fri, 28 Jan 2000 22:35:16 -0500 (EST) 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 WAA26280; Fri, 28 Jan 2000 22:24:43 -0500 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 WAA28784; Fri, 28 Jan 2000 22:24:42 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45662; Fri, 28 Jan 2000 18:51:05 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48978; Fri, 28 Jan 2000 18:51:01 -0500 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 SAA25602 for ; Fri, 28 Jan 2000 18:49:42 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA30554 for ; Fri, 28 Jan 2000 18:49:39 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 16:32:43 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0142A6E2@rerun.lucentctc.com> From: "Weiss, Walter" To: Shai Herzog Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 16:32:42 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Shai, > As for the definition of Roles, I hate to say it, but I think that > neither 1 or 2 are true definitions because they are tied down to > specific implementation (PIB/Rule binding, etc.). > I think that a Role is a more general concept and the definition > should reflect it. Perhaps a definition should look something like: > > "A Role represent an attribute of a network node or an interface > that reflect physical or logical functionality. Those attribute may be > used by policy systems to determine the appropriate policy that > should be constructed for that node or interface." > > And role combination: > > "A set of one or more Roles that are grouped together as a basic > atomic unit for which policy instructions are needed". > > What do you think? > I see little distinction between roles and attributes in your definition. If this is the definition we would agree to, I would suggest that we remove the concept of roles altogether. The main reason why concept was introduced was to address logical attributes in policies to actual attributes in a set of devices. The question is at what level of detail is this binding specified. If it is at the attribute level, then the binding would need to be in the policy itself (as opposed to being associated with the policy). If a policy describes an interaction between two queues or two interfaces or two services located on the same device, you need some type of explicit qualification to distinguish the two in the policy. The concept of being able to distinguish components within a device is distinct from the concept of which devices or components the policy is applicable to. regards, -Walter From majordomo@raleigh.ibm.com Fri Jan 28 22:35:48 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03533 for ; Fri, 28 Jan 2000 22:35:47 -0500 (EST) 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 WAA19598; Fri, 28 Jan 2000 22:24:41 -0500 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 WAA26662; Fri, 28 Jan 2000 22:24:36 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45926; Fri, 28 Jan 2000 18:51:07 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48988; Fri, 28 Jan 2000 18:51:04 -0500 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 SAA29874 for ; Fri, 28 Jan 2000 18:49:45 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28012 for ; Fri, 28 Jan 2000 18:49:41 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 16:32:46 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0142A6E3@rerun.lucentctc.com> From: "Weiss, Walter" To: Francis Reichmeyer -NJ , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 16:32:43 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Fran, > > > > In many of the discussions I have been in (and presentations > > I have seen), I > > have seen roles used for two distinct objectives. In one case > > a role is used > > as a means for determining the policy targets (i.e., the set > > of components > > or services that the policy will either be influenced by or > > influence). In > > the more explicit interpretation of role, there has been a > > desire to provide > > a binding between the attributes expressed in the policy and > > the actual > > attributes in the component or service interacting with > > (influenced or being > > influenced by) policies. Now, in PIBs and MIBs the binding > between the > > attribute values in the message and the actual attributes in > > the device is > > implicit because the attributes are grouped together is such > > a way that all > > the attributes are easily bound. Let's consider a > > hypothetical case where we > > constructed a MIB or PIB that contained the two dropping > > thresholds for two > > different queues without specifying the queue. In this case, > > there would be > > no way to determine which threshold was for which queue. > > However, we don't > > do this in MIBs or PIBs. In practice, we create separate > row for each > > specific queue with a set of attributes for that queue. This > > way, we specify > > the queue number is specified once in the message and we > know that all > > remaining attributes are for the queue. The identification of > > the queue we > > are interested in is just like definition 2 of a role in that > > it binds a set > > of values to a specific instance of a queue. > > > > In policy, as I have pointed out earlier, it is quite common > > for policy to > > be too broadly defined so that a binding to specific > attributes at the > > policy level is insufficient for the proper interpretation of > > the policy. A > > simple example: > > > > Set Queue2's drop threshold to Queue1's drop threshold. > > > > If you said that the role for the policy was Queue1 and > > Queue2, you > > still don't know which instance of a threshold to assign to > > which other > > threshold. You need a more explicit binding in the policy itself > > (Queue1.DropThreshold = Queue2.DropThreshold). The concept of > > a role is > > still valuable because you can provide a larger context for > > the policy such > > as "for this set of interfaces on this set of switches." > > Right, agreed. The role for a policy like the one in your example > should not be "Queue1 and Queue2". However, the role could be > "all interfaces that support Queue1 and Queue2", which I think is > basically what you are saying. > Exactly. Thanks. -Walter From majordomo@raleigh.ibm.com Fri Jan 28 22:36:05 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03544 for ; Fri, 28 Jan 2000 22:36:04 -0500 (EST) 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 WAA23964; Fri, 28 Jan 2000 22:24:42 -0500 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 WAA28722; Fri, 28 Jan 2000 22:24:38 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45202; Fri, 28 Jan 2000 15:39:42 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38538; Fri, 28 Jan 2000 15:39:39 -0500 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 PAA27960 for ; Fri, 28 Jan 2000 15:39:39 -0500 Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA37502 for ; Fri, 28 Jan 2000 15:39:32 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Fri, 28 Jan 2000 15:39:10 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 15:39:10 -0500 Message-Id: <63E0DAD7784FD21188310000F80824B30267416F@zmpkdx02.us.nortel.com> From: "Ken Roberts" To: Francis Reichmeyer -NJ , "'Jon Sjoberg'" , Shai Herzog - NJ , Jon Saperia , "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 15:39:05 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF69CF.BA3A59DA" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Roberts" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF69CF.BA3A59DA Content-Type: text/plain; charset="iso-8859-1" Group, Roles should be straight forward. IMO they define cardinality in a relationship, when management is involved we need an invoker and a performer of any given operation this specification is done using Roles, that is an entity either is a invoker or performer for a given instance of an operation (or notification). Obviously this isn't something that can be statically defined and over time may move within an intelligent network, more probably it is something that will/ should be negotiated between two entities on a as needed basis. I realize the above introduces concepts and terms we haven't debated and for this I apologize but I don't think anything is served if we begin redefining terms that have a well known meaning in relationship modeling. That will only further confuse folks. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. -----Original Message----- From: Francis Reichmeyer -NJ [mailto:FranR@iphighway.com] Sent: Friday, January 28, 2000 9:57 AM To: 'Jon Sjoberg'; Shai Herzog - NJ; Jon Saperia; Weiss, Walter Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Hi Jon, > > I like Shai's definition, with one minor tweak: > > > "A Role represent an attribute of a network node or an interface > > that reflect physical or logical functionality. Those > attribute may be > > used by policy systems to determine the appropriate policy that > > should be constructed for that node or interface." > > > Or : > "A Role represents an attribute of a network element that > reflects physical > or logical functionality...should be constructed for that > network element." > An element could be as low level as an interface or as high level as a > firewall. In fact, it seems that a high level role could be > defined by an > aggregation of role combinations. With regards to your tweak: By "high level role" do you mean a role that represents what you are calling a high level element or are you implying there are different types of roles: low level and high level, plus role combinations? Thanks, -Fran ------_=_NextPart_001_01BF69CF.BA3A59DA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Policy issues: definition of Roles

Group,
Roles should be straight forward. IMO they define = cardinality in a relationship, when management is involved we need an = invoker and a performer of any given operation this specification is = done using Roles, that is an entity either is a invoker or performer = for a given instance of an operation (or notification).

Obviously this isn't something that can be statically = defined and over time may move within an intelligent network, more = probably it is something that will/ should be negotiated between two = entities on a as needed basis.

I realize the above introduces concepts and terms we = haven't debated and for this I apologize but I don't think anything is = served if we begin redefining terms that have a well known meaning in = relationship modeling. That will only further confuse folks.

---------------------------------------------------------------= -----------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   = :        = 655-7844        =         =         ?Direct  : = 408-565-7844
?  Fax    = :        408-565-8226
? email :      = kjr@nortelnetworks.com
 
This message may contain information proprietary to = Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.

 -----Original Message-----
From:   Francis Reichmeyer -NJ [mailto:FranR@iphighway.com] =
Sent:   Friday, January 28, 2000 9:57 = AM
To:     'Jon Sjoberg'; Shai = Herzog - NJ; Jon Saperia; Weiss, Walter
Cc:     = policy@raleigh.ibm.com
Subject:        = RE: Policy issues: definition of Roles

Hi Jon,

>
> I like Shai's definition, with one minor = tweak:
>
> > "A Role represent an attribute of a = network node or an interface
> > that reflect physical or logical = functionality. Those
> attribute may be
> > used by policy systems to determine the = appropriate policy that
> > should be constructed for that node or = interface."
> >
> Or :
> "A Role represents an attribute of a = network element that
> reflects physical
> or logical functionality...should be = constructed for that
> network element."
> An element could be as low level as an = interface or as high level as a
> firewall.  In fact, it seems that a high = level role could be
> defined by an
> aggregation of role combinations.

With regards to your tweak:
By "high level role" do you mean a role = that represents what you are
calling a high level element or are you implying = there are different
types of roles: low level and high level, plus role = combinations?

Thanks,
-Fran

------_=_NextPart_001_01BF69CF.BA3A59DA-- From majordomo@raleigh.ibm.com Fri Jan 28 22:36:10 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03555 for ; Fri, 28 Jan 2000 22:36:09 -0500 (EST) 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 WAA27610; Fri, 28 Jan 2000 22:25:19 -0500 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 WAA31338; Fri, 28 Jan 2000 22:24:42 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35212; Fri, 28 Jan 2000 18:49:11 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54916; Fri, 28 Jan 2000 18:49:08 -0500 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 SAA30808 for ; Fri, 28 Jan 2000 18:49:09 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA09030 for ; Fri, 28 Jan 2000 18:48:57 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 17:00:25 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191155E@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Ed_Ellesson@tivoli.com'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 17:00:24 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Ed, > -----Original Message----- > From: Ed_Ellesson@tivoli.com [mailto:Ed_Ellesson@tivoli.com] > Sent: Friday, January 28, 2000 1:13 AM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: Re: Policy issues: definition of Roles > The first definition, if I understand it's intent, is the one > I think we had in > mind for the PCIM document. It seems to me that you are > arguing in favor of > keeping that definition, and I agree with that. I also think > that the words we > have in the PCIM document already capture the essence of that > definition: > > A role represents a capability that operates at the > point where a policy is applied. Examples of roles > include Frame Relay interface, BGP-capable router, > web server, and firewall. > While 1 is the definition I would prefer, some (including myself) are a bit confused with the current text. The Policy Framework is then responsible for configuring each of the resources associated with a role in such a way that it behaves according to the policies specified for that role. First, there is a reference to resources without any context. Second, I find policies that can only operate within the confines of a particular resource unnecessarily restrictive. Figure 4 illustrates how roles and two concepts closely related to roles, the policy subject and the policy target, operate within the Policy Framework. Because the distinction between them is not important to this discussion, the PDP and the PEP are combined in one box. The points illustrated here apply equally well, though, to an environment where the PDP and the PEP are implemented separately. I had trouble drawing anything useful from this text. If this text somehow refers to text in the policy framework, perhaps a reference would help. Roles are represented in the Core Policy Schema by values of the PolicyKeywords property. I found this text to be even more confusing because it supported a third concept not defined in either of the two concepts I described: an arbitrary grouping based on a keyword possibly bound to a technology like QoS or security, or an organization like engineering, or something else??? > Definition #2 defines device-specific configuration. Of > course, the config needs > to carry out the policy, so the two have to be mapped, which > is where the PDP > function comes in. I disagree. If all policies carry is attribute names and a role for the policy, it is impossible for a PDP to interpret the policy unambiguously. Please consider the numerous examples of policies I have given in this thread that would be ambiguous without attribute level qualifiers. > > You are right to point out the misunderstanding between the > two groups of > authors. Do you have a suggestion regarding a way to > differentiate the two > concepts? Perhaps, PCIM could use the term "functional > role", and the PIB > authors could use a term like "configuration role"? Ideas? > Refer to comments above on current text issues. From majordomo@raleigh.ibm.com Fri Jan 28 22:36:21 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03569 for ; Fri, 28 Jan 2000 22:36:18 -0500 (EST) 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 WAA44928; Fri, 28 Jan 2000 22:32:14 -0500 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 WAA06014; Fri, 28 Jan 2000 22:32:15 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21796; Fri, 28 Jan 2000 22:18:37 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47640; Fri, 28 Jan 2000 22:18:34 -0500 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 WAA28706; Fri, 28 Jan 2000 22:18:30 -0500 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA24398; Fri, 28 Jan 2000 22:18:25 -0500 Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id RAA14734; Fri, 28 Jan 2000 17:07:46 -0800 (PST) From: Keith McCloghrie Message-Id: <200001290107.RAA14734@foxhound.cisco.com> Subject: Re: Policy issues: definition of Roles To: saperia@mediaone.net Date: Fri, 28 Jan 2000 17:07:46 -0800 (PST) Cc: ellesson@raleigh.ibm.com, WWeiss@lucentctc.com (Weiss Walter), policy@raleigh.ibm.com In-Reply-To: <38918BE6.E271F038@mediaone.net> from "Jon Saperia" at Jan 28, 2000 07:30:30 AM X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Keith McCloghrie Content-Transfer-Encoding: 7bit > ... There seems to be > consensus that a role is an attribute. People know what an attribute is, > say interface speed, or ability to do WFQ, etc. Given this adding > another term, role, does not add anything in my view. But, it's a particular type of attribute: one that denotes a characteristic or function. There are other types of attributes which are not roles (e.g., ifInOctets). Keith. From majordomo@raleigh.ibm.com Fri Jan 28 22:36:22 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03568 for ; Fri, 28 Jan 2000 22:36:17 -0500 (EST) 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 WAA44988; Fri, 28 Jan 2000 22:32:24 -0500 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 WAA21536; Fri, 28 Jan 2000 22:32:19 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35766; Fri, 28 Jan 2000 21:25:33 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48988; Fri, 28 Jan 2000 18:51:04 -0500 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 SAA29874 for ; Fri, 28 Jan 2000 18:49:45 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28012 for ; Fri, 28 Jan 2000 18:49:41 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 16:32:46 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0142A6E3@rerun.lucentctc.com> From: "Weiss, Walter" To: Francis Reichmeyer -NJ , policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Fri, 28 Jan 2000 16:32:43 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Fran, > > > > In many of the discussions I have been in (and presentations > > I have seen), I > > have seen roles used for two distinct objectives. In one case > > a role is used > > as a means for determining the policy targets (i.e., the set > > of components > > or services that the policy will either be influenced by or > > influence). In > > the more explicit interpretation of role, there has been a > > desire to provide > > a binding between the attributes expressed in the policy and > > the actual > > attributes in the component or service interacting with > > (influenced or being > > influenced by) policies. Now, in PIBs and MIBs the binding > between the > > attribute values in the message and the actual attributes in > > the device is > > implicit because the attributes are grouped together is such > > a way that all > > the attributes are easily bound. Let's consider a > > hypothetical case where we > > constructed a MIB or PIB that contained the two dropping > > thresholds for two > > different queues without specifying the queue. In this case, > > there would be > > no way to determine which threshold was for which queue. > > However, we don't > > do this in MIBs or PIBs. In practice, we create separate > row for each > > specific queue with a set of attributes for that queue. This > > way, we specify > > the queue number is specified once in the message and we > know that all > > remaining attributes are for the queue. The identification of > > the queue we > > are interested in is just like definition 2 of a role in that > > it binds a set > > of values to a specific instance of a queue. > > > > In policy, as I have pointed out earlier, it is quite common > > for policy to > > be too broadly defined so that a binding to specific > attributes at the > > policy level is insufficient for the proper interpretation of > > the policy. A > > simple example: > > > > Set Queue2's drop threshold to Queue1's drop threshold. > > > > If you said that the role for the policy was Queue1 and > > Queue2, you > > still don't know which instance of a threshold to assign to > > which other > > threshold. You need a more explicit binding in the policy itself > > (Queue1.DropThreshold = Queue2.DropThreshold). The concept of > > a role is > > still valuable because you can provide a larger context for > > the policy such > > as "for this set of interfaces on this set of switches." > > Right, agreed. The role for a policy like the one in your example > should not be "Queue1 and Queue2". However, the role could be > "all interfaces that support Queue1 and Queue2", which I think is > basically what you are saying. > Exactly. Thanks. -Walter From majordomo@raleigh.ibm.com Fri Jan 28 22:36:23 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03570 for ; Fri, 28 Jan 2000 22:36:18 -0500 (EST) 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 WAA45758; Fri, 28 Jan 2000 22:32:28 -0500 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 WAA31222; Fri, 28 Jan 2000 22:32:19 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51060; Fri, 28 Jan 2000 22:19:44 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53100; Fri, 28 Jan 2000 22:19:41 -0500 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 WAA13008 for ; Fri, 28 Jan 2000 22:18:27 -0500 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA24392 for ; Fri, 28 Jan 2000 22:18:23 -0500 Received: (from kzm@localhost) by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id RAA15072; Fri, 28 Jan 2000 17:35:02 -0800 (PST) From: Keith McCloghrie Message-Id: <200001290135.RAA15072@foxhound.cisco.com> Subject: Re: Policy issues: definition of Roles To: bnatale@acecomm.com Date: Fri, 28 Jan 2000 17:35:01 -0800 (PST) Cc: herzog@iphighway.com (Shai Herzog), policy@raleigh.ibm.com In-Reply-To: <4.2.2.20000128110001.00b1cef0@plymouth.acec.com> from "Bob Natale" at Jan 28, 2000 11:13:55 AM X-Mailer: ELM [version 2.5 PL1] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Keith McCloghrie Content-Transfer-Encoding: 7bit > >And role combination: > > > >"A set comprising of all the Roles associated a single network entity". > > I cannot understand the inclusion of "all" here...can you explain the > rationale to me? For interfaces, suppose you defined these roles: "Frame-Relay", "Ethernet", "Backbone", and "Edge-router". You could then assign both the "Ethernet" role and the "Backbone" role to a particular interface. That interface would then have a role combination of "Ethernet"+"Backbone". If you defined some policies for the "Ethernet" role, and some policies for the "Backbone" role, then that interface would get the combination of the policies for "Ethernet" and the policies for "Backbone". Note that it is advantageous for the system to detect as soon as possible any conflicts that might exist by applying both the policies for "Ethernet" and those for "Backbone" to the same interface. This can be facilitated by a priori determination of which role-combinations are valid and which are invalid. For example, "Ethernet"+"Frame-Relay" might be invalid and thus, it would not be a problem if there were conflicts between the policies for "Ethernet" and those for "Frame-Relay". In order to catch all such conflicts, an interface's role combination needs to be all the roles that are associated with a particular interface. Keith. PS. When I think of "network entity", I tend to think of a network device, i.e., it seems strange to me that a router interface would be called a "network entity". To overcome this, I would suggest that "network entity" be changed to "network entity/component". From majordomo@raleigh.ibm.com Fri Jan 28 23:20:56 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03908 for ; Fri, 28 Jan 2000 23:20:53 -0500 (EST) 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 XAA39360; Fri, 28 Jan 2000 23:17:15 -0500 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 WAA35416; Fri, 28 Jan 2000 22:32:25 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28096; Fri, 28 Jan 2000 22:20:27 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27974; Fri, 28 Jan 2000 22:20:14 -0500 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 WAA04974 for ; Fri, 28 Jan 2000 22:20:11 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA43010 for ; Fri, 28 Jan 2000 22:20:07 -0500 Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D6TZS62T; Fri, 28 Jan 2000 22:18:13 -0500 Message-Id: <4.2.0.58.20000128221538.01736eb0@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 28 Jan 2000 22:20:39 -0500 To: Keith McCloghrie , bnatale@acecomm.com From: Shai Herzog Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <200001290135.RAA15072@foxhound.cisco.com> References: <4.2.2.20000128110001.00b1cef0@plymouth.acec.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_205288929==_.ALT" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Shai Herzog --=====================_205288929==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:35 PM 01/28/2000, Keith McCloghrie wrote: > > >And role combination: > > > > > >"A set comprising of all the Roles associated a single network entity". > > > > I cannot understand the inclusion of "all" here...can you explain the > > rationale to me? Keith, you were quicker than me in responding, so I guess I have little to add ;-) However,... "ALL" is required since Role Combination goes beyond a "set of roles". Given a network entity/component with X roles, it's role combination would be the concatenation of all X roles. The set of X-1 roles is NOT role combination for this entity. As for the single, it is related to the "ALL". If you require that all roles are included, you must also specify the entity the roles are coming from. However, it is fine to drop the single and state: "A set comprising of all the roles associated with a network entity/component" >Keith. > >PS. When I think of "network entity", I tend to think of a network >device, i.e., it seems strange to me that a router interface would be >called a "network entity". To overcome this, I would suggest that >"network entity" be changed to "network entity/component". Makes sense. Shai __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Main: (508) 620-1141 Framingham, MA 01701 Fax : (212) 656-1006 --=====================_205288929==_.ALT Content-Type: text/html; charset="us-ascii" At 05:35 PM 01/28/2000, Keith McCloghrie wrote:
> >And role combination:
> >
> >"A set comprising of all the Roles associated a single network entity".
>
> I cannot understand the inclusion of "all" here...can you explain the
> rationale to me?

Keith, you were quicker than me in responding, so I guess I have
little to add ;-) However,...

"ALL" is required since Role Combination goes beyond a "set of
roles". Given a network entity/component with X roles, it's role
combination would be the concatenation of all X roles. The
set of X-1 roles is NOT role combination for this entity.

As for the single, it is related to the "ALL". If you require that
all roles are included, you must also specify the entity the roles
are coming from.

However, it is fine to drop the single and state:

"A set comprising of all the roles associated with a network
entity/component"

Keith.

PS. When I think of "network entity", I tend to think of a network
device, i.e., it seems strange to me that a router interface would be
called a "network entity".  To overcome this, I would suggest that
"network entity" be changed to "network entity/component".

Makes sense.

Shai



__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006
                                             

        
                                
                             --=====================_205288929==_.ALT-- From majordomo@raleigh.ibm.com Fri Jan 28 23:27:00 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03927 for ; Fri, 28 Jan 2000 23:26:55 -0500 (EST) 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 XAA19234; Fri, 28 Jan 2000 23:23:08 -0500 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 WAA05964; Fri, 28 Jan 2000 22:33:38 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52454; Fri, 28 Jan 2000 22:20:31 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48252; Fri, 28 Jan 2000 22:20:20 -0500 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 WAA05556 for ; Fri, 28 Jan 2000 22:20:23 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id WAA42532 for ; Fri, 28 Jan 2000 22:20:19 -0500 Received: from bnatale (ppp10.acec.com [38.249.211.63]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id VAA19979; Fri, 28 Jan 2000 21:17:56 -0500 (EST) Message-Id: <4.2.2.20000128205801.00b25de0@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 21:21:42 -0500 To: Keith McCloghrie From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <200001290135.RAA15072@foxhound.cisco.com> References: <4.2.2.20000128110001.00b1cef0@plymouth.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/28/2000:08:35 PM, Keith McCloghrie wrote: Hi Keith, > > >And role combination: > > > > > >"A set comprising of all the Roles associated a single network entity". > > > > I cannot understand the inclusion of "all" here...can you explain the > > rationale to me? > >For interfaces, suppose you defined these roles: "Frame-Relay", >"Ethernet", "Backbone", and "Edge-router". You could then assign both >the "Ethernet" role and the "Backbone" role to a particular interface. >That interface would then have a role combination of "Ethernet"+"Backbone". >If you defined some policies for the "Ethernet" role, and some policies >for the "Backbone" role, then that interface would get the combination >of the policies for "Ethernet" and the policies for "Backbone". Granted. However, I can imagine, for example, a role called "Overflow" or some such applicable to interfaces that I would apply to interfaces. I migh have policies such as "activaeOverflows" and "deactivateOverflows" to either turn these on or off as traffic and/or pricing conditions might warrant. Makes sense so far...? If so, then I can imagine that I might have some policies that apply to the role comibnation of "Ethernet+Overflow" without necessarily involving the "Ethernet+Backbone" combination -- because it might well also apply to Ethernet interfaces which did not play the "Backbone" role. Now, if that also makes sense (?), how does it mesh with your explanation? >Note that it is advantageous for the system to detect as soon as >possible any conflicts that might exist by applying both the policies >for "Ethernet" and those for "Backbone" to the same interface. This >can be facilitated by a priori determination of which role-combinations >are valid and which are invalid. For example, "Ethernet"+"Frame-Relay" >might be invalid and thus, it would not be a problem if there were >conflicts between the policies for "Ethernet" and those for "Frame-Relay". > >In order to catch all such conflicts, an interface's role combination >needs to be all the roles that are associated with a particular interface. Ok...I understand your use...however, I don't consider that definition -- namely, "a role combination is the set of all roles supported by an entity" -- to be very useful...especially, in the context of trying to depict a (possibly transient, working) hierarchy of roles (for the application of one or more policies in any given instance). I'd suggest using another term, say, "Role Profile" to mean the "the set of *all* roles supported by an entity" and "Role Combination" to mean "a set of roles that may be referenced as a unit by a polciy" (or better words to that effect). Given that, then every "Role Profile" would by definition be a "Role Combination", but not every "Role Combination" would be a "Role Profile". Am I still off base? Thanks. >PS. When I think of "network entity", I tend to think of a network >device, i.e., it seems strange to me that a router interface would be >called a "network entity". To overcome this, I would suggest that >"network entity" be changed to "network entity/component". I agree that almost all the terms we try to come up with in this domain tend to be problematic these days...if just about everything is part of "the network", then using "network" as a qualifier is not very helpful. And, of course, "entity" does much better in ontological contexts (inside pun for the SNMP community! :-) than in technical areas. My original suggestion for "network entity/component" was "policy target"...meaning anything we could apply a policy to... which I expect to include way, way more than network devices and interfaces. However, I doubt we're going to see consensus form for something like "policy target", so I will be happy to agree to your suggestion in this case. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Sat Jan 29 10:42:47 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20764 for ; Sat, 29 Jan 2000 10:42:46 -0500 (EST) 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 KAA32410; Sat, 29 Jan 2000 10:12:33 -0500 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 KAA27980; Sat, 29 Jan 2000 10:12:36 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31890; Sat, 29 Jan 2000 09:43:12 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43146; Sat, 29 Jan 2000 09:43:09 -0500 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 JAA35074; Sat, 29 Jan 2000 09:43:14 -0500 Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA31438; Sat, 29 Jan 2000 09:43:11 -0500 Received: from mediaone.net (h0050e460d16d.ne.mediaone.net [24.128.60.221]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA28977; Sat, 29 Jan 2000 09:43:04 -0500 (EST) Message-Id: <3892FC5A.61C9631A@mediaone.net> Date: Sat, 29 Jan 2000 09:42:35 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en Mime-Version: 1.0 To: Keith McCloghrie Cc: ellesson@raleigh.ibm.com, Weiss Walter , policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles References: <200001290107.RAA14734@foxhound.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jon Saperia Content-Transfer-Encoding: 7bit Keith McCloghrie wrote: > > > ... There seems to be > > consensus that a role is an attribute. People know what an attribute is, > > say interface speed, or ability to do WFQ, etc. Given this adding > > another term, role, does not add anything in my view. > > But, it's a particular type of attribute: one that denotes a > characteristic or function. There are other types of attributes which > are not roles (e.g., ifInOctets). > > Keith. Keith, your short sentence is the best I have seen so far. If the blank could be filled in with a word or just a few, that would help things a lot from my perspective. A role is a type of attribute that dentoes a __________ characteristic or function. /jon From majordomo@raleigh.ibm.com Sun Jan 30 01:14:29 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29647 for ; Sun, 30 Jan 2000 01:14:28 -0500 (EST) 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 BAA22776; Sun, 30 Jan 2000 01:10:24 -0500 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 BAA13812; Sun, 30 Jan 2000 01:10:22 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51786; Sun, 30 Jan 2000 00:51:11 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32578; Sun, 30 Jan 2000 00:51:08 -0500 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 AAA23364 for ; Sun, 30 Jan 2000 00:51:11 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA40458 for ; Sun, 30 Jan 2000 00:51:09 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA01493; Sat, 29 Jan 2000 21:50:02 -0800 (PST) Message-Id: <4.2.0.58.20000129213422.00b65e70@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 29 Jan 2000 21:50:55 -0800 To: Bob Natale , Keith McCloghrie From: "John C. Strassner" Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.2.20000128205801.00b25de0@plymouth.acec.com> References: <200001290135.RAA15072@foxhound.cisco.com> <4.2.2.20000128110001.00b1cef0@plymouth.acec.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_48653339==_.ALT" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John C. Strassner" --=====================_48653339==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Comments inline. I'm resisting the urge to respond to the previous messages and instead am starting with Bob's reply to Keith's definition, which I agree with. The following is an attempt to elaborate on Keith's points. But since this is a long note, the key notion that I would like to make is that a role is more than "just" an attribute or even a set of attributes. A role is a selector that can be used to select one or more policies that are applicable to a set of entities or components from a large set of policies that are available. In another note, I would like to work this definition into the basic definition that Mike and Keith have put forth. regards, John At 09:21 PM 1/28/00 -0500, Bob Natale wrote: >At 1/28/2000:08:35 PM, Keith McCloghrie wrote: > >Hi Keith, > > > > >And role combination: > > > > > > > >"A set comprising of all the Roles associated a single network entity". > > > > > > I cannot understand the inclusion of "all" here...can you explain the > > > rationale to me? > > > >For interfaces, suppose you defined these roles: "Frame-Relay", > >"Ethernet", "Backbone", and "Edge-router". You could then assign both > >the "Ethernet" role and the "Backbone" role to a particular interface. > >That interface would then have a role combination of "Ethernet"+"Backbone". > >If you defined some policies for the "Ethernet" role, and some policies > >for the "Backbone" role, then that interface would get the combination > >of the policies for "Ethernet" and the policies for "Backbone". > >Granted. However, I can imagine, for example, a role called >"Overflow" or some such applicable to interfaces that I would apply >to interfaces. I migh have policies such as "activaeOverflows" >and "deactivateOverflows" to either turn these on or off as traffic >and/or pricing conditions might warrant. Makes sense so far...? > >If so, then I can imagine that I might have some policies that >apply to the role comibnation of "Ethernet+Overflow" without >necessarily involving the "Ethernet+Backbone" combination -- >because it might well also apply to Ethernet interfaces which >did not play the "Backbone" role. Now, if that also makes sense >(?), how does it mesh with your explanation? [js] But a role is more than an attribute. A role defines a particular function of an entity or component that can be used to identify particular behavior associated with that entity or component. So the "Ethernet+Overflow" role-combination is different than the "Ethernet+Backbone" role-combination. This difference is critical, and is most easily understood by thinking of a role as a selector. Thus, "Ethernet+Overflow" selects a different set of policies than "Ethernet+Backbone" does. So it doesn't matter if you have "activateOverflows", "deactivateOverflows", and any other "xxxOverflows" policies - you are using the role-combination to select which of these applies. So if it makes sense for both of these (and other) Overflow policies to be associated with "Ethernet+Overflow", that's fine. If they happen to also be associated with "Ethernet+Backbone", that's ok, because we are using the role-combination to select the policy, and aren't concerned with selecting the policy directly. Though, I would say that in this case, the role "Ethernet+Backbone" was named unfortunately. > >Note that it is advantageous for the system to detect as soon as > >possible any conflicts that might exist by applying both the policies > >for "Ethernet" and those for "Backbone" to the same interface. This > >can be facilitated by a priori determination of which role-combinations > >are valid and which are invalid. For example, "Ethernet"+"Frame-Relay" > >might be invalid and thus, it would not be a problem if there were > >conflicts between the policies for "Ethernet" and those for "Frame-Relay". > > > >In order to catch all such conflicts, an interface's role combination > >needs to be all the roles that are associated with a particular interface. > >Ok...I understand your use...however, I don't consider that definition >-- namely, "a role combination is the set of all roles supported by >an entity" -- to be very useful...especially, in the context of trying >to depict a (possibly transient, working) hierarchy of roles (for the >application of one or more policies in any given instance). [js] I disagree. COnsider the case of a repository having thousands of policies. Roles and role-combinations are used to select which policies are applicable to a set of entities or components. What's important here is not depicting a hierarchy of anything. Rather, the purpose is to select the small subset of policies that are applicable from a huge set of policies that are available. >I'd suggest using another term, say, "Role Profile" to mean the "the >set of *all* roles supported by an entity" and "Role Combination" to mean >"a set of roles that may be referenced as a unit by a polciy" (or better >words to that effect). Given that, then every "Role Profile" would by >definition be a "Role Combination", but not every "Role Combination" would >be a "Role Profile". > >Am I still off base? Thanks. [js] I'm not sure that Role Profile helps. Profiles generally mean needs or requirements of something. For example, a User Profile tells the system what services it needs. We're not trying to depict that at all. Roles don't represent a need, they are a selector that describes the characteristics or functions of an entity or component. > >PS. When I think of "network entity", I tend to think of a network > >device, i.e., it seems strange to me that a router interface would be > >called a "network entity". To overcome this, I would suggest that > >"network entity" be changed to "network entity/component". > >I agree that almost all the terms we try to come up with in this >domain tend to be problematic these days...if just about everything >is part of "the network", then using "network" as a qualifier is >not very helpful. And, of course, "entity" does much better in >ontological contexts (inside pun for the SNMP community! :-) than >in technical areas. My original suggestion for "network entity/component" >was "policy target"...meaning anything we could apply a policy to... >which I expect to include way, way more than network devices and >interfaces. However, I doubt we're going to see consensus form >for something like "policy target", so I will be happy to agree >to your suggestion in this case. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > --=====================_48653339==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Comments inline. I'm resisting the urge to respond to the previous messages and instead am starting with Bob's reply to Keith's definition, which I agree with. The following is an attempt to elaborate on Keith's points. But since this is a long note, the key notion that I would like to make is that a role is more than "just" an attribute or even a set of attributes. A role is a selector that can be used to select one or more policies that are applicable to a set of entities or components from a large set of policies that are available.

In another note, I would like to work this definition into the basic definition that Mike and Keith have put forth.

regards,
John

At 09:21 PM 1/28/00 -0500, Bob Natale wrote:
At 1/28/2000:08:35 PM, Keith McCloghrie wrote:

Hi Keith,

> > >And role combination:
> > >
> > >"A set comprising of all the Roles associated a single network entity".
> >
> > I cannot understand the inclusion of "all" here...can you explain the
> > rationale to me?
>
>For interfaces, suppose you defined these roles: "Frame-Relay",
>"Ethernet", "Backbone", and "Edge-router".  You could then assign both
>the "Ethernet" role and the "Backbone" role to a particular interface.
>That interface would then have a role combination of "Ethernet"+"Backbone".
>If you defined some policies for the "Ethernet" role, and some policies
>for the "Backbone" role, then that interface would get the combination
>of the policies for "Ethernet" and the policies for "Backbone".

Granted.  However, I can imagine, for example, a role called
"Overflow" or some such applicable to interfaces that I would apply
to interfaces.  I migh have policies such as "activaeOverflows"
and "deactivateOverflows" to either turn these on or off as traffic
and/or pricing conditions might warrant.  Makes sense so far...?

If so, then I can imagine that I might have some policies that
apply to the role comibnation of "Ethernet+Overflow" without
necessarily involving the "Ethernet+Backbone" combination --
because it might well also apply to Ethernet interfaces which
did not play the "Backbone" role.  Now, if that also makes sense
(?), how does it mesh with your explanation?


[js] But a role is more than an attribute. A role defines a particular function of an entity or component that can be used to identify particular behavior associated with that entity or component. So the "Ethernet+Overflow" role-combination is different than the "Ethernet+Backbone" role-combination. This difference is critical, and is most easily understood by thinking of a role as a selector. Thus, "Ethernet+Overflow" selects a different set of policies than "Ethernet+Backbone" does. So it doesn't matter if you have "activateOverflows", "deactivateOverflows", and any other "xxxOverflows" policies - you are using the role-combination to select which of these applies. So if it makes sense for both of these (and other) Overflow policies to be associated with "Ethernet+Overflow", that's fine. If they happen to also be associated with "Ethernet+Backbone", that's ok, because we are using the role-combination to select the policy, and aren't concerned with selecting the policy directly. Though, I would say that in this case, the role "Ethernet+Backbone" was named unfortunately.


>Note that it is advantageous for the system to detect as soon as
>possible any conflicts that might exist by applying both the policies
>for "Ethernet" and those for "Backbone" to the same interface.  This
>can be facilitated by a priori determination of which role-combinations
>are valid and which are invalid.  For example, "Ethernet"+"Frame-Relay"
>might be invalid and thus, it would not be a problem if there were
>conflicts between the policies for "Ethernet" and those for "Frame-Relay".
>
>In order to catch all such conflicts, an interface's role combination
>needs to be all the roles that are associated with a particular interface.

Ok...I understand your use...however, I don't consider that definition
-- namely, "a role combination is the set of all roles supported by
an entity" -- to be very useful...especially, in the context of trying
to depict a (possibly transient, working) hierarchy of roles (for the
application of one or more policies in any given instance).

[js] I disagree. COnsider the case of a repository having thousands of policies. Roles and role-combinations are used to select which policies are applicable to a set of entities or components. What's important here is not depicting a hierarchy of anything. Rather, the purpose is to select the small subset of policies that are applicable from a huge set of policies that are available.


I'd suggest using another term, say, "Role Profile" to mean the "the
set of *all* roles supported by an entity" and "Role Combination" to mean
"a set of roles that may be referenced as a unit by a polciy" (or better
words to that effect).  Given that, then every "Role Profile" would by
definition be a "Role Combination", but not every "Role Combination" would
be a "Role Profile".

Am I still off base?  Thanks.

[js] I'm not sure that Role Profile helps. Profiles generally mean needs or requirements of something. For example, a User Profile tells the system what services it needs. We're not trying to depict that at all. Roles don't represent a need, they are a selector that describes the characteristics or functions of an entity or component.


>PS. When I think of "network entity", I tend to think of a network
>device, i.e., it seems strange to me that a router interface would be
>called a "network entity".  To overcome this, I would suggest that
>"network entity" be changed to "network entity/component".

I agree that almost all the terms we try to come up with in this
domain tend to be problematic these days...if just about everything
is part of "the network", then using "network" as a qualifier is
not very helpful.  And, of course, "entity" does much better in
ontological contexts (inside pun for the SNMP community! :-) than
in technical areas.  My original suggestion for "network entity/component"
was "policy target"...meaning anything we could apply a policy to...
which I expect to include way, way more than network devices and
interfaces.  However, I doubt we're going to see consensus form
for something like "policy target", so I will be happy to agree
to your suggestion in this case.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

--=====================_48653339==_.ALT-- From majordomo@raleigh.ibm.com Sun Jan 30 01:18:59 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29979 for ; Sun, 30 Jan 2000 01:18:59 -0500 (EST) 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 BAA33728; Sun, 30 Jan 2000 01:10:21 -0500 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 BAA22248; Sun, 30 Jan 2000 01:10:20 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34648; Sun, 30 Jan 2000 00:56:07 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34638; Sun, 30 Jan 2000 00:56:03 -0500 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 AAA25362; Sun, 30 Jan 2000 00:56:06 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id AAA24622; Sun, 30 Jan 2000 00:56:02 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA01638; Sat, 29 Jan 2000 21:54:51 -0800 (PST) Message-Id: <4.2.0.58.20000129215208.00c34ab0@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 29 Jan 2000 21:55:21 -0800 To: Jon Saperia , Keith McCloghrie From: "John C. Strassner" Subject: Re: Policy issues: definition of Roles Cc: ellesson@raleigh.ibm.com, Weiss Walter , policy@raleigh.ibm.com In-Reply-To: <3892FC5A.61C9631A@mediaone.net> References: <200001290107.RAA14734@foxhound.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: "John C. Strassner" OK, how about this: A role is a type of attribute that is used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. This definition keeps the "attribute" association that people like, but emphasizes the logical function of roles as that of a selector. regards, John At 09:42 AM 1/29/00 -0500, Jon Saperia wrote: >Keith McCloghrie wrote: > > > > > ... There seems to be > > > consensus that a role is an attribute. People know what an attribute is, > > > say interface speed, or ability to do WFQ, etc. Given this adding > > > another term, role, does not add anything in my view. > > > > But, it's a particular type of attribute: one that denotes a > > characteristic or function. There are other types of attributes which > > are not roles (e.g., ifInOctets). > > > > Keith. > >Keith, your short sentence is the best I have seen so far. If the blank >could be filled in with a word or just a few, that would help things a >lot from my perspective. > >A role is a type of attribute that dentoes a __________ characteristic >or function. > > >/jon From majordomo@raleigh.ibm.com Sun Jan 30 01:48:44 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02121 for ; Sun, 30 Jan 2000 01:48:43 -0500 (EST) 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 BAA32492; Sun, 30 Jan 2000 01:45:28 -0500 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 BAA23164; Sun, 30 Jan 2000 01:45:29 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39468; Sun, 30 Jan 2000 01:29:21 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41508; Sun, 30 Jan 2000 01:29:18 -0500 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 BAA29096 for ; Sun, 30 Jan 2000 01:29:22 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id BAA40382 for ; Sun, 30 Jan 2000 01:29:20 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA02743; Sat, 29 Jan 2000 22:27:45 -0800 (PST) Message-Id: <4.2.0.58.20000129221737.00a6d100@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 29 Jan 2000 22:28:41 -0800 To: Jon Saperia , Jon Sjoberg From: "John C. Strassner" Subject: Re: Policy Framework Core Information Model -- Version 1 Cc: policy@raleigh.ibm.com In-Reply-To: <388EE9C7.3445C8AD@mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "John C. Strassner" Remember that an Information Model is repository-independent. So our intended protocol is most certainly not limited to just LDAP. Rather, we define a set of mappings (in other documents) that translate the data in the information model to a form suitable for implementation using a specific repository. It would be more correct to say that the mapping of the information in the PFCIM to a form suitable for implementing in a directory using (L)DAP is documented in the following draft: draft-ietf-policy-core-schema-06.txt. With respect to your comments about UML and CIM, CIM does try to use UML. Granted, it strays from strict UML representation in some places, and uses the notion of "weak" associations, but I'm struggling to understand why both of you think that this is not UML. Please explain with specific examples. With regards to CIM quirks (or quarks, which I guess is a really big quirk ;-) ) I agree. This comes from trying not to have dueling object wars, and trying to use CIM 2.2 (which is released and publically available). With respect to certain CIM "value-less attributes", you are probably right in many respects. But this is more of a result of CIM being specifically designed to be used for many problem domains. We have a very specific problem domain defined, and therefore are stuck with some of these more generic attributes that aren't directly applicable. We can fix this, at least in a directory mapping, by ensuring that these attributes are all marked as optional. So I personally would be happy to help rework the draft to "track tighter", as you put it, but in order to do that I need specific examples, especially concerning its not being compliant with UML. SO please supply examples, and I'll give it a shot. respectfully, John At 07:34 AM 1/26/00 -0500, Jon Saperia wrote: >Jon Sjoberg Wrote: > > > > 2.) > > Usage of the CIM notation seems to add to the complexity of the problem > > domain and to the complexity of this draft. A conservative estimate of 15 > > percent of the document is devoted to describing CIM work-arounds, CIM > > attributes that add no direct value (my opinion) to the problem domain, and > > CIM "quarks". Given that our intended protocol is LDAP, is there enough > > value to the CIM notation to use it instead of some other more robust OO > > representation (UML, Shlear-Mellor, etc.)? I'm not suggesting holding up > > last call over this (least I get shot), but perhaps we could re-work the > > draft to track tighter to the essential complexity of the problem? > > > > Jon > >One of the reasons I like your suggestion (especially about UML) are >that there are some very good tools around that generate UML and for >some of us at least, would help with design code and other reasons. > >/jon From majordomo@raleigh.ibm.com Sun Jan 30 06:19:30 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07430 for ; Sun, 30 Jan 2000 06:19:30 -0500 (EST) 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 GAA30182; Sun, 30 Jan 2000 06:15:33 -0500 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 GAA31454; Sun, 30 Jan 2000 06:15:34 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47514; Sun, 30 Jan 2000 05:59:53 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30596; Sun, 30 Jan 2000 05:59:49 -0500 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 FAA31178 for ; Sun, 30 Jan 2000 05:59:53 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA45510 for ; Sun, 30 Jan 2000 05:59:50 -0500 Received: from eh6mq5 ([10.100.1.6]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id FAA21796; Sun, 30 Jan 2000 05:59:11 -0500 From: "Jon Sjoberg" To: "Weiss, Walter" Cc: Subject: RE: Policy issues: definition of Roles Date: Sun, 30 Jan 2000 06:08:28 -0800 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 In-Reply-To: <75ADD7496F0BD211ADC000104B8846CF0191155E@rerun.lucentctc.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit Walter, > > The Policy Framework is then responsible for configuring > each of the resources associated with a role in such a way that it > behaves according to the policies specified for that role. > > > First, there is a reference to resources without any context. > Second, I find > policies that can only operate within the confines of a > particular resource > unnecessarily restrictive. > I don't understand where the second point is derived from. I guess I read the text to say that policies are confined within a specific role. It seems that policies, in the general sense, can operate across resource and role boundaries. Each policy rule that enacts a policy must be restricted, however, to a role. It would be easier, from a PDP/PEP implementation stand point, to restrict each policy rule down to a resource (and make the policy management tool do all the REAL work). > > > Roles are represented in the Core Policy Schema by values of the > PolicyKeywords property. > > > I found this text to be even more confusing because it supported a third > concept not defined in either of the two concepts I described: an > arbitrary > grouping based on a keyword possibly bound to a technology like QoS or > security, or an organization like engineering, or something else??? > Actually the possible current values are enumerated in 6.1.2, and the values fall into the "something else" category. If I read correctly, the standard possible values are: UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and "EVENT". I am not sure I fully understand many of these, though the document does explain them. Anyway, it is clearly another definition of role not akin to your two or, best I can tell, Shai's newest proposal. From majordomo@raleigh.ibm.com Sun Jan 30 10:54:39 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09491 for ; Sun, 30 Jan 2000 10:54:39 -0500 (EST) 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 KAA28646; Sun, 30 Jan 2000 10:49:22 -0500 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 KAA31594; Sun, 30 Jan 2000 10:49:23 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA11874; Sun, 30 Jan 2000 10:25:49 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44378; Sun, 30 Jan 2000 10:25:46 -0500 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 KAA31450 for ; Sun, 30 Jan 2000 10:25:46 -0500 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA27372 for ; Sun, 30 Jan 2000 10:25:43 -0500 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Sun, 30 Jan 2000 09:25:29 -0600 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D9DTD6KS; Sun, 30 Jan 2000 10:25:21 -0500 Received: from netgww (141.251.80.117 [141.251.80.117]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CY2DLBJW; Sun, 30 Jan 2000 10:25:20 -0500 From: "Glenn Waters" To: "John C. Strassner" Cc: policy Subject: RE: Policy issues: definition of Roles Date: Sun, 30 Jan 2000 10:27:19 -0500 Message-Id: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01BF6B0C.967D8010" X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <4.2.0.58.20000129213422.00b65e70@omega.cisco.com> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Glenn Waters" This is a multi-part message in MIME format. ------=_NextPart_000_0002_01BF6B0C.967D8010 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by rtpmail03.raleigh.ibm.com id KAA31450 Content-Transfer-Encoding: quoted-printable [js] But a role is more than an attribute. A role defines a particular function of an entity or component that can be used to identify particula= r behavior associated with that entity or component. So the "Ethernet+Overflow" role-combination is different than the "Ethernet+Backbone" role-combination. This difference is critical, and is most easily understood by thinking of a role as a selector. Thus, "Ethernet+Overflow" selects a different set of policies than "Ethernet+Backbone" does. So it doesn't matter if you have "activateOverflows", "deactivateOverflows", and any other "xxxOverflows" policies - you are using the role-combination to select which of these applies. So if it makes sense for both of these (and other) Overflow policies to be associated with "Ethernet+Overflow", that's fine. If they happen to also be associated with "Ethernet+Backbone", that's ok, because= we are using the role-combination to select the policy, and aren't concerned with selecting the policy directly. Though, I would say that in this case= , the role "Ethernet+Backbone" was named unfortunately. [gww] I=92m still confused. The way I read the Policy CIM is that a role = is associated with a policy. In one of your examples above you say =93=85if = it makes sense for both of these (and other) Overflow policies to be associa= ted with "Ethernet+Overflow", that's fine=85=94 which to me implies that a po= licy is associated with a role combination. I can=92t figure out which is intende= d. How I thought this all worked was that a policy is associated with a role (or multiple roles). When the policies for a particular role combination = are required then you pick each of the policies that match each of the roles = in the role combination. So for example, the role combination =93Ethernet+Overflow=94 would select the =93Ethernet=94 policies and the = =93Overflow=94 policies. /gww ------=_NextPart_000_0002_01BF6B0C.967D8010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

[js] But a role is more than an = attribute. A role defines a particular function of an entity or component that can = be used to identify particular behavior associated with that entity or = component. So the "Ethernet+Overflow" role-combination is different than the "Ethernet+Backbone" role-combination. This difference is = critical, and is most easily understood by thinking of a role as a selector. Thus, "Ethernet+Overflow" selects a different set of policies than "Ethernet+Backbone" does. So it doesn't matter if you have "activateOverflows", "deactivateOverflows", and any = other "xxxOverflows" policies - you are using the role-combination = to select which of these applies. So if it makes sense for both of these = (and other) Overflow policies to be associated with = "Ethernet+Overflow", that's fine. If they happen to also be associated with "Ethernet+Backbone", that's ok, because we are using the role-combination to select the policy, and aren't concerned with = selecting the policy directly. Though, I would say that in this case, the role "Ethernet+Backbone" was named unfortunately.

[g= ww] I’m still confused. The way I read the Policy CIM is that a role is = associated with a policy. In one of your examples above you say = “…if it makes sense for both of = these (and other) Overflow policies to be associated with = "Ethernet+Overflow", that's fine…” which to me implies that a policy is associated with a role combination. I = can’t figure out which is intended.

 

How I thought this all worked was = that a policy is associated with a role (or multiple roles). When the policies = for a particular role combination are required then you pick each of the policies that = match each of the roles in the role combination.  So for example, the role combination = “Ethernet+Overflow” would select the “Ethernet” policies and the “Overflow” = policies.

 

/gww

------=_NextPart_000_0002_01BF6B0C.967D8010-- From majordomo@raleigh.ibm.com Sun Jan 30 12:00:28 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10046 for ; Sun, 30 Jan 2000 12:00:28 -0500 (EST) 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 LAA31564; Sun, 30 Jan 2000 11:56:58 -0500 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 LAA28434; Sun, 30 Jan 2000 11:57:01 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31344; Sun, 30 Jan 2000 11:39:06 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34920; Sun, 30 Jan 2000 11:39:03 -0500 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 LAA33664 for ; Sun, 30 Jan 2000 11:39:03 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA44152 for ; Sun, 30 Jan 2000 11:39:00 -0500 Received: from bnatale (ppp12.acec.com [38.249.211.65]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id LAA24479; Sun, 30 Jan 2000 11:37:34 -0500 (EST) Message-Id: <4.2.2.20000130112936.00ab7db0@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 30 Jan 2000 11:41:42 -0500 To: "Glenn Waters" From: Bob Natale Subject: RE: Policy issues: definition of Roles Cc: policy In-Reply-To: References: <4.2.0.58.20000129213422.00b65e70@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/30/2000:10:27 AM, Glenn Waters wrote: Hi Glenn, [In the interrest of brevity (uncommon for me!), I'll just make a short response to Glenn's reaction to John's reply to my previous more lengthly note.] >[gww] I m still confused. That makes two of us. ><...> >How I thought this all worked was that a policy is associated >with a role (or multiple roles). >When the policies for a particular role combination are required >then you pick each of the policies that match each of the roles >in the role combination. >So for example, the role combination Ethernet+Overflow would >select the Ethernet policies and the Overflow policies. That's exactly how I understand each of those three points too. I am only questioning whether "role combination" has to mean the set of *all* roles supported by a "network entity/component"...the *all* is the problematic part for me...it just seems that a construct of "role combination" as *any* valid set of 1 to all roles supported by a "network entity/component" is a more useful meaning. Indeed, as I read John's rebuttal (?) to my follow-up to Keith's message, I understood him to be saying exactly that same thing. However, I also perceived that he was intending to disagree with that statement. So, like Glenn, I am still confused. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Sun Jan 30 12:27:38 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10189 for ; Sun, 30 Jan 2000 12:27:37 -0500 (EST) 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 MAA38076; Sun, 30 Jan 2000 12:24:10 -0500 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 MAA05488; Sun, 30 Jan 2000 12:24:12 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55470; Sun, 30 Jan 2000 12:01:52 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46758; Sun, 30 Jan 2000 12:01:49 -0500 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 MAA26658 for ; Sun, 30 Jan 2000 12:01:49 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA34306 for ; Sun, 30 Jan 2000 12:01:44 -0500 Received: from bnatale (ppp12.acec.com [38.249.211.65]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id MAA24531; Sun, 30 Jan 2000 12:00:23 -0500 (EST) Message-Id: <4.2.2.20000130115126.00b081c8@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 30 Jan 2000 12:04:31 -0500 To: "John C. Strassner" From: Bob Natale Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.0.58.20000129215208.00c34ab0@omega.cisco.com> References: <3892FC5A.61C9631A@mediaone.net> <200001290107.RAA14734@foxhound.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/30/2000:12:55 AM, John C. Strassner wrote: Hi John, >OK, how about this: > > A role is a type of attribute that is used to select > one or more policies for a set of entities and/or > components from among a much larger set of > available policies. Works for me. Given that, how then would you define "role combination"? For my part, I just can't see any reason to go beyond "A role combination is a set of roles." ...which, it could be argued, does not convey a lot added value. >This definition keeps the "attribute" association that >people like, but emphasizes the logical function of roles >as that of a selector. Right. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Sun Jan 30 16:20:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11646 for ; Sun, 30 Jan 2000 16:20:00 -0500 (EST) 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 QAA44110; Sun, 30 Jan 2000 16:16:08 -0500 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 QAA04132; Sun, 30 Jan 2000 16:16:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47876; Sun, 30 Jan 2000 16:04:20 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA08186; Sun, 30 Jan 2000 16:04:15 -0500 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 QAA31226 for ; Sun, 30 Jan 2000 16:04:17 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA32100 for ; Sun, 30 Jan 2000 16:04:15 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA04152; Sun, 30 Jan 2000 13:03:13 -0800 (PST) Message-Id: <4.2.0.58.20000130125958.00bc02f0@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 30 Jan 2000 13:04:08 -0800 To: Bob Natale , "John C. Strassner" From: "John C. Strassner" Subject: Re: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.2.20000130115126.00b081c8@plymouth.acec.com> References: <4.2.0.58.20000129215208.00c34ab0@omega.cisco.com> <3892FC5A.61C9631A@mediaone.net> <200001290107.RAA14734@foxhound.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: "John C. Strassner" Hi Bob,... At 12:04 PM 1/30/00 -0500, Bob Natale wrote: >At 1/30/2000:12:55 AM, John C. Strassner wrote: > >Hi John, > > >OK, how about this: > > > > A role is a type of attribute that is used to select > > one or more policies for a set of entities and/or > > components from among a much larger set of > > available policies. > >Works for me. [js] Great! >Given that, how then would you define "role combination"? [js] A role-combination is a set of attribute that are used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. The selection process is equivalent to a logical ANDing of each attribute, such that the set of policies that are selected are defined by the intersection of all roles in the role-combination. Note that you and Glenn are questioning the use of the logical AND as the selection process, and that in a previous message I've said that I'm ok in defining other types of selection processes, but want to hear from Keith, Michael and Shai (at least) first. If we did want to do that, then we probably need at least an associated attribute that defines how the selection process for the role combination is done. >For my part, I just can't see any reason to go beyond >"A role combination is a set of roles." ...which, it >could be argued, does not convey a lot added value. > > >This definition keeps the "attribute" association that > >people like, but emphasizes the logical function of roles > >as that of a selector. > >Right. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > From majordomo@raleigh.ibm.com Sun Jan 30 16:20:04 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11657 for ; Sun, 30 Jan 2000 16:20:03 -0500 (EST) 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 QAA42326; Sun, 30 Jan 2000 16:16:09 -0500 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 QAA30512; Sun, 30 Jan 2000 16:16:10 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27550; Sun, 30 Jan 2000 15:59:56 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33686; Sun, 30 Jan 2000 15:59:53 -0500 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 PAA06728 for ; Sun, 30 Jan 2000 15:59:54 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA44060 for ; Sun, 30 Jan 2000 15:59:50 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03903; Sun, 30 Jan 2000 12:58:45 -0800 (PST) Message-Id: <4.2.0.58.20000130125628.00bb9d70@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 30 Jan 2000 12:59:42 -0800 To: Bob Natale , "Glenn Waters" From: "John C. Strassner" Subject: RE: Policy issues: definition of Roles Cc: policy , kzm@cisco.com, mfine@cisco.com, herzog@iphighway.com In-Reply-To: <4.2.2.20000130112936.00ab7db0@plymouth.acec.com> References: <4.2.0.58.20000129213422.00b65e70@omega.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: "John C. Strassner" Hi Bob, the last email I sent to Glenn assumes that the "ALL" part of the definition, as initially defined by Shai and Keith, applies to the selection process as well. In other words, "Ethernet+Overflow" doesn't just select all Ethernet policies and all overflow policies, it selects the subset that apply to Ethernet and overflow. What it appears that you and Glenn are saying is that you want room to interpret how the different roles in a role-combination are used to create the selector. I'm fine with broadening this, but would really like to hear back from Keith, Michael Fine, and Shai before we set this in stone. regards, John At 11:41 AM 1/30/00 -0500, Bob Natale wrote: >At 1/30/2000:10:27 AM, Glenn Waters wrote: > >Hi Glenn, > >[In the interrest of brevity (uncommon for me!), I'll just >make a short response to Glenn's reaction to John's reply >to my previous more lengthly note.] > > >[gww] I m still confused. > >That makes two of us. > > ><...> > >How I thought this all worked was that a policy is associated > >with a role (or multiple roles). > >When the policies for a particular role combination are required > >then you pick each of the policies that match each of the roles > >in the role combination. > >So for example, the role combination Ethernet+Overflow would > >select the Ethernet policies and the Overflow policies. > >That's exactly how I understand each of those three points too. > >I am only questioning whether "role combination" has to mean the >set of *all* roles supported by a "network entity/component"...the >*all* is the problematic part for me...it just seems that a construct >of "role combination" as *any* valid set of 1 to all roles supported >by a "network entity/component" is a more useful meaning. > >Indeed, as I read John's rebuttal (?) to my follow-up to Keith's message, >I understood him to be saying exactly that same thing. However, I also >perceived that he was intending to disagree with that statement. So, >like Glenn, I am still confused. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > From majordomo@raleigh.ibm.com Sun Jan 30 16:20:19 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11670 for ; Sun, 30 Jan 2000 16:20:18 -0500 (EST) 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 QAA28490; Sun, 30 Jan 2000 16:16:03 -0500 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 QAA29012; Sun, 30 Jan 2000 16:16:05 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39004; Sun, 30 Jan 2000 15:54:36 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35920; Sun, 30 Jan 2000 15:54:33 -0500 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 PAA30664 for ; Sun, 30 Jan 2000 15:54:33 -0500 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA19494 for ; Sun, 30 Jan 2000 15:54:32 -0500 Received: from jstrassn-lt ([171.69.108.130]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03706; Sun, 30 Jan 2000 12:53:51 -0800 (PST) Message-Id: <4.2.0.58.20000130125016.00bb1100@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 30 Jan 2000 12:54:47 -0800 To: "Glenn Waters" , "John C. Strassner" From: "John C. Strassner" Subject: RE: Policy issues: definition of Roles Cc: policy In-Reply-To: References: <4.2.0.58.20000129213422.00b65e70@omega.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: "John C. Strassner" Hi Glenn, comment inline. regards, John At 10:27 AM 1/30/00 -0500, Glenn Waters wrote: >[js] But a role is more than an attribute. A role defines a particular >function of an entity or component that can be used to identify particular >behavior associated with that entity or component. So the >"Ethernet+Overflow" role-combination is different than the >"Ethernet+Backbone" role-combination. This difference is critical, and is >most easily understood by thinking of a role as a selector. Thus, >"Ethernet+Overflow" selects a different set of policies than >"Ethernet+Backbone" does. So it doesn't matter if you have >"activateOverflows", "deactivateOverflows", and any other "xxxOverflows" >policies - you are using the role-combination to select which of these >applies. So if it makes sense for both of these (and other) Overflow >policies to be associated with "Ethernet+Overflow", that's fine. If they >happen to also be associated with "Ethernet+Backbone", that's ok, because >we are using the role-combination to select the policy, and aren't >concerned with selecting the policy directly. Though, I would say that in >this case, the role "Ethernet+Backbone" was named unfortunately. > >[gww] I m still confused. The way I read the Policy CIM is that a role is >associated with a policy. In one of your examples above you say &if it >makes sense for both of these (and other) Overflow policies to be >associated with "Ethernet+Overflow", that's fine& which to me implies that >a policy is associated with a role combination. I can t figure out which >is intended. [js2] In the PFCIM, we allow for either a role or a role-combination to serve as the selector for identifying one or more policies that are applicable. So in the example below, it is equally correct for a single role as well as a role-combination to select a policy. The example below was unfortunate in that it only contained role-combinations. Does that help? >How I thought this all worked was that a policy is associated with a role >(or multiple roles). When the policies for a particular role combination >are required then you pick each of the policies that match each of the >roles in the role combination. So for example, the role combination >Ethernet+Overflow would select the Ethernet policies and the Overflow policies. [js2] This is why I prefer thinking of roles as selectors, not just attributes. The intent is to use the combination of roles in a role-combination to select which policies apply. So to continue your example, "Ethernet+Overflow" would end up selecting all policies that are applicable for Ethernet AND affect "overflow". >/gww From majordomo@raleigh.ibm.com Mon Jan 31 04:42:55 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00360 for ; Mon, 31 Jan 2000 04:42:54 -0500 (EST) 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 EAA21556; Mon, 31 Jan 2000 04:39:38 -0500 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 EAA14682; Mon, 31 Jan 2000 04:39:38 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31388; Mon, 31 Jan 2000 04:18:14 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34964; Mon, 31 Jan 2000 04:18:10 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA27218 for ; Mon, 31 Jan 2000 04:18:09 -0500 Message-Id: <200001310918.EAA27218@rtpmail02.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 1129; Mon, 31 Jan 00 10:18:12 CET Date: Mon, 31 Jan 00 10:18:12 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: Re: Policy issues: definition of Roles Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Mmmm.... this discussion seems to belong in the Policy Terminology mailing list. But clearly, now that we have a WG Last Call outstanding, now we need to nail down the definitions. So it is good to have the discussion. I see we're starting to converge, but I do not see full agreement yet. We may want to try and get agreement in this WG real quick, and then try to sense out if other people agree on the polterm mailing list. Bert From majordomo@raleigh.ibm.com Mon Jan 31 05:02:22 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00476 for ; Mon, 31 Jan 2000 05:02:22 -0500 (EST) 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 EAA29366; Mon, 31 Jan 2000 04:58:47 -0500 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 EAA29106; Mon, 31 Jan 2000 04:58:46 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28696; Mon, 31 Jan 2000 04:40:11 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36092; Mon, 31 Jan 2000 04:40:06 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA21950 for ; Mon, 31 Jan 2000 04:40:04 -0500 Message-Id: <200001310940.EAA21950@rtpmail01.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2885; Mon, 31 Jan 00 10:40:09 CET Date: Mon, 31 Jan 00 10:40:09 CET From: "Bert Wijnen" To: jschnizl@cisco.com Cc: policy@raleigh.ibm.com Subject: WG Last Call: draft-ietf-policy-core-info-model-03.txt Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Ref: Your note of Fri, 28 Jan 2000 08:42:25 -0500 Subject: Re: WG Last Call: draft-ietf-policy-core-info-model-03.txt John writes: > > An architectural diagram diagram is included in this draft proposed for > standards track despite the controversy that has delayed progress on a > framework document. Would passing "last call" on this document imply > approval of the archicture we have not agreed on in the framework? > Do you mean the diagram on page 15 (i.e. figure 4)? I think that we do not need to mandate such architecture in a "Core Information Model" document. We could change the text to say that "A Policy Framework" or "A Policy System" or "A policy Infrastructure" "can then be made responsible for configuring.... " The figure can then be stated to be an example of how such a Framework could look in practice, without mandating that it needs to be done that way. The information model I think can be specified architecture independent. Also, for the Information model, it should not be important if we distinguish between PDP/PEP or what names we give to those functional blocks. > As a related question, what happened to the apparent consensus of the > room that we should agree on terms, policy use cases, and requirements > before progressing a model that supposedly addresses them? > Those terms that we need to agree on, we need to agree on. Clearly the discussion about "Roles" is part of that. Once we decide, that can go into the polterm work. I am not sure if we indeed need to agree on use cases before we can define the PCIM. The sooner we have those defined and agreed upon, the better. But again, I would hope that the core info model can be done independent of use cases. If we turn out to create dependencies (i.e. normative references), then the core info model document will have to wait for publication untill the other docs are ready. On the other hand, I would think that the Framework or Architecture are quite dependent on use-cases and/or vice versa. W.r.t. the requirements as we are defining them in confmgt mailing list, those requirements are generic for "Configuration Management". We should measure the Policy Framework/Architecture against the document that confmgt will produce. In any event, let us at least try to get WG consensus on this document. If we cannot get consensus on the complete doc, let us then try to produce a list of "open issues" that need to be resolved before we can reach consensus. If such a list indeed matures, I would then like to see an appendix in the doc that lists the issues and dependencies. We can then try to go on to the next document (uses cases, framework, terminology, schema, whichever we choose) and see how far we get there. If we keep postponing decisions and consensus forming because of dependencies on other docs, then we never get anywhere, and then you ADs may get fed up with the WG and.... oh well. We MUST start moving closer to the end, not just farther from the beginning. Bert From majordomo@raleigh.ibm.com Mon Jan 31 07:09:35 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01244 for ; Mon, 31 Jan 2000 07:09:34 -0500 (EST) 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 HAA22562; Mon, 31 Jan 2000 07:06:12 -0500 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 HAA04286; Mon, 31 Jan 2000 07:06:12 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45780; Mon, 31 Jan 2000 06:49:26 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53708; Mon, 31 Jan 2000 06:49:23 -0500 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 GAA24106 for ; Mon, 31 Jan 2000 06:49:22 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA25656 for ; Mon, 31 Jan 2000 06:49:20 -0500 Received: from eh6mq5 ([10.100.1.6]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id GAA27503; Mon, 31 Jan 2000 06:48:35 -0500 From: "Jon Sjoberg" To: "John C. Strassner" Cc: Subject: RE: Policy Framework Core Information Model -- Version 1 Date: Mon, 31 Jan 2000 06:57:55 -0800 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) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <4.2.0.58.20000129221737.00a6d100@omega.cisco.com> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit John, > So I personally would be happy to help rework the draft to "track > tighter", > as you put it, but in order to do that I need specific examples, > especially > concerning its not being compliant with UML. SO please supply > examples, and > I'll give it a shot. Here is a list of differences between CIM and UML. If you need any help re-working this, let me know. 1.) We don't use the inheritance of associations, so it is just more words that add little value to our problem. Lets lop it out of the document. 2.) Associations with attributes is not used in UML and seems un-necessary. Standard information modeling says: For one to many associations the key attribute(s) of the association go to the one. For the one to one association the key attribute(s) can go to either. For the many to many associations then there is an associating object that can hold the key attributes plus any other attributes of the association (the only case that is somewhat like the current "associations with attributes"). This eliminates a whole nest of sections on associations and provides just secondary key attributes. Note that where the association keys go is just an analysis tool and has NO relevance on the implementation. 3.) CreationClassName: Do we need this? I understand why CIM uses it, but UML uses the concept of categories to provide name scoping. We have the category of the base PCIM. All names within in it are scoped to be unique (PCIM.PolicyGroup). There is a whole paragraph plus a bunch of attribute descriptions for CreationClassName that are not part of the essential problem. Perhaps the UML category idea would be lighter weight? Besides, in all honesty, I don't quite get the whole "weak association" thing but what I do get leads me to believe it is not intrinsic in the policy problem. The above three deviations from UML add, what I would consider, non-essential complexity to the document. If, as Ed implied, we are using CIM to play nicely with others, then there is merit in that. To minimize the impact on us, perhaps we could move some of the CIM specific text to appendices, just refer to the CIM modeling language document (if it is publicly available), or a combination of the two. If we are using CIM because it is the modeling tool best known by the authors, I would assert that it is not the best tool for the job. UML would be better, Shlear-Mellor would be best. NON-SEQUITOR: UML is not a bunch of boxes and arrows and therefore the use of boxes and arrows does not make it UML. UML is an approach to system architecture, design, and even, to extremes, implementation. CIM is NOT UML, or even very much like UML. This does not mean CIM is evil, but on several occasions I have heard the statement the CIM is UML (or so similar as for there to be no distinction) as a defense. This statement is inaccurate and should probably not be used. Jon P.S. Yes "quark" was supposed to be "quirk". The spell checker was checking what I typed, not what I meant. From majordomo@raleigh.ibm.com Mon Jan 31 07:34:40 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01523 for ; Mon, 31 Jan 2000 07:34:40 -0500 (EST) 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 HAA21042; Mon, 31 Jan 2000 07:29:59 -0500 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 HAA27586; Mon, 31 Jan 2000 07:29:59 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42812; Mon, 31 Jan 2000 07:12:58 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41012; Mon, 31 Jan 2000 07:12:55 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA29998 for ; Mon, 31 Jan 2000 07:12:56 -0500 Message-Id: <200001311212.HAA29998@rtpmail02.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 0339; Mon, 31 Jan 00 13:12:59 CET Date: Mon, 31 Jan 00 13:12:59 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - Editorial/Admin comments Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" I have send a number of editorial/administrative comments to the authors. I leave it up to them if they think they need discussion on this list. I think they are not controversial, that is why I did not want to bother you all with that. Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:16:49 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02564 for ; Mon, 31 Jan 2000 08:16:48 -0500 (EST) 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 IAA24694; Mon, 31 Jan 2000 08:10:53 -0500 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 IAA27914; Mon, 31 Jan 2000 08:10:53 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42906; Mon, 31 Jan 2000 07:51:29 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36754; Mon, 31 Jan 2000 07:51:26 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA27864 for ; Mon, 31 Jan 2000 07:51:25 -0500 Message-Id: <200001311251.HAA27864@rtpmail01.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2269; Mon, 31 Jan 00 13:51:30 CET Date: Mon, 31 Jan 00 13:51:30 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - Sect 6.1.2. - PolicyKeywords Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" I wonder how definitions of Keywords are registered. And how we prevent collisions. Whatever we think up, we should document the procedure, I think. Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:17:08 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02586 for ; Mon, 31 Jan 2000 08:17:08 -0500 (EST) 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 IAA25706; Mon, 31 Jan 2000 08:10:51 -0500 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 IAA27912; Mon, 31 Jan 2000 08:10:51 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36654; Mon, 31 Jan 2000 07:54:07 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40230; Mon, 31 Jan 2000 07:54:04 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA29466 for ; Mon, 31 Jan 2000 07:54:04 -0500 Message-Id: <200001311254.HAA29466@rtpmail02.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2358; Mon, 31 Jan 00 13:54:07 CET Date: Mon, 31 Jan 00 13:54:07 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - Class Names Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Last para of sect 6.2.1 states: Class names in CIM are limited to alphabetic and numeric characters plus the underscore. Mmmm... Are the class names also in UCS-2 ?? If so, then what does "alphabetic and numeric" mean? Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:19:22 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02622 for ; Mon, 31 Jan 2000 08:19:21 -0500 (EST) 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 IAA33816; Mon, 31 Jan 2000 08:12:07 -0500 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 IAA23190; Mon, 31 Jan 2000 08:11:37 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43076; Mon, 31 Jan 2000 07:55:49 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43066; Mon, 31 Jan 2000 07:55:46 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA24588 for ; Mon, 31 Jan 2000 07:55:46 -0500 Message-Id: <200001311255.HAA24588@rtpmail03.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2430; Mon, 31 Jan 00 13:55:49 CET Date: Mon, 31 Jan 00 13:55:49 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - Length of Class Names Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" It seems that the MaxLength for a class name is fixed at 256, or we prefer to define it at that. I see the MaxLength specification in quite a few classNames, but not for all. Is that intended? Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:20:11 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02664 for ; Mon, 31 Jan 2000 08:20:11 -0500 (EST) 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 IAA28496; Mon, 31 Jan 2000 08:10:47 -0500 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 IAA26048; Mon, 31 Jan 2000 08:10:46 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34314; Mon, 31 Jan 2000 07:48:06 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47362; Mon, 31 Jan 2000 07:48:03 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA29238 for ; Mon, 31 Jan 2000 07:48:03 -0500 Message-Id: <200001311248.HAA29238@rtpmail03.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2123; Mon, 31 Jan 00 13:48:07 CET Date: Mon, 31 Jan 00 13:48:07 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - sect 6.5.3 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" I wonder if the discussion of the DISMAN SCHEDULE MIB is usefull here. Maybe it is better to just pick up some of the text from the DESCRIPTION clause, but not to list that whole SYNTAX and the SMIv2 BITS construct. Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:33:58 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02980 for ; Mon, 31 Jan 2000 08:33:56 -0500 (EST) 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 IAA39746; Mon, 31 Jan 2000 08:28:10 -0500 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 IAA26850; Mon, 31 Jan 2000 08:28:09 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36268; Mon, 31 Jan 2000 08:05:43 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53156; Mon, 31 Jan 2000 08:05:40 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA25986 for ; Mon, 31 Jan 2000 08:05:40 -0500 Message-Id: <200001311305.IAA25986@rtpmail01.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2838; Mon, 31 Jan 00 14:05:45 CET Date: Mon, 31 Jan 00 14:05:45 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - OIDs Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Taking sect 6.6.2 as an example, it is not clear to me how an OID is encoded in a UCS-2 string. is it 2 octets per character (I think yes) and is it of the form 1.3.6.x.y.z or is it of another form. If this form, are the digoits and the dot from the US ASCII set?? Maybe this is defined in DMTF CIM doc. I still need to read that one. Bert From majordomo@raleigh.ibm.com Mon Jan 31 08:44:58 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03174 for ; Mon, 31 Jan 2000 08:44:57 -0500 (EST) 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 IAA38884; Mon, 31 Jan 2000 08:28:45 -0500 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 IAA27858; Mon, 31 Jan 2000 08:28:10 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA08718; Mon, 31 Jan 2000 08:09:02 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47606; Mon, 31 Jan 2000 08:08:59 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA14616 for ; Mon, 31 Jan 2000 08:08:59 -0500 Message-Id: <200001311308.IAA14616@rtpmail02.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 2962; Mon, 31 Jan 00 14:09:03 CET Date: Mon, 31 Jan 00 14:09:03 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - Sect 7.3 Object References Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Is it just me, or are there other who do not understand. I cannot follow the discussion on "high order part" and "model path" (since "path" is repeated several times, it probably was not a misspelled "part". Bert From majordomo@raleigh.ibm.com Mon Jan 31 09:06:59 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03847 for ; Mon, 31 Jan 2000 09:06:59 -0500 (EST) 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 JAA23750; Mon, 31 Jan 2000 09:03:41 -0500 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 IAA25760; Mon, 31 Jan 2000 08:31:39 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44666; Mon, 31 Jan 2000 08:15:51 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA22380; Mon, 31 Jan 2000 08:15:48 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA33622 for ; Mon, 31 Jan 2000 08:15:48 -0500 Message-Id: <200001311315.IAA33622@rtpmail03.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 3260; Mon, 31 Jan 00 14:15:52 CET Date: Mon, 31 Jan 00 14:15:52 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - property GroupNumber Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Mmm... here I am also confused. Is this an alternative way of grouping conditions besides the way of grouping them. If I understand it right, then sets of conditions can be grouped together in a PolicyRule by giving them the same group number. Then sets of PolicyRules (with zero, one or more groups of conditions) can be grouped together into a PolicyGrooup. Did I get that right? Regardless of if I did get it right or not, I cannot say that this is easy to grasp from the doc. Bert From majordomo@raleigh.ibm.com Mon Jan 31 09:26:27 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04278 for ; Mon, 31 Jan 2000 09:26:27 -0500 (EST) 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 JAA19846; Mon, 31 Jan 2000 09:23:14 -0500 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 JAA34268; Mon, 31 Jan 2000 09:23:14 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43178; Mon, 31 Jan 2000 09:05:12 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47510; Mon, 31 Jan 2000 09:05:07 -0500 Received: from nlvm1.emea.ibm.com (nlvm1.emea.ibm.com [9.165.3.73]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA28508 for ; Mon, 31 Jan 2000 09:05:06 -0500 Message-Id: <200001311405.JAA28508@rtpmail01.raleigh.ibm.com> Received: from UITVM1 by nlvm1.emea.ibm.com (IBM VM SMTP V2R4) with BSMTP id 5736; Mon, 31 Jan 00 15:05:11 CET Date: Mon, 31 Jan 00 15:05:11 CET From: "Bert Wijnen" To: policy@raleigh.ibm.com Subject: WG Last Call PCIM - section 7.13, 7.13.1 and 7.13.2 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Bert Wijnen" Are these 3 sections in sync? I have the impression they are not... maybe I just don't understand. And the same question for sect 7.14, 7.14.1 and 7.14.2 Bert From majordomo@raleigh.ibm.com Mon Jan 31 11:00:56 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08144 for ; Mon, 31 Jan 2000 11:00:55 -0500 (EST) 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 JAA25556; Mon, 31 Jan 2000 09:57:24 -0500 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 JAA30646; Mon, 31 Jan 2000 09:57:26 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42792; Mon, 31 Jan 2000 09:36:53 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26652; Mon, 31 Jan 2000 09:36:50 -0500 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 JAA27734 for ; Mon, 31 Jan 2000 09:36:51 -0500 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA28306 for ; Mon, 31 Jan 2000 09:36:45 -0500 Received: from ysnir8000 (telaviv3-dhcp40.cisco.com [144.254.93.168]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id QAA10457; Mon, 31 Jan 2000 16:39:26 +0200 (IST) From: "Yoram Snir" To: "'Bert Wijnen'" , Subject: RE: WG Last Call PCIM - property GroupNumber Date: Mon, 31 Jan 2000 16:33:59 +0200 Message-Id: <002301bf6bf8$37006f20$a85dfe90@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200001311315.IAA33622@rtpmail03.raleigh.ibm.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit The use of condition groupings with the PolicyRule 'policyRuleConditionListType' attribute is to create flexible Boolean expressions. For example: The following Boolean expression made of conditions A,B,C : ((A and B) OR not C) will be defined using policyRuleConditionListType=DNF Condition A's policyConditionGroupNumber = 1 Condition A's policyConditionNegated = 0 Condition B's policyConditionGroupNumber = 1 Condition B's policyConditionNegated = 0 Condition C's policyConditionGroupNumber = 2 Condition C's policyConditionNegated = 1 Yoram Snir Cisco Systems Tel. 972-9-9700085 Mobile 972-54-970085 > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bert Wijnen > Sent: Monday, January 31, 2000 4:16 PM > To: policy@raleigh.ibm.com > Subject: WG Last Call PCIM - property GroupNumber > > > Mmm... here I am also confused. > Is this an alternative way of grouping conditions besides the > way of grouping them. > If I understand it right, then sets of conditions can be grouped > together in a PolicyRule by giving them the same group number. > Then sets of PolicyRules (with zero, one or more groups of > conditions) can be grouped together into a PolicyGrooup. > > Did I get that right? > > Regardless of if I did get it right or not, I cannot say that > this is easy to grasp from the doc. > > Bert > > From majordomo@raleigh.ibm.com Mon Jan 31 13:36:08 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12170 for ; Mon, 31 Jan 2000 13:36:05 -0500 (EST) 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 NAA30060; Mon, 31 Jan 2000 13:29:46 -0500 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 NAA12754; Mon, 31 Jan 2000 13:29:44 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43834; Mon, 31 Jan 2000 12:26:29 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA40996; Mon, 31 Jan 2000 12:26:25 -0500 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 MAA25680 for ; Mon, 31 Jan 2000 12:26:26 -0500 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 MAA36880 for ; Mon, 31 Jan 2000 12:26:21 -0500 Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA23987; Mon, 31 Jan 2000 09:25:20 -0800 (PST) Message-Id: <4.1.20000131122304.00a60d70@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 31 Jan 2000 12:24:41 -0500 To: "Bert Wijnen" From: John Schnizlein Subject: Re: WG Last Call: draft-ietf-policy-core-info-model-03.txt Cc: policy@raleigh.ibm.com In-Reply-To: <200001310940.EAA65238@northrelay03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 10:40 AM 01/31/2000 +0100, Bert Wijnen wrote: >Ref: Your note of Fri, 28 Jan 2000 08:42:25 -0500 >John writes: >> >> An architectural diagram diagram is included in this draft proposed for >> standards track despite the controversy that has delayed progress on a >> framework document. Would passing "last call" on this document imply >> approval of the archicture we have not agreed on in the framework? >> >Do you mean the diagram on page 15 (i.e. figure 4)? Yes, and I agree that rephrasing this as just an example of how the information model might be implemented would work. From majordomo@raleigh.ibm.com Mon Jan 31 14:06:22 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13005 for ; Mon, 31 Jan 2000 14:06:22 -0500 (EST) 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 NAA34102; Mon, 31 Jan 2000 13:57:08 -0500 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 NAA04144; Mon, 31 Jan 2000 13:57:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46576; Mon, 31 Jan 2000 13:37:10 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46556; Mon, 31 Jan 2000 13:37:02 -0500 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 NAA25866 for ; Mon, 31 Jan 2000 13:37:03 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA32108 for ; Mon, 31 Jan 2000 13:36:59 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jan 2000 13:36:30 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191156A@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Jon Sjoberg'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 13:36:24 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Jon, Since my posting, the intent of Roles (in the form of keywords and keyword combinations) has become clearer to me. With role combinations, I can create policies that cross domains. That said, I wanted to draw attention to the text because it was too vague for me to understand what the intent was. It seems that the definition of Roles that PCIM authors had in mind is a bit more high level then what I was thinking of. I don't have any problem with grouping policies together based on some keyword. These are fairly abstract concepts that I could easily see as useful for policy conflicts. However, I have not seen the rubber hit the road yet. In the original posting, my main concern was that the policy rules, and more precisely the attributes within policy rules, eventually have to be bound to some physical attribute somewhere in order to effect changes in network devices or services. Specifying keywords is not enough. We should also document how an attribute actually maps to given instances of that attribute in an interface, queue or whatever. We could use the role keyword as a way of indicating which set of interfaces or queues we would like the policy to apply to, but then we need a mechanism to bind the keyword to that set. If that is the approach taken, then we still have attribute qualifiers to deal with, but at least I know how I can use Role Keys beyond conflict detection. As a side note, we are spending a considerable amount of time focused on device interfaces. I would like to remind folks that the purpose of this working group is to come up with a framework that can not only be applied to QoS components in forwarding engines, but also other problem domains. Security policies, Address management policies, and Routing policies have little if anything to do with interfaces. While I am comfortable with focusing on QoS (as per our charter), I would like to make sure that we don't make assumptions about how and where policy will be used. regards, -Walter > -----Original Message----- > From: Jon Sjoberg [mailto:jsjoberg@TopLayer.com] > Sent: Sunday, January 30, 2000 9:08 AM > To: Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > Walter, > > > > > The Policy Framework is then responsible for configuring > > each of the resources associated with a role in such a way that it > > behaves according to the policies specified for that role. > > > > > > First, there is a reference to resources without any context. > > Second, I find > > policies that can only operate within the confines of a > > particular resource > > unnecessarily restrictive. > > > I don't understand where the second point is derived from. I > guess I read > the text to say that policies are confined within a specific > role. It seems > that policies, in the general sense, can operate across > resource and role > boundaries. Each policy rule that enacts a policy must be restricted, > however, to a role. It would be easier, from a PDP/PEP > implementation stand > point, to restrict each policy rule down to a resource (and > make the policy > management tool do all the REAL work). > > > > > > > Roles are represented in the Core Policy Schema by values of the > > PolicyKeywords property. > > > > > > I found this text to be even more confusing because it > supported a third > > concept not defined in either of the two concepts I described: an > > arbitrary > > grouping based on a keyword possibly bound to a technology > like QoS or > > security, or an organization like engineering, or something else??? > > > Actually the possible current values are enumerated in 6.1.2, > and the values > fall into the "something else" category. If I read > correctly, the standard > possible values are: > UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", > "MOTIVATIONAL", > "INSTALLATION", and "EVENT". I am not sure I fully understand many of > these, though the document does explain them. Anyway, it is > clearly another > definition of role not akin to your two or, best I can tell, > Shai's newest > proposal. > > > From majordomo@raleigh.ibm.com Mon Jan 31 14:07:13 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13036 for ; Mon, 31 Jan 2000 14:07:12 -0500 (EST) 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 NAA32394; Mon, 31 Jan 2000 13:57:18 -0500 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 NAA25712; Mon, 31 Jan 2000 13:57:16 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52726; Mon, 31 Jan 2000 12:22:28 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35306; Mon, 31 Jan 2000 12:22:24 -0500 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 MAA04382 for ; Mon, 31 Jan 2000 12:22:26 -0500 Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA44732 for ; Mon, 31 Jan 2000 12:22:22 -0500 Received: from GARAGE (user-2ini9g7.dialup.mindspring.com [165.121.38.7]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with SMTP id MAA19645; Mon, 31 Jan 2000 12:22:21 -0500 (EST) From: "Andrea Westerinen" To: "Bert Wijnen" , Subject: RE: WG Last Call PCIM - Length of Class Names Date: Mon, 31 Jan 2000 09:36:25 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200001311255.HAA24588@rtpmail03.raleigh.ibm.com> Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit The MaxLength qualifier is usually specified for properties that are keys (such as Names) - so that an identifying code doesn't run on forever. Alternately, MaxLength is specified on a property where this length is well understood. Andrea > -----Original Message----- > From: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Bert Wijnen > Sent: Monday, January 31, 2000 5:56 AM > To: policy@raleigh.ibm.com > Subject: WG Last Call PCIM - Length of Class Names > > > It seems that the MaxLength for a class name is fixed at 256, or > we prefer to define it at that. I see the MaxLength specification > in quite a few classNames, but not for all. Is that intended? > > Bert From majordomo@raleigh.ibm.com Mon Jan 31 14:37:02 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13963 for ; Mon, 31 Jan 2000 14:37:01 -0500 (EST) 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 OAA27028; Mon, 31 Jan 2000 14:28:03 -0500 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 OAA28328; Mon, 31 Jan 2000 14:28:04 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36770; Mon, 31 Jan 2000 14:08:09 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43414; Mon, 31 Jan 2000 14:08:02 -0500 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 OAA27176 for ; Mon, 31 Jan 2000 14:08:03 -0500 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA19716 for ; Mon, 31 Jan 2000 14:08:00 -0500 Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jan 2000 14:07:31 -0500 Message-Id: <75ADD7496F0BD211ADC000104B8846CF0191156B@rerun.lucentctc.com> From: "Weiss, Walter" To: "'Ed_Ellesson@tivoli.com'" Cc: policy@raleigh.ibm.com Subject: RE: WG Last Call: PCIM (Issue 2) Date: Mon, 31 Jan 2000 14:07:30 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" Ed, > -----Original Message----- > From: Ed_Ellesson@tivoli.com [mailto:Ed_Ellesson@tivoli.com] > Sent: Friday, January 28, 2000 2:28 AM > To: Weiss, Walter > Cc: Ken Roberts; policy@raleigh.ibm.com > Subject: RE: WG Last Call: PCIM (Issue 2) > > > > > Walter, > > You wrote, in part: > > >The main justification of declarative over procedural was that atomic > >actions are easier to implement. In addition, simple actions > can be grouped > >to identify and arbitrate conflicts. In contrast, a > procedural policy could > >nest policies (or conditions) within other policies and describe more > >complicated interactions at the expense of making conflict > detection more > >difficult if not impossible. > > Agreed. There was also the "let's walk before we run" > justification. I don't > think we need to put all of this in the text of the PCIM, though. > > Maybe the easiest way to deal with this issue, is to just delete the > justification > and just state that what we have defined is a declarative > model, and state what > that means. Otherwise, I am afraid we will end up arguing about the > justification, > and I think we are way beyond that now. > That's fine. > >In the PCIM text as described under declarative, I would > suggest the term > >"Behavioral Simulation Policy."..... > > >In the PCIM text as described under procedural, I would > suggest the term > >"System Interaction Policy." . . . . . > > I would prefer to just leave the above paragraphs out > entirely, since they > evidently do not contribute to their objective, which was to > justify the use of > the declarative approach. > I disagree. One of the issues we need to address is how policies are represented. Some of us of suggested that a policy should be described from the perspective of a input into the system. For example, the forwarding engine of a router takes as input a packet and the policy is described as "if an arriving packet is an HTTP packet, mark 1 Mb as in-profile and the rest as out-of-profile." This is what I have described in the previous posting as a "Behavioral Simulation Policy" because the policy describes an abstract processing rule for the forwarding engine. You could almost describe the policy as a meta-forwarding engine. In contrast, a "system interaction policy" would use interfaces to the forwarding engine to construct policies. The same result could be achieved, however, there are no assumptions about the construction of the forwarding engine beyond what interfaces are exported by it. In the former policy model, you are standardizing the behavioral characteristics of the systems you want to define policy for. In the latter model, you use defined policy semantics to create new policies on top of the interfaces defined by services. In the former, a policy crossing say security and QoS would need to be standardized because the behavioral interaction between the two technologies would need to be agreed to. In the latter, the interfaces to security and QoS would be standardized (MIBs, PIBs, Information Models, etc.) and the policy uses the standardized interfaces to create policy rules. I certainly expect that we will not support both policy approaches in this working group, but even if we do, we need to explain each to the point that people understand the tradeoffs in the approaches. This does imply some additional terminology. If you want to defer to the framework document for a discussion of this issue, that's fine. But then we should not be implying the use or applicability of either in this document. > Regarding your suggested defintions: > > >Declarative: A set of actions triggered by a well known > (possibly canned) > >condition. > > >Procedural: Any execution stream. > > How about this: > > (I have taken the liberty of paraphrasing the following from > a book titled > "UML and C++, A Practical Guide to Object-Oriented > Development", by Richard C. > Lee and William M. Tepfenhart, Prentice Hall, 1997.) > > Declarative approach: Characterized by a data-driven > expression of invariants, > constraints, and rules (situation-action heuristics). > Distinguished from > procedural > in that the sequence of steps for doing the processing of > declarative statements > tends to be left to the implementor (although we have > provided for the option of > expressing the desired order of action execution in this > policy info model, and > for expressing whether the order is mandatory or not). > > Procedural approach: Characterized by a set of instructions > which are always > executed > in a specified sequence (as in a program or script). I am comfortable with these suggestions. I look forward to reading the next version. regards, -Walter From majordomo@raleigh.ibm.com Mon Jan 31 14:51:47 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14351 for ; Mon, 31 Jan 2000 14:51:47 -0500 (EST) 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 OAA48912; Mon, 31 Jan 2000 14:44:01 -0500 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 OAA23234; Mon, 31 Jan 2000 14:44:03 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34274; Mon, 31 Jan 2000 14:23:33 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49610; Mon, 31 Jan 2000 14:23:26 -0500 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 OAA03438 for ; Mon, 31 Jan 2000 14:23:28 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA24162 for ; Mon, 31 Jan 2000 14:23:23 -0500 Received: from bnatale (dhcpeast1.acec.com [192.152.208.44]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id OAA04265; Mon, 31 Jan 2000 14:14:49 -0500 (EST) Message-Id: <4.2.2.20000131140604.00ae9380@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jan 2000 14:19:09 -0500 To: "John C. Strassner" From: Bob Natale Subject: RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <4.2.0.58.20000130125628.00bb9d70@omega.cisco.com> References: <4.2.2.20000130112936.00ab7db0@plymouth.acec.com> <4.2.0.58.20000129213422.00b65e70@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/30/2000:03:59 PM, John C. Strassner wrote: Hi John, Thanks for your patience on this...I do feel that we're making progress. >the last email I sent to Glenn assumes that the "ALL" part of the definition, >as initially defined by Shai and Keith, applies to the selection process as well. >In other words, "Ethernet+Overflow" doesn't just select all Ethernet policies and >all overflow policies, it selects the subset that apply to Ethernet and overflow. Yes, that would be my understanding too...and further serves to bolster the original (and only) point I am trying to make on this thread, to wit: >What it appears that you and Glenn are saying is that you want room to interpret >how the different roles in a role-combination are used to create the selector. I can't speak for Glenn, of course...but the only thing I am trying to clarify -- which your explanation above supports -- is that a "role-combination" does *not* necessarily refer to the set of *all* roles supported by a "network entity/component" ...rather, it only refers to the subset defined by the combination ("Ethernet+Overflow", in the example above...not "all Ethernet and all Overflow roles in the network entity/ component"...much less "all roles in the network entity/component"). So, we seem to be saying the same thing here. >I'm fine with broadening this, but would really like to hear back from Keith, >Michael Fine, and Shai before we set this in stone. Sounds fair to me...thanks. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Mon Jan 31 15:19:31 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14822 for ; Mon, 31 Jan 2000 15:19:30 -0500 (EST) 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 PAA30242; Mon, 31 Jan 2000 15:02:56 -0500 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 PAA26832; Mon, 31 Jan 2000 15:02:57 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49596; Mon, 31 Jan 2000 14:40:48 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49580; Mon, 31 Jan 2000 14:40:43 -0500 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 OAA26838 for ; Mon, 31 Jan 2000 14:40:46 -0500 Received: from mail.toplayer.com ([199.103.238.97]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA33656 for ; Mon, 31 Jan 2000 14:40:41 -0500 Received: from jsjobergnt (dyn146.TopLayer.com [199.103.238.146]) by mail.toplayer.com (8.8.7/8.8.7) with SMTP id OAA01950; Mon, 31 Jan 2000 14:40:03 -0500 From: "Jon Sjoberg" To: Cc: Subject: RE: Policy Framework Core Information Model -- Version 1 Date: Mon, 31 Jan 2000 14:37:48 -0500 Message-Id: <000c01bf6c22$a7649d20$92ee67c7@blazenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000131192030.9528.qmail@fsmail.net> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Jon Sjoberg" Content-Transfer-Encoding: 7bit John, Actually, my issue was with the simple nature of the aggregation not the participants in the aggregation. After re-reading the draft and with all the discussion, however, I'm beginning to think my point was pointless :) Sorry for the noise. > -----Original Message----- > From: John Strassner [mailto:straz@fsmail.net] > Sent: Monday, January 31, 2000 2:20 PM > To: jsjoberg@mail.toplayer.com; policy@raleigh.ibm.com > Cc: johns@cisco.com; straz@fsmail.net > Subject: Re: Policy Framework Core Information Model -- Version 1 > > > Hi Jon, comments inline. Sorry about the weird address, it will be valid > for only a couple of days. Please reply to johns@cisco.com > > regards, > John > > At 05:45 PM 1/25/00 -0800, Jon Sjoberg wrote: > A few comments the draft: "Policy Framework Core Information Model -- > Version 1 Specification". > > 1.) > The general view that I get from the draft is that policy (as currently > being focused on by this WG, not in the most general sense) is being made > to > apply to the aggregation of a client and some network behavior. > > > Forgive me if I haven't had enough coffee yet ;-) but I fail to see how > your examples listed below are different than, as you put it, > aggregating a > client and some network behavior. For example, if I look at the first > example, I see a client (paying_customers), the traffic from that client > (HTTP traffic ending up on landsend.com) and network behavior (priority > treatment from special_servers). > > > The following statement, from the draft, sums up the "feeling" that I get: > "Service policies describe services available in the network. Usage > policies > describe the particular binding of a client of the network to services > available in the network." > > Often the draft uses examples like "so-and-so gets gold service" or "use > this scheme on this interface." I appreciate these are only examples, but > they also further my opinion that this draft focuses on a simple > aggregation. > > > But that same page defines other types of policies (e.g., > Configuration and > Installation policies) that have nothing to do with aggregating clients. > > So if I'm reading you right, you're objecting to the emphasis of examples > that focus on binding a client (human or otherwise) to a network service. > Is that correct? If so, I'd be happy to add additional examples to balance > things out. If not, please explain again. > > > What I'm looking at is policies such as: > All HTTP traffic from paying_customers for landsend.com gets priority > network treatment from special_servers. > All HTTP traffic from browsing_customers for landsend.com gets priority > network treatment from unwashed_masses_servers.All FTP retr traffic for > landsend.com gets bulk-transfer network treatment > from unwashed_masses_servers. > All FTP stor traffic for landsend.com gets denied network treatment. > > > All of these seem to fit the mold of client binding to network service. As > another example, in the last example, the FTP traffic is generated by some > person or application operated on behalf of a person (e.g., a client) and > the service is, in this case, being denied. > > > Clearly these can be represented as condition/action policy > rules. What I'm > not so clear on is all the other stuff that goes around these > policy rules. > What policy keywords or roles are appropriate for these policies? Where > does the definition of HTTP, paying_cutomers, FTP, etc. fit into the > repository or do they (I think I remember one incarnation of this draft or > the LDAP schema that sort of addressed this)? Can some one enlighten me! > Thanks. > > > The policy keywords, roles, etc. that are appropriate for these types of > policies will necessarily be different for each application. The PFCIM > deignated a small set of keywords and roles to standardize common, > high-level concepts. If you look at these (pg 22), you'll see that they > correspond to the types of policie that are described on page 6 (with > "unknown" being a general catch-all). > > So, for the above example, if you treat a role as a selector, then you > would want to define a set of policies that would select HTTP traffic and > at least one other attribute (e.g., the set of IP addresses (for example) > that map to landsend.com. Likewise, keywords are used to speed up > searches, > so you would define a set of keywords that would help you locate policy > rules, conditions, actions, etc. > > > 2.) > Usage of the CIM notation seems to add to the complexity of the problem > domain and to the complexity of this draft. A conservative estimate of 15 > percent of the document is devoted to describing CIM work-arounds, CIM > attributes that add no direct value (my opinion) to the problem > domain, and > CIM "quarks". Given that our intended protocol is LDAP, is there enough > value to the CIM notation to use it instead of some other more robust OO > representation (UML, Shlear-Mellor, etc.)? I'm not suggesting holding up > last call over this (least I get shot), but perhaps we could re-work the > draft to track tighter to the essential complexity of the problem? > > Already covered in another email I sent. > > > Jon > > _________________________________________________________ > fsmail - get your free web-based email at: www.fsmail.net > > > > From majordomo@raleigh.ibm.com Mon Jan 31 17:46:10 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17636 for ; Mon, 31 Jan 2000 17:46:09 -0500 (EST) 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 RAA12606; Mon, 31 Jan 2000 17:39:08 -0500 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 RAA21808; Mon, 31 Jan 2000 17:39:05 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34554; Mon, 31 Jan 2000 17:13:03 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45028; Mon, 31 Jan 2000 17:13:00 -0500 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 RAA33022 for ; Mon, 31 Jan 2000 17:13:03 -0500 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA33678 for ; Mon, 31 Jan 2000 17:12:58 -0500 Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA20209; Mon, 31 Jan 2000 14:12:24 -0800 (PST) Message-Id: <4.1.20000131162848.00a9e100@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 31 Jan 2000 17:10:51 -0500 To: policy@raleigh.ibm.com From: John Schnizlein Subject: time period syntax: draft-ietf-policy-core-info-model-03.txt Cc: johns@cisco.com, straz@fsmail.net In-Reply-To: <20000131192635.10075.qmail@fsmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein Agreement, as requested, prior to argument regarding time period: At , John Strassner wrote: >At 08:42 AM 1/28/00 -0500, John Schnizlein wrote: >Page 13: >Why is over a page devoted to the distinction between "rule specific" >and "reusable" policy conditions and actions despite the assertion that > "There is no inherent difference between a rule-specific condition or > action and a reusable one. " > > >... >The statement that you are referencing was intended to underscore the fact >that a condition or action that is initially defined as reusable may be >turned into a rule-specific condition or action, and vice-versa. The >difference is not one of functionality, but how the rule is stored. This is >why text was devoted to explaining this and other differences in using >rule-specific vs. reusable conditions and actions. > >So as a compromise, how about adding text to the problem statement >identified above that states this? >Would your concern be satisfied by doing this? Yes. ... >An architectural diagram diagram is included in this draft proposed for >standards track despite the controversy that has delayed progress on a >framework document. Would passing "last call" on this document imply >approval of the archicture we have not agreed on in the framework? > > >I can only assume that you are referring to Figure 4, which everyone has >agreed to already. However, we could insert words emphasizing that this is >an example only, and is not meant as a standard architecture. Would that >satisfy your concerns? > Yes. ... >Pages 20 - 59: CIM Data Types >No justification is provided for the host of decisions made in CIM, and >reflected in the detailed specification of its classes and attributes. >In particular, why is a different representation of time periods used >than in (standards track) RFC 2445? >This begs the question if (which of) the attribute syntaxes correspond >to syntax already specified as standard in the IETF. > ... > >With respect to your question about 2445, this document uses RFC 2591 as a >way to represent some of its data. We thought that that RFC was well suited >to expressing what we wanted. The bit-mask concept in the PCIM (sections 6.5.2, 6.5.3, 6.5.4, 6.5.5) seems like the bit-mask in RFC 2591, but that RFC contains nothing like the time period (section 6.5.1), which is defined in RFC 2445. Excerpts from these three documents (following) suggest that the general application-level exchange format of RFC 2445 might suit generic policy syntax better than the particular MIB item settings of RFC 2591. The bit-mask concept is valuable, but does not interfere with using the aleady existing (standards track) syntax for period of time. draft-ietf-policy-core-info-model-03.txt 6.5.1. The Property "TimePeriod" This property identifies an overall range of calendar dates and times over which a policy rule is valid. It is formatted as a string consisting of a start date and time, then a colon (':'), and followed by an end date and time. The first date indicates the beginning of the range, while the second date indicates the end. Thus, the second date and time must be later than the first. Dates are expressed as substrings of the form "yyyymmddhhmmss". For example: 19990101080000:19990131120000 January 1, 1999, 0800 through January 31, 1999, noon RFC 2445: The iCalendar format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, ... 4.3.4 Date Example: The following represents July 14, 1997: 19970714 4.3.5 Date-Time For example, the following represents January 19, 1998, at 0700 UTC: DTSTART:19980119T070000Z 4.3.9 Period of Time Example: The period starting at 18:00:00 UTC, on January 1, 1997 and ending at 07:00:00 UTC on January 2, 1997 would be: 19970101T180000Z/19970102T070000Z RFC 2591 The MIB defined in this memo provides scheduling of actions periodically or at specified dates and times. The actions can be used to realize on-duty / off-duty schedules or to trigger management functions in a distributed management application. Schedules can be enabled or disabled by modifying a control object. This allows pre-configured schedules which are activated or de- activated by some other management functions. 5. Usage Examples 5.2. Starting a script at the next Friday the 13th It is assumed that the schedule entry is owned by schedOwner = "joe" and its name is schedName = "13th". The instance identifier for the scheduling entry is therefore 3.106.111.101.4.49.51.116.104. It is further assumed that the smLaunchTable entry is owned by smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The complete object identifier for the smLaunchStart object is therefore smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives in the context identified by the string "engine1". The configuration of the scheduler entry which launches the script on every Friday 13th at midnight would look as follows: schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday } schedMonth.3.106.111.101.4.49.51.116.104 = { january, february, march, april, may, june, july, august, september, october, november, december } schedDay.3.106.111.101.4.49.51.116.104 = { d13 } schedHour.3.106.111.101.4.49.51.116.104 = { h0 } schedMinute.3.106.111.101.4.49.51.116.104 = { m0 } schedValue.3.106.111.101.4.49.51.116.104 = 0 schedContextName.3.106.111.101.4.49.51.116.104 = "engine1" schedVariable.3.106.111.101.4.49.51.116.104 = smLaunchStart.3.106.111.101.5.103.104.111.115.116 schedType.3.106.111.101.4.49.51.116.104 = oneshot(3) schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2) schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3) schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1) All the remaining columns in the schedTable represent status information and are not shown here. From majordomo@raleigh.ibm.com Mon Jan 31 18:14:43 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17982 for ; Mon, 31 Jan 2000 18:14:42 -0500 (EST) 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 SAA38456; Mon, 31 Jan 2000 18:05:18 -0500 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 SAA05632; Mon, 31 Jan 2000 18:05:20 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41300; Mon, 31 Jan 2000 17:44:10 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53544; Mon, 31 Jan 2000 17:44:05 -0500 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 RAA28254 for ; Mon, 31 Jan 2000 17:44:09 -0500 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA38810 for ; Mon, 31 Jan 2000 17:44:03 -0500 Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 14:43:11 -0800 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC4A9@SOL> From: Andrew Smith To: "'Bob Natale'" Cc: policy@raleigh.ibm.com Subject: RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 14:43:09 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Andrew Smith So is the confusion just related to the use of the symbol "+" then? If you're a hardware person that means "OR" and if you're a mathematical person it means "AND". I would suggest that we (try to) stick with a simple definition for "role combination" that uses "AND" semantics (and a new symbol - how about "&&"?). If we find out later on that we need to broaden this to include ORs, NOTs and parentheses then so be it. However, the whole goal of the role combination concept, at least as far as I understand it in the PIB work, was to make the multiplied-out set of possibilities as small as possible for the sake of simplicity in the device. So, keep it simple if possible. Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Bob Natale [mailto:bnatale@acecomm.com] > Sent: Monday, January 31, 2000 11:19 AM > To: John C. Strassner > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles > > > At 1/30/2000:03:59 PM, John C. Strassner wrote: > > Hi John, > > Thanks for your patience on this...I do feel that we're > making progress. > > >the last email I sent to Glenn assumes that the "ALL" part > of the definition, > >as initially defined by Shai and Keith, applies to the > selection process as well. > >In other words, "Ethernet+Overflow" doesn't just select all > Ethernet policies and > >all overflow policies, it selects the subset that apply to > Ethernet and overflow. > > Yes, that would be my understanding too...and further serves > to bolster > the original (and only) point I am trying to make on this > thread, to wit: > > >What it appears that you and Glenn are saying is that you > want room to interpret > >how the different roles in a role-combination are used to > create the selector. > > I can't speak for Glenn, of course...but the only thing I am > trying to clarify -- > which your explanation above supports -- is that a > "role-combination" does *not* > necessarily refer to the set of *all* roles supported by a > "network entity/component" > ...rather, it only refers to the subset defined by the > combination ("Ethernet+Overflow", > in the example above...not "all Ethernet and all Overflow > roles in the network entity/ > component"...much less "all roles in the network > entity/component"). So, we seem > to be saying the same thing here. > > >I'm fine with broadening this, but would really like to hear > back from Keith, > >Michael Fine, and Shai before we set this in stone. > > Sounds fair to me...thanks. > > Cordially, > > BobN > ------------ ISO 9001 Registered Quality Supplier ----------- > Bob Natale | ACE*COMM | 301-721-3000 [v] > Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] > bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com > ------------- Free downloads at www.winsnmp.com ------------- > From majordomo@raleigh.ibm.com Mon Jan 31 18:34:36 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18182 for ; Mon, 31 Jan 2000 18:34:35 -0500 (EST) 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 SAA27832; Mon, 31 Jan 2000 18:28:51 -0500 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 SAA27518; Mon, 31 Jan 2000 18:28:49 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44406; Mon, 31 Jan 2000 18:08:54 -0500 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44134; Mon, 31 Jan 2000 18:08:50 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA05682 for ; Mon, 31 Jan 2000 18:08:52 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id RAA19940 for ; Mon, 31 Jan 2000 17:08:52 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256877.007F2781 ; Mon, 31 Jan 2000 17:08:51 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: policy@raleigh.ibm.com Message-Id: <86256877.007F2616.00@tivmta4.tivoli.com> Date: Mon, 31 Jan 2000 18:06:13 -0500 Subject: Re: WG Last Call: draft-ietf-policy-core-info-model-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com I am forwarding this to the list for John Strassner. Ed From straz@fsmail.net Mon Jan 31 14:26:01 2000 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52148; Mon, 31 Jan 2000 14:26:01 -0500 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 OAA27570 for ; Mon, 31 Jan 2000 14:26:02 -0500 Received: from fsmail.net (216.200.119.41.reverse.not.updated.above.net [216.200.119.41] (may be forged)) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id OAA26478 for ; Mon, 31 Jan 2000 14:25:59 -0500 Received: (qmail 10076 invoked by uid 1120); 31 Jan 2000 19:26:35 -0000 Message-Id: <20000131192635.10075.qmail@fsmail.net> From: John Strassner Subject: Re: WG Last Call: draft-ietf-policy-core-info-model-03.txt To: jschnizl@cisco.com, ellesson@raleigh.ibm.com, policy@raleigh.ibm.com Cc: johns@cisco.com, straz@fsmail.net Date: Mon Jan 31 19:26:34 GMT 2000 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline. Sorry about the weird email address, please reply to johns@cisco.com. regards, John At 08:42 AM 1/28/00 -0500, John Schnizlein wrote: At 03:58 PM 01/20/2000 -0500, Ed_Ellesson@tivoli.com wrote: > >Unless there are strong objections, we would like to consider >this draft of the document to be the final one, before moving it >forward for proposed standard status. One problem is that this draft references an expired draft: draft-strassner-policy-terms-02.txt according to an IETF.org query. That's a goof, we'll remove it. Page 4: One way to think of a policy-controlled network is to first model the network as a state machine and then use policy to control which state a policy-controlled device should be in or is allowed to be in at any given time. Given this approach, policy is applied using a set of policy rules. The state-machine model was repudiated when questions were asked as to how the information model relates to the state transition table. What is the relationship between the "policy rules" and the states and transitions of a state machine? Please see my response to Ken and Walter. Since the state machine analogy caused confusion, I removed it in the proposed text. Pages 6 & 7: Policies represent business goals and objectives. A translation must be made between these goals and objectives and their realization in the network. An example of this could be a Service Level Agreement (SLA), and its objectives and metrics (Service Level Objectives, or SLOs), that are used to specify services that the network will provide for a given client [8]. The SLA will usually be written in high-level business terminology. SLOs address more specific metrics in support of the SLA. These high-level descriptions of network services and metrics must be translated into lower-level, but also vendor- and device- independent specifications. The Policy Core Information Model classes are intended to serve as the foundation for these vendor- and device- independent specifications. This terminology does not reflect the distinction between SLA and SLS negotiated in the diffserv WG draft-ietf-diffserv-new-terms-01.txt. I don't think it should. That terminology was negotiated specifically for DiffServ, and will undoubtedly be modified for IPSP and other groups that want to use the PFCIM. The PFCIM is, after all, supposed to be general and not tied directly to DiffServ. So what I think is needed here is to keep these general definitions and then show how they can be related to the more specific usage by DiffServ and other groups. Specifically, this document does not use the term SLS, it instead uses the term SLO. So the only conflict is between the definition of SLA. In DiffServ, SLA is defined as "...service contract... that specifies the forwarding service a customer should receive". The only difference is that this definition of SLA says "...usually be written in high-level business terminology." This does not conflict with the DiffServ definition. Thus, all we need to do is to reference the DiffServ definition and tie it into the above. More significantly, it is still not clear how policy specifications are translated into device configuration specifications or how the nature of the network devices or their interconnection interacts with policy in this translation. This is a valid concern, but one that is not applicable to the PFCIM. This is because the purpose of the PFCIM is to define a general framework of classes that can be used to generically express the structure of a policy rule. The translation into specific device configurations is not the goal of the PFCIM, nor can it be expressed in the PFCIM, since this is by definition specific to a particular type of domain (e.g., DiffServ vs. DHCP). This is instead the goal of other drafts (e.g., the QoS drafts). Therefore, this concern should be addressed when (for example) the QoS drafts go to Last Call. In fact, it should be addressed any time the PFCIM is used in conjunction with other drafts to express policy for a particular domain. While the distinction between procedural and declarative forms are explored, compelling justification is not given for the "if (condition) then " form of rules. Might we be better served by extending the style of rule already used in Steven Bellovin's Distributed Firewalls paper? http://www.research.att.com/%7Esmb/papers/distfw.html Rules like this might ease coordination with the Security Policy WG. Instead of either procudural or declarative program statements, a form more analogous to "invariant" statements would reflect the situation that the policy is intended to maintain. The tradition of invariant statements in program verification suggests that this form might help with the difficult task of verifying that a set of rules specifies what is intended. The "if then form of rules has been accepted now for over a year, and it troubles me that we now seek a need to rethink this. That being said, what is important in the PFCIM is the set of building blocks, in the form of classes, attributes and relationships, that can be used to define the structure of a policy. Steve's examples can be represented by the constructs defined by the PFCIM. So perhaps what is called for is NOT to rewrite the PFCIM in terms of Steve's or another person's alternative representation, but rather to show how different representations are equivalent. This way everyone wins. Page 13: Why is over a page devoted to the distinction between "rule specific" and "reusable" policy conditions and actions despite the assertion that "There is no inherent difference between a rule-specific condition or action and a reusable one. " I respectfully submit that this statement is being taken out of context. Earlier, the text says: It is important to understand that the difference between a rule- specific condition or action and a reusable one is based on the intent of the policy administrator for the condition or action, rather than on the current associations in which the condition or action participates. The statement that you are referencing was intended to underscore the fact that a condition or action that is initially defined as reusable may be turned into a rule-specific condition or action, and vice-versa. The difference is not one of functionality, but how the rule is stored. This is why text was devoted to explaining this and other differences in using rule-specific vs. reusable conditions and actions. So as a compromise, how about adding text to the problem statement identified above that states this? Would your concern be satisfied by doing this? Page 15: Roles The concept of role is central to the design of the entire Policy Framework. But, as was pointed out in the Policy Terms BOF in Washington, roles are associated with principals rather than with resources in much of the security policy discussion. Roles can be associated with either, and the PFCIM is designed to handle either. I'm sorry, but I'm missing your point here. The isolation (indirect reference) of "roles" as arbitrary strings associated with resources (interfaces in many discussions) is presented as a virtue. But it seems that hiding the particular abilities of policy enforcement points makes it harder to determine if policy is in effect. Does this "role" really facilitate building a policy system? Please see my earlier note in reply to Walter and Ken. Roles should not be viewed as "just attributes", but rather as a selector. Therefore, their purpose is not to hide or abstract anything. Rather, their purpose is to select a subset of applicable policies from a larger set of available policies. So in this sense, it very much facilitates building a policy system. An architectural diagram diagram is included in this draft proposed for standards track despite the controversy that has delayed progress on a framework document. Would passing "last call" on this document imply approval of the archicture we have not agreed on in the framework? I can only assume that you are referring to Figure 4, which everyone has agreed to already. However, we could insert words emphasizing that this is an example only, and is not meant as a standard architecture. Would that satisfy your concerns? As a related question, what happened to the apparent consensus of the room that we should agree on terms, policy use cases, and requirements before progressing a model that supposedly addresses them? Granted, we rushed ahead on the role term. But what other terms does this document define that are controversial? We did have agreement on the policy use cases; the cry was for more, and to separate the requirements from the use cases. No requirements were set against the PFCIM (I'm not sure how any specific requirements COULD be set against it, except to try to ensure its generality). So I'm not sure that we violated anything here... Furthermore, it is the opinion of the co-chairs that we need to progress the core information model in order to put a stake in the ground. Having no stakes in any ground has been one of the reasons that has made it hard to nail things down. So I think that progressing this document is a Good Thing. Pages 20 - 59: CIM Data Types No justification is provided for the host of decisions made in CIM, and reflected in the detailed specification of its classes and attributes. In particular, why is a different representation of time periods used than in (standards track) RFC 2445? This begs the question if (which of) the attribute syntaxes correspond to syntax already specified as standard in the IETF. This line of questions leads to the more general concern that a lot of detailed specification is proposed for IETF standards track on little more than the indication that the CIM group of the DMTF developed it. It is still not clear if this facilitates or hinders mutual support policy configuration efforts across areas of IETF interest. I honestly don't know how to respond to a rhetorical question like this. CIM represents a general object-oriented information model, and many people from many different standards bodies have spent a lot of time working on it. There are deployed systems using it. If you look at the CIM models, you will see that CIM attributes reference IETF MIB variables when appropriate. It has a special qualifier that is used explicitly for this. CIM is not trying to provide an alternative standard, set of syntaxes, or any other "nefarious" contrivance. It is simply trying to describe a managed domain in an object-oriented way. When appropriate, it will reuse IETF and possibly other standard information to achieve this goal. With respect to your question about 2445, this document uses RFC 2591 as a way to represent some of its data. We thought that that RFC was well suited to expressing what we wanted. Finally, imho, the only way to develop mutual support of policy configuration efforts across different areas of the IETF is to put a stake in the ground and encourage people to use it. The PFWG has been trying to do this for over a year, and imho it's a little late to question the foundation of the class design after we've been working for over a year on it. John _________________________________________________________ fsmail - get your free web-based email at: www.fsmail.net From majordomo@raleigh.ibm.com Mon Jan 31 18:35:04 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18196 for ; Mon, 31 Jan 2000 18:35:03 -0500 (EST) 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 SAA29084; Mon, 31 Jan 2000 18:28:49 -0500 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 SAA33906; Mon, 31 Jan 2000 18:28:48 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34892; Mon, 31 Jan 2000 18:07:41 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38468; Mon, 31 Jan 2000 18:07:39 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA26246 for ; Mon, 31 Jan 2000 18:07:42 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id RAA19665 for ; Mon, 31 Jan 2000 17:07:41 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256877.007F08B0 ; Mon, 31 Jan 2000 17:07:32 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: policy@raleigh.ibm.com Message-Id: <86256877.007F043D.00@tivmta4.tivoli.com> Date: Mon, 31 Jan 2000 18:04:45 -0500 Subject: RE: Policy issues: definition of Roles Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com I am forwarding this, and a few other notes to the mailing list on behalf of John Strassner, since he is temporarily using a source mail address that is not on the mailling list. From straz@fsmail.net Mon Jan 31 14:30:04 2000 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44164; Mon, 31 Jan 2000 14:30:04 -0500 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 OAA20472 for ; Mon, 31 Jan 2000 14:30:05 -0500 Received: from fsmail.net (216.200.119.41.reverse.not.updated.above.net [216.200.119.41] (may be forged)) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id OAA12464 for ; Mon, 31 Jan 2000 14:30:00 -0500 Received: (qmail 10493 invoked by uid 1120); 31 Jan 2000 19:30:36 -0000 Message-Id: <20000131193036.10492.qmail@fsmail.net> From: John Strassner Subject: RE: Policy issues: definition of Roles To: jsjoberg@TopLayer.com, WWeiss@lucentctc.com, policy@raleigh.ibm.com Cc: johns@cisco.com, straz@fsmail.net Date: Mon Jan 31 19:30:35 GMT 2000 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: inline Comments inline. regards, John At 06:08 AM 1/30/00 -0800, Jon Sjoberg wrote: Walter, > > The Policy Framework is then responsible for configuring > each of the resources associated with a role in such a way that it > behaves according to the policies specified for that role. > > > First, there is a reference to resources without any context. The intent is for the policy to use the role as one of several selectors to define the context for configuring the resource. For example, consider a financial institution defining policies that allocate resources based on market conditions. Roles and policies enable it to respond much faster, and in a predictable fashion, to changing market conditions than relying on individually configuring these resources. This institution could have two policies that configure the same network resources in different ways, depending on the market conditions. The context is determined by roles as well as other external conditions. If you want, text such as this could be added to make the meaning clearer. > Second, I find > policies that can only operate within the confines of a > particular resource > unnecessarily restrictive. Please refer back to the earlier response that I sent to Ken and Walter. Roles are simply selectors, to choose a subset of applicable policies from among a larger list. I don't think that the statement in the PFCIM that you are quoting says or doesn't say this. In the general case, a policy may or may not need to be restricted to a particular resources, and I find nothing wrong with doing either. On the other hand, if you are worried about the PFCIM not being able to protect the policy designer from himself or herself, then keep worrying ;-) I see no way that we can do this. If a policy designer wants to write a restrictive policy, then that is his or her right. We shouldn't prevent this, just as we shouldn't prevent the policy designer writing a very general rule. I don't understand where the second point is derived from. I guess I read the text to say that policies are confined within a specific role. It seems that policies, in the general sense, can operate across resource and role boundaries. Each policy rule that enacts a policy must be restricted, however, to a role. It would be easier, from a PDP/PEP implementation stand point, to restrict each policy rule down to a resource (and make the policy management tool do all the REAL work). Policies can be written to affect a single resource or multiple resources. Roles are used to select policies. Policy rules can use roles as one of the means to identify particular policies. If the policy rule says: IF Interface == Edge-Interface, THEN ... the role Edge-Interface is used to select all interfaces that are classified as Edge interfaces, and the action in the THEN clause is applied to all such interfaces. If the interface only one resource to be managed, so be it. If it allows multiple resources to be managed, then that's fine too. Finally, note that there is no restriction of having a policy rule be restricted to a single role. For example: IF Interface == Edge-Interface AND (Interface == ATM-Interface OR Interface == FR-Interface)... > > Roles are represented in the Core Policy Schema by values of the > PolicyKeywords property. > > > I found this text to be even more confusing because it supported a third > concept not defined in either of the two concepts I described: an > arbitrary > grouping based on a keyword possibly bound to a technology like QoS or > security, or an organization like engineering, or something else??? > Actually the possible current values are enumerated in 6.1.2, and the values fall into the "something else" category. If I read correctly, the standard possible values are: UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and "EVENT". I am not sure I fully understand many of these, though the document does explain them. Anyway, it is clearly another definition of role not akin to your two or, best I can tell, Shai's newest proposal. Actually, the values define the types of policies that are described in page 7, plus a catch-all (unknown). Now, we could have defined additional values like "Edge" and "Core", but decided that by excluding values like this, no bias was given in the core info model to any particular domain. This enables us to use the PFCIM for things like DHCP, where "Edge" and "Core" are meaningless. What is really needed is implementation experience, and so we wanted to keep the keywords as general as possible. _________________________________________________________ fsmail - get your free web-based email at: www.fsmail.net From majordomo@raleigh.ibm.com Mon Jan 31 18:37:01 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18209 for ; Mon, 31 Jan 2000 18:37:01 -0500 (EST) 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 SAA17550; Mon, 31 Jan 2000 18:28:48 -0500 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 SAA28278; Mon, 31 Jan 2000 18:28:47 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52046; Mon, 31 Jan 2000 18:10:08 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34366; Mon, 31 Jan 2000 18:10:05 -0500 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA35812 for ; Mon, 31 Jan 2000 18:10:08 -0500 Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id RAA20253 for ; Mon, 31 Jan 2000 17:10:06 -0600 (CST) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256877.007F446F ; Mon, 31 Jan 2000 17:10:05 -0600 X-Lotus-Fromdomain: TIVOLI SYSTEMS From: ellesson@raleigh.ibm.com To: policy@raleigh.ibm.com Message-Id: <86256877.007F4296.00@tivmta4.tivoli.com> Date: Mon, 31 Jan 2000 18:07:26 -0500 Subject: Re: Policy Framework Core Information Model -- Version 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@raleigh.ibm.com I am forwarding following note for John Strassner. Ed From straz@fsmail.net Mon Jan 31 14:19:56 2000 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48666; Mon, 31 Jan 2000 14:19:56 -0500 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 OAA32704 for ; Mon, 31 Jan 2000 14:19:59 -0500 Received: from fsmail.net (216.200.119.41.reverse.not.updated.above.net [216.200.119.41] (may be forged)) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id OAA33908 for ; Mon, 31 Jan 2000 14:19:54 -0500 Received: (qmail 9530 invoked by uid 1120); 31 Jan 2000 19:20:30 -0000 Message-Id: <20000131192030.9528.qmail@fsmail.net> From: John Strassner Subject: Re: Policy Framework Core Information Model -- Version 1 To: jsjoberg@TopLayer.com, policy@raleigh.ibm.com Cc: johns@cisco.com, straz@fsmail.net Date: Mon Jan 31 19:20:29 GMT 2000 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jon, comments inline. Sorry about the weird address, it will be valid for only a couple of days. Please reply to johns@cisco.com regards, John At 05:45 PM 1/25/00 -0800, Jon Sjoberg wrote: A few comments the draft: "Policy Framework Core Information Model -- Version 1 Specification". 1.) The general view that I get from the draft is that policy (as currently being focused on by this WG, not in the most general sense) is being made to apply to the aggregation of a client and some network behavior. Forgive me if I haven't had enough coffee yet ;-) but I fail to see how your examples listed below are different than, as you put it, aggregating a client and some network behavior. For example, if I look at the first example, I see a client (paying_customers), the traffic from that client (HTTP traffic ending up on landsend.com) and network behavior (priority treatment from special_servers). The following statement, from the draft, sums up the "feeling" that I get: "Service policies describe services available in the network. Usage policies describe the particular binding of a client of the network to services available in the network." Often the draft uses examples like "so-and-so gets gold service" or "use this scheme on this interface." I appreciate these are only examples, but they also further my opinion that this draft focuses on a simple aggregation. But that same page defines other types of policies (e.g., Configuration and Installation policies) that have nothing to do with aggregating clients. So if I'm reading you right, you're objecting to the emphasis of examples that focus on binding a client (human or otherwise) to a network service. Is that correct? If so, I'd be happy to add additional examples to balance things out. If not, please explain again. What I'm looking at is policies such as: All HTTP traffic from paying_customers for landsend.com gets priority network treatment from special_servers. All HTTP traffic from browsing_customers for landsend.com gets priority network treatment from unwashed_masses_servers.All FTP retr traffic for landsend.com gets bulk-transfer network treatment from unwashed_masses_servers. All FTP stor traffic for landsend.com gets denied network treatment. All of these seem to fit the mold of client binding to network service. As another example, in the last example, the FTP traffic is generated by some person or application operated on behalf of a person (e.g., a client) and the service is, in this case, being denied. Clearly these can be represented as condition/action policy rules. What I'm not so clear on is all the other stuff that goes around these policy rules. What policy keywords or roles are appropriate for these policies? Where does the definition of HTTP, paying_cutomers, FTP, etc. fit into the repository or do they (I think I remember one incarnation of this draft or the LDAP schema that sort of addressed this)? Can some one enlighten me! Thanks. The policy keywords, roles, etc. that are appropriate for these types of policies will necessarily be different for each application. The PFCIM deignated a small set of keywords and roles to standardize common, high-level concepts. If you look at these (pg 22), you'll see that they correspond to the types of policie that are described on page 6 (with "unknown" being a general catch-all). So, for the above example, if you treat a role as a selector, then you would want to define a set of policies that would select HTTP traffic and at least one other attribute (e.g., the set of IP addresses (for example) that map to landsend.com. Likewise, keywords are used to speed up searches, so you would define a set of keywords that would help you locate policy rules, conditions, actions, etc. 2.) Usage of the CIM notation seems to add to the complexity of the problem domain and to the complexity of this draft. A conservative estimate of 15 percent of the document is devoted to describing CIM work-arounds, CIM attributes that add no direct value (my opinion) to the problem domain, and CIM "quarks". Given that our intended protocol is LDAP, is there enough value to the CIM notation to use it instead of some other more robust OO representation (UML, Shlear-Mellor, etc.)? I'm not suggesting holding up last call over this (least I get shot), but perhaps we could re-work the draft to track tighter to the essential complexity of the problem? Already covered in another email I sent. Jon _________________________________________________________ fsmail - get your free web-based email at: www.fsmail.net From majordomo@raleigh.ibm.com Mon Jan 31 18:49:23 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18525 for ; Mon, 31 Jan 2000 18:49:22 -0500 (EST) 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 SAA22958; Mon, 31 Jan 2000 18:45:29 -0500 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 SAA32538; Mon, 31 Jan 2000 18:45:27 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52680; Mon, 31 Jan 2000 18:24:16 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA33728; Mon, 31 Jan 2000 18:24:13 -0500 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 SAA28136 for ; Mon, 31 Jan 2000 18:24:16 -0500 Received: from relay1.acec.com ([38.249.211.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA23330 for ; Mon, 31 Jan 2000 18:24:10 -0500 Received: from bnatale (dhcpeast1.acec.com [192.152.208.44]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id SAA05809; Mon, 31 Jan 2000 18:22:50 -0500 (EST) Message-Id: <4.2.2.20000131182027.00b31f00@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 31 Jan 2000 18:27:10 -0500 To: Andrew Smith From: Bob Natale Subject: RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC4A9@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Bob Natale At 1/31/2000:05:43 PM, Andrew Smith wrote: Hi Andrew, >So is the confusion just related to the use of the symbol "+" then? If >you're a hardware person that means "OR" and if you're a mathematical person >it means "AND". No, in my case, the problem is not with the "+" symbol or its meaning. I was questioning the word ALL in the definition of "role combination" that went like "...the set of ALL roles supported by the network entity/ component". I did not think the ALL belonged there; and I believe that subsequent discussion on the list has shown that it does not belong in the definition. >I would suggest that we (try to) stick with a simple definition for "role >combination" that uses "AND" semantics (and a new symbol - how about "&&"?). That works fine for me. All I care about on this thread is that a "role combination" DOES NOT HAVE to include ALL of the roles supported by a network entity/component (although there MAY well be a role combination which does incorporate all roles supported by a network entity/component). >If we find out later on that we need to broaden this to include ORs, NOTs >and parentheses then so be it. However, the whole goal of the role >combination concept, at least as far as I understand it in the PIB work, was >to make the multiplied-out set of possibilities as small as possible for the >sake of simplicity in the device. So, keep it simple if possible. Precisely. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From majordomo@raleigh.ibm.com Mon Jan 31 19:02:02 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18692 for ; Mon, 31 Jan 2000 19:02:01 -0500 (EST) 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 SAA29828; Mon, 31 Jan 2000 18:57:27 -0500 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 SAA18210; Mon, 31 Jan 2000 18:57:28 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44288; Mon, 31 Jan 2000 18:37:01 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28144; Mon, 31 Jan 2000 18:36:57 -0500 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 SAA34454 for ; Mon, 31 Jan 2000 18:36:57 -0500 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA33806 for ; Mon, 31 Jan 2000 18:36:52 -0500 Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 15:35:53 -0800 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC4AD@SOL> From: Andrew Smith To: "'Bob Natale'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" Subject: RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 15:35:48 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Andrew Smith And, in particular, you only need to tell the device about those roles that are relevant to it - that is where the big savings are, I think. e.g. 1. Device A has roles W, X and Y. 2. Device B has roles W, X and Z. 3. A policy that references roles W and X should be downloaded to both devices. 4. A policy that references roles W and Y should be downloaded only to device A, not device B. The role combination concept in the PIB was introduced specifically in order to do this: you have to be able to list only those roles that are relevant to the policy, not necessarily ALL roles on the device, in a role combination. (Apologies if I'm repeating stuff here). Andrew > -----Original Message----- > From: Bob Natale [mailto:bnatale@acecomm.com] > Sent: Monday, January 31, 2000 3:27 PM > To: Andrew Smith > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles ... > That works fine for me. All I care about on this thread is that a > "role combination" DOES NOT HAVE to include ALL of the roles supported > by a network entity/component (although there MAY well be a role > combination which does incorporate all roles supported by a network > entity/component). From majordomo@raleigh.ibm.com Mon Jan 31 20:28:00 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19761 for ; Mon, 31 Jan 2000 20:27:58 -0500 (EST) 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 UAA28992; Mon, 31 Jan 2000 20:23:54 -0500 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 UAA08784; Mon, 31 Jan 2000 20:23:56 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30418; Mon, 31 Jan 2000 20:00:47 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35018; Mon, 31 Jan 2000 20:00:44 -0500 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 UAA31784 for ; Mon, 31 Jan 2000 20:00:49 -0500 Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA32740 for ; Mon, 31 Jan 2000 20:00:43 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 31 Jan 2000 18:42:17 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id <1BKLFV6N>; Mon, 31 Jan 2000 18:42:10 -0600 Message-Id: <63E0DAD7784FD21188310000F80824B30269D15C@zmpkdx02.us.nortel.com> From: "Ken Roberts" To: Andrew Smith , "'Bob Natale'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" Subject: RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 18:42:07 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6C4D.2BE453AE" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Ken Roberts" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6C4D.2BE453AE Content-Type: text/plain; charset="iso-8859-1" Gents & others, I'm a little confused by Andrew's statement of a policy that has multiple roles. I understood a policy had rules. Rules may be crafted to include the notion of roles but are they separate rules or sub classes of one rule? When the statement "A policy that references roles W and X" is made does this imply there is a matrix relationship that can be established from one parent policy (/rule)? How is this managed? Why is this required? If policies have hierarchical structure can this not be done with containment or another relationship? I think I had better re-read the thread as maybe I've missed something. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. -----Original Message----- From: Andrew Smith [mailto:andrew@extremenetworks.com] Sent: Monday, January 31, 2000 3:36 PM To: 'Bob Natale' Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' Subject: RE: Policy issues: definition of Roles And, in particular, you only need to tell the device about those roles that are relevant to it - that is where the big savings are, I think. e.g. 1. Device A has roles W, X and Y. 2. Device B has roles W, X and Z. 3. A policy that references roles W and X should be downloaded to both devices. 4. A policy that references roles W and Y should be downloaded only to device A, not device B. The role combination concept in the PIB was introduced specifically in order to do this: you have to be able to list only those roles that are relevant to the policy, not necessarily ALL roles on the device, in a role combination. (Apologies if I'm repeating stuff here). Andrew > -----Original Message----- > From: Bob Natale [mailto:bnatale@acecomm.com] > Sent: Monday, January 31, 2000 3:27 PM > To: Andrew Smith > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles ... > That works fine for me. All I care about on this thread is that a > "role combination" DOES NOT HAVE to include ALL of the roles supported > by a network entity/component (although there MAY well be a role > combination which does incorporate all roles supported by a network > entity/component). ------_=_NextPart_001_01BF6C4D.2BE453AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Policy issues: definition of Roles

Gents & others,
I'm a little confused by Andrew's statement of a = policy that has multiple roles. I understood a policy had rules. Rules = may be crafted to include the notion of roles but are they separate = rules or sub classes of one rule?

When the statement "A policy that references = roles W and X" is made does this imply there is a matrix = relationship that can be established from one parent policy (/rule)? = How is this managed? Why is this required? If policies have = hierarchical structure can this not be done with containment or another = relationship?

I think I had better re-read the thread as maybe I've = missed something.

---------------------------------------------------------------= -----------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   = :        = 655-7844        =         =         ?Direct  : = 408-565-7844
?  Fax    = :        408-565-8226
? email :      = kjr@nortelnetworks.com
 
This message may contain information proprietary to = Nortel Networks Corporation so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.

 -----Original Message-----
From:   Andrew Smith [mailto:andrew@extremenetworks= .com]
Sent:   Monday, January 31, 2000 3:36 = PM
To:     'Bob Natale'
Cc:     policy@raleigh.ibm.com; = 'snmpconf@snmp.com'
Subject:        = RE: Policy issues: definition of Roles

And, in particular, you only need to tell the device = about those roles that
are relevant to it - that is where the big savings = are, I think. e.g.

1. Device A has roles W, X and Y.
2. Device B has roles W, X and Z.
3. A policy that references roles W and X should be = downloaded to both
devices.
4. A policy that references roles W and Y should be = downloaded only to
device A, not device B.

The role combination concept in the PIB was = introduced specifically in order
to do this: you have to be able to list only those = roles that are relevant
to the policy, not necessarily ALL roles on the = device, in a role
combination.

(Apologies if I'm repeating stuff here).

Andrew


> -----Original Message-----
> From: Bob Natale [mailto:bnatale@acecomm.com]
> Sent: Monday, January 31, 2000 3:27 PM
> To: Andrew Smith
> Cc: policy@raleigh.ibm.com
> Subject: RE: Policy issues: definition of = Roles
...

> That works fine for me.  All I care about = on this thread is that a
> "role combination" DOES NOT HAVE to = include ALL of the roles supported
> by a network entity/component (although there = MAY well be a role
> combination which does incorporate all roles = supported by a network
> entity/component).

------_=_NextPart_001_01BF6C4D.2BE453AE-- From majordomo@raleigh.ibm.com Mon Jan 31 20:48:47 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20113 for ; Mon, 31 Jan 2000 20:48:44 -0500 (EST) 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 UAA47502; Mon, 31 Jan 2000 20:45:17 -0500 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 UAA30022; Mon, 31 Jan 2000 20:45:20 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46006; Mon, 31 Jan 2000 20:24:32 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31394; Mon, 31 Jan 2000 20:24:28 -0500 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 UAA28022 for ; Mon, 31 Jan 2000 20:24:33 -0500 Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id UAA28320 for ; Mon, 31 Jan 2000 20:24:26 -0500 Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 17:23:35 -0800 Message-Id: <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> From: Andrew Smith To: "'Ken Roberts'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" Subject: RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 17:23:33 -0800 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Andrew Smith e.g. "HTTP traffic gets AF treatment on all Ethernet and FDDI interfaces" is a policy rule that references two roles: "Ethernet interfaces" and "FDDI interfaces". You wouldn't bother sending that rule to token-ring devices. (I guess I'm really an assembler programmer so I don't understand these "class" and "subclass" things you talk about). Andrew P.S. Maybe we should drop the "policy framework" list from this thread since this appears to be purely a "device" thing. But I did think we were attempting the (maybe thankless) task of unifying the terminology between all the WGs. -----Original Message----- From: Ken Roberts [mailto:kjr@nortelnetworks.com] Sent: Monday, January 31, 2000 4:42 PM To: Andrew Smith; 'Bob Natale' Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' Subject: RE: Policy issues: definition of Roles Gents & others, I'm a little confused by Andrew's statement of a policy that has multiple roles. I understood a policy had rules. Rules may be crafted to include the notion of roles but are they separate rules or sub classes of one rule? When the statement "A policy that references roles W and X" is made does this imply there is a matrix relationship that can be established from one parent policy (/rule)? How is this managed? Why is this required? If policies have hierarchical structure can this not be done with containment or another relationship? I think I had better re-read the thread as maybe I've missed something. -------------------------------------------------------------------------- Regards, Ken Roberts INM Product Architecture Nortel Networks ?ESN : 655-7844 ?Direct : 408-565-7844 ? Fax : 408-565-8226 ? email : kjr@nortelnetworks.com This message may contain information proprietary to Nortel Networks Corporation so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. -----Original Message----- From: Andrew Smith [mailto:andrew@extremenetworks.com] Sent: Monday, January 31, 2000 3:36 PM To: 'Bob Natale' Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' Subject: RE: Policy issues: definition of Roles And, in particular, you only need to tell the device about those roles that are relevant to it - that is where the big savings are, I think. e.g. 1. Device A has roles W, X and Y. 2. Device B has roles W, X and Z. 3. A policy that references roles W and X should be downloaded to both devices. 4. A policy that references roles W and Y should be downloaded only to device A, not device B. The role combination concept in the PIB was introduced specifically in order to do this: you have to be able to list only those roles that are relevant to the policy, not necessarily ALL roles on the device, in a role combination. (Apologies if I'm repeating stuff here). Andrew > -----Original Message----- > From: Bob Natale [mailto:bnatale@acecomm.com] > Sent: Monday, January 31, 2000 3:27 PM > To: Andrew Smith > Cc: policy@raleigh.ibm.com > Subject: RE: Policy issues: definition of Roles ... > That works fine for me. All I care about on this thread is that a > "role combination" DOES NOT HAVE to include ALL of the roles supported > by a network entity/component (although there MAY well be a role > combination which does incorporate all roles supported by a network > entity/component). From majordomo@raleigh.ibm.com Mon Jan 31 23:49:20 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24145 for ; Mon, 31 Jan 2000 23:49:20 -0500 (EST) 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 XAA23034; Mon, 31 Jan 2000 23:45:49 -0500 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 XAA23962; Mon, 31 Jan 2000 23:45:47 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43278; Mon, 31 Jan 2000 23:23:45 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39430; Mon, 31 Jan 2000 23:23:42 -0500 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 XAA32700 for ; Mon, 31 Jan 2000 23:23:47 -0500 Received: from bmailnj.iphighway.com ([209.3.6.76]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id XAA25128 for ; Mon, 31 Jan 2000 23:23:40 -0500 Received: by BMAILNJ with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jan 2000 23:21:14 -0500 Message-Id: <6399122981E1D211AB490090271E0AA33C9C66@BMAILNJ> From: Francis Reichmeyer -NJ To: "'snmpconf@snmp.com'" , "'Ken Roberts'" Cc: policy@raleigh.ibm.com, "'polterm@ops.ietf.org'" Subject: RE: snmpconf RE: Policy issues: definition of Roles Date: Mon, 31 Jan 2000 23:21:13 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Francis Reichmeyer -NJ It may be too late for this thread, but I've copied the polterm list. Future discussions of this sort might benefit from including polterm as well. Thanks, -Fran > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > Sent: Monday, January 31, 2000 8:24 PM > To: 'Ken Roberts' > Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' > Subject: snmpconf RE: Policy issues: definition of Roles > > > e.g. "HTTP traffic gets AF treatment on all Ethernet and FDDI > interfaces" is > a policy rule that references two roles: "Ethernet > interfaces" and "FDDI > interfaces". You wouldn't bother sending that rule to > token-ring devices. > > (I guess I'm really an assembler programmer so I don't > understand these > "class" and "subclass" things you talk about). > > Andrew > > P.S. Maybe we should drop the "policy framework" list from > this thread since > this appears to be purely a "device" thing. But I did think we were > attempting the (maybe thankless) task of unifying the > terminology between > all the WGs. > > -----Original Message----- > From: Ken Roberts [mailto:kjr@nortelnetworks.com] > Sent: Monday, January 31, 2000 4:42 PM > To: Andrew Smith; 'Bob Natale' > Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' > Subject: RE: Policy issues: definition of Roles > > > Gents & others, > I'm a little confused by Andrew's statement of a policy that > has multiple > roles. I understood a policy had rules. Rules may be crafted > to include the > notion of roles but are they separate rules or sub classes of > one rule? > When the statement "A policy that references roles W and X" > is made does > this imply there is a matrix relationship that can be > established from one > parent policy (/rule)? How is this managed? Why is this required? If > policies have hierarchical structure can this not be done > with containment > or another relationship? > I think I had better re-read the thread as maybe I've missed > something. > -------------------------------------------------------------- > ------------ > Regards, > Ken Roberts > INM Product Architecture > Nortel Networks > ?ESN : 655-7844 ?Direct : > 408-565-7844 > ? Fax : 408-565-8226 > ? email : kjr@nortelnetworks.com > > This message may contain information proprietary to Nortel Networks > Corporation so any > unauthorised disclosure, copying or distribution of its > contents is strictly > prohibited. > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > Sent: Monday, January 31, 2000 3:36 PM > To: 'Bob Natale' > Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com' > Subject: RE: Policy issues: definition of Roles > And, in particular, you only need to tell the device about > those roles that > are relevant to it - that is where the big savings are, I think. e.g. > 1. Device A has roles W, X and Y. > 2. Device B has roles W, X and Z. > 3. A policy that references roles W and X should be > downloaded to both > devices. > 4. A policy that references roles W and Y should be > downloaded only to > device A, not device B. > The role combination concept in the PIB was introduced > specifically in order > > to do this: you have to be able to list only those roles that > are relevant > to the policy, not necessarily ALL roles on the device, in a role > combination. > (Apologies if I'm repeating stuff here). > Andrew > > > > -----Original Message----- > > From: Bob Natale [mailto:bnatale@acecomm.com] > > Sent: Monday, January 31, 2000 3:27 PM > > To: Andrew Smith > > Cc: policy@raleigh.ibm.com > > Subject: RE: Policy issues: definition of Roles > ... > > That works fine for me. All I care about on this thread is that a > > "role combination" DOES NOT HAVE to include ALL of the > roles supported > > by a network entity/component (although there MAY well be a role > > combination which does incorporate all roles supported by a network > > entity/component). >