From moulton@snmp.com Mon Jan 31 11:50:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09301 for ; Mon, 31 Jan 2000 11:50:08 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id LAA04194 for ; Mon, 31 Jan 2000 11:49:39 -0500 (EST) Message-Id: <200001311649.LAA04194@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf-archive@ietf.org Subject: initial posting to active working group list Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 31 Jan 2000 11:49:39 -0500 From: Steve Moulton Content-Transfer-Encoding: 8bit This posting came into snmpconf@snmp.com between working group creation and adding the IETF archive to the mailing list. ------- Forwarded Message Return-Path: saperia@mediaone.net Delivery-Date: Mon Jan 31 11:40:09 2000 Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id LAA04037 for ; Mon, 31 Jan 2000 11:40:07 -0500 (EST) Received: from mediaone.net (h0050e460d16d.ne.mediaone.net [24.128.60.221]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA00740 for ; Mon, 31 Jan 2000 11:39:35 -0500 (EST) Message-ID: <3895BADE.1E55CAEF@mediaone.net> Date: Mon, 31 Jan 2000 11:39:59 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Tech Team Subject: [Fwd: WG Action: Configuration Management with SNMP (snmpconf)] Content-Type: multipart/mixed; boundary="------------CD6EBEF379CCAE97A07E5A8C" This is a multi-part message in MIME format. --------------CD6EBEF379CCAE97A07E5A8C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are off and running now. /jon --------------CD6EBEF379CCAE97A07E5A8C Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from chmls16.mediaone.net ([24.128.1.213]) by chmls14.mediaone.net (Netscape Messaging Server 4.1) with ESMTP id FP7E8V00.NQX; Mon, 31 Jan 2000 09:14:55 -0500 Received: from chmls12.mediaone.net (chmls12.mediaone.net [24.128.1.214]) by chmls16.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA19356; Mon, 31 Jan 2000 09:14:55 -0500 (EST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by chmls12.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA10262; Mon, 31 Jan 2000 09:14:49 -0500 (EST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA19371 for ietf-123-outbound.09@ietf.org; Mon, 31 Jan 2000 07:55:05 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA19339 for ; Mon, 31 Jan 2000 07:50:56 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01762 for ; Mon, 31 Jan 2000 07:50:54 -0500 (EST) Message-Id: <200001311250.HAA01762@ietf.org> From: The IESG To: IETF-Announce: ; Subject: WG Action: Configuration Management with SNMP (snmpconf) Date: Mon, 31 Jan 2000 07:50:54 -0500 Sender: scoya@cnri.reston.va.us X-Mozilla-Status2: 00000000 A new working group has been formed in the Operations and Management Area of the IETF. For additional information, contact the Area Directors or the WG Chair. Configuration Management with SNMP (snmpconf) --------------------------------------------- Current Status: Active Working Group Chair(s): Jonathan Saperia David Harrington Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Bert Wijnen Mailing Lists: General Discussion:snmpconf@snmp.com To Subscribe: snmpconf-request@snmp.com In Body: subscribe snmpconf Archive: snmpconf-request@snmp.com (index snmpconf in body) Description of Working Group: The working group will create a Best Current Practices document which outlines the most effective methods for using the SNMP Framework to accomplish configuration management. The scope of the work will include recommendations for device specific as well as network-wide (Policy) configuration. The group is also chartered to write any MIB modules necessary to facilitate configuration management, specifically they will write a MIB module which describes a network entities capabilities and capacities which can be used by management entities making policy decisions at a network level or device specific level. As a proof of concept, the working group will also write a MIB module which describes management objects for the control of differentiated services policy in coordination with the effort currently taking place in the Differentiated Services Working Group. Deliverables 1. A Best Current Practices document to provide guidelines on how to best use the existing Internet Standard Management Framework to perform configuration management. 2. A MIB module which describes a network entities capabilities such as support for a particular type of security or a particular queuing method on certain interfaces. The module will also convey the capacity of the device to perform certain work. 3. A MIB module which can be used to concisely convey information about desired network wide Diffserv Based QoS behavior. AD wonders: We indeed only want to do QoS for Diffserv for now to prove the concepts, right? 4. A document which describes potential future work needed to meet all the Requirements for Configuration Management. Goals and Milestones: Jan 00 Announce Working Group and call for Input Feb 00 Submit Initial Drafts for BCP and MIB Documents Mar 00 Meet at 47th IETF in Adelaide May 00 Interim Meeting May 00 Revised Drafts for BCP and MIB Documents and WG Last Call these Drafts. Submit to AD for consideration as BCP and PS. Jun 00 Conduct Interoperability Testing Jul 00 New Internet Drafts, including a document describing potential future work. Aug 00 Meet at 48th IETF meeting in Pittsburgh Sep 00 WG Last Call on remaining Drafts. Submit to AD for consideration as BCP and PS. Oct 00 Re-charter or shutdown WG. --------------CD6EBEF379CCAE97A07E5A8C-- ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 17:25:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17104 for ; Mon, 31 Jan 2000 17:25:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id RAA09650 for snmpconf-outgoing; Mon, 31 Jan 2000 17:05:59 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC4A7@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Subject: snmpconf FW: Majordomo results Date: Mon, 31 Jan 2000 14:04:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Can someone tell me how to retrieve the mail archive for this WG? All I get from the "index snmpconf" command is the enclosed message. Thanks, Andrew -----Original Message----- From: Majordomo@snmp.com [mailto:Majordomo@snmp.com] Sent: Monday, January 31, 2000 1:52 PM To: andrew@extremenetworks.com Subject: Majordomo results -- >>>> index snmpconf total 36 -rw-rw---- 1 majordom 36792 Jan 31 11:43 snmpconf.0001 From owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 17:42:52 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17562 for ; Mon, 31 Jan 2000 17:42:52 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id RAA10313 for snmpconf-outgoing; Mon, 31 Jan 2000 17:28:48 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200001312228.RAA10300@seymour39.SNMP.COM> to: snmpconf@snmp.com, owner-snmpconf@snmp.com Subject: Re: snmpconf FW: Majordomo results Date: Mon, 31 Jan 2000 17:28:45 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com > Can someone tell me how to retrieve the mail archive for this WG? All I get > from the "index snmpconf" command is the enclosed message. > > Thanks, > > Andrew > > > -----Original Message----- > From: Majordomo@snmp.com [mailto:Majordomo@snmp.com] > Sent: Monday, January 31, 2000 1:52 PM > To: x@yy.zzz > Subject: Majordomo results > > > -- > > >>>> index snmpconf > total 36 > -rw-rw---- 1 majordom 36792 Jan 31 11:43 snmpconf.0001 This file contains the entire archive for the working group. A new archive file is started monthly. The majordomo syntax for doing this is get Or, in this case, get snmpconf snmpconf.0001 You will get two messages, one acknowledging your request, and one with the archive. The address owner-snmpconf is being watched for administrative requests and questions, and will not post to the entire list. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 18:52:10 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18552 for ; Mon, 31 Jan 2000 18:52:10 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id SAA11209 for snmpconf-outgoing; Mon, 31 Jan 2000 18:36:53 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC4AD@SOL> From: Andrew Smith To: "'Bob Natale'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" Subject: snmpconf 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: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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 owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 19:22:49 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18871 for ; Mon, 31 Jan 2000 19:22:49 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id TAA11434 for snmpconf-outgoing; Mon, 31 Jan 2000 19:07:47 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC4B0@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Cc: "Bert Wijnen (E-mail)" , "'Scott Bradner'" Subject: Re: snmpconfig Re: Work on the Diff Serv Policy MIB Date: Mon, 31 Jan 2000 16:06:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I hope I am not too late to catch this departing thread - the list and WG were only publicly announced today so I hope not too many decisions have been made already in everyone's absence - I would suggest that the WG chairs send a recap message as to where we are today with proposed documents and authors/editors since this is the first official day of public operation of this WG. I am confused about the value of a MIB with "BCP" status. Surely this should be either standards'-track or informational. [Are there other instances of BCP MIBs?]. Assuming that this should be a standards'track MIB, then I too do not see the point of having 2 WGs working on the same thing: as John Seligson pointed out, it is an explicit goal of the PIB syntax being developed in the RAP WG and the specific QoS PIB work item that the DiffServ WG has taken up, to have the PIB document machine-translatable into a QoS policy configuration MIB. It seems like there is an inconsistency forming here - the deliverable #3 of this WG really ought to be a work item for the DiffServ WG, not this one, according to principles espoused by both Scott Bradner and Bert Wijnen over the last few months. Andrew P.S. Procedural note for Steve Coya - when an announcement about a proposed new WG goes out, it does not mention which forum is appropriate for discussion and development of the WG's charter: thus, the first few months of any WGs task is often devoted to charter discussions such as my points above. In this instance, AFAIK, no BoF was held on the topic of this new WG (the conf-mgmt BoF and its associated design team, is on a related topic but, as Bert pointed out to me in a private email, this is still in operation and is focusing on development of requirements, not solutions) and, based on my reading of the minutes of the by-invitation-only meeting in Chicago last September, there was really no clear consensus that a WG on SNMP-based configuration was the appropriate next step. **************************************************************** 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 **************************************************************** Message-ID: <387F8DE8.E327A2B@mediaone.net> Date: Fri, 14 Jan 2000 15:58:16 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: John Seligson CC: snmpconfig , Aiko Pras , David Partain , TSS management group , snmpconf@snmp.com Subject: Re: snmpconfig Re: Work on the Diff Serv Policy MIB ... Bottom line we are not duplicating the work of the DiffServ MIB that is instance level information ours, like the PIB will be policy based. In that sense our MIB is a duplication of the policy PIB. The BCP will cover protocol operations, mib design, and perhaps even configuration suggestions for notifications. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 20:37:08 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19950 for ; Mon, 31 Jan 2000 20:37:07 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id UAA11946 for snmpconf-outgoing; Mon, 31 Jan 2000 20:24:34 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> From: Andrew Smith To: "'Ken Roberts'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" Subject: snmpconf 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: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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 owner-snmpconf@seymour39.SNMP.COM Mon Jan 31 23:35:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24035 for ; Mon, 31 Jan 2000 23:35:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id XAA13356 for snmpconf-outgoing; Mon, 31 Jan 2000 23:23:46 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f 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: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com 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). >