From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 01:46:39 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 BAA28974 for ; Tue, 1 Feb 2000 01:46:39 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id BAA20171 for snmpconf-outgoing; Tue, 1 Feb 2000 01:34:55 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Date: Tue, 1 Feb 2000 07:34:05 +0100 Message-Id: <200002010634.HAA00525@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: FranR@iphighway.com CC: snmpconf@snmp.com, policy@raleigh.ibm.com, polterm@ops.ietf.org In-reply-to: <6399122981E1D211AB490090271E0AA33C9C66@BMAILNJ> (message from Francis Reichmeyer -NJ on Mon, 31 Jan 2000 23:21:13 -0500) Subject: Re: snmpconf RE: Policy issues: definition of Roles References: <6399122981E1D211AB490090271E0AA33C9C66@BMAILNJ> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Francis Reichmeyer -NJ writes: Francis> It may be too late for this thread, but I've copied the Francis> polterm list. Future discussions of this sort might benefit Francis> from including polterm as well. Can we please do the opposite and use just one mailing list? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 05:35:13 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 FAA10733 for ; Tue, 1 Feb 2000 05:35:13 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id FAA23243 for snmpconf-outgoing; Tue, 1 Feb 2000 05:22:53 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002011022.FAA37948@northrelay03.pok.ibm.com> Date: Tue, 1 Feb 00 11:22:29 CET From: "Bert Wijnen" To: snmpconf@snmp.com Subject: snmpconf Re: Policy issues: definition of Roles Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Let me suggest a procedure so we do not get all these cross postings. As you can see, I post to one list at a time, so that the REPLY button that some people use do not automatically cross post too. As you can see from the subject line, this topic (I think) should be discussed on the POLICY wg mailing list and not be cross posted to a set of other lists. The issue there has to do with the defenition of that term in the core info model document that is currently in WG last call in the Policy WG. If you want to join the discussion, then you should subscribe and post to the policy wg mailing list: policy@raleigh.ibm.com, normal majordomo subscription mechanism I believe. After the POLICY wg list has agreed on how they want to define the term, then they might want to post their viewpoint to polterm mailing list so that any other viewpoints that were not yet considered can be discussed as well. After that, it may be a term that the Polterm DT (Design Team) may include in their terminology document. Bert From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 05:56:04 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 FAA10839 for ; Tue, 1 Feb 2000 05:56:03 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id FAA23398 for snmpconf-outgoing; Tue, 1 Feb 2000 05:44:42 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002011044.FAA49658@northrelay03.pok.ibm.com> Date: Tue, 1 Feb 00 11:44:07 CET From: "Bert Wijnen" To: andrew@extremenetworks.com, snmpconf@snmp.com Subject: snmpconfig Re: Work on the Diff Serv Policy MIB Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Ref: Your note of Mon, 31 Jan 2000 16:06:48 -0800 Subject: Re: snmpconfig Re: Work on the Diff Serv Policy MIB Andrew, new (planned) work and WGs are normally something that the IESG decides upon in collaboration with IAB and potential WG chairs for the new WG. We basically have two cycles. In the first cycle we "approve/agree" to the new work in the IESG. It then gets posted to new-work and IETF-announce mailing lists. This is to sollicit general public and other standards bodies to let us know if they see any trouble with the proposed work. Normal review time is one week. If we do not get any comments, then in the seconf cycle we (IESG) "approove/agree" the new work and Steve announces that the WG has been formed. We did go through that process, and the initial announce was on 24 march. So I agree that the final announce was immediately after the timeout.. but then, we did not get any feedback that there would be any problem. W.r.t. to this WG, you also knew (or could have known) that it was coming, because I did sort of pre-announce our IESG thinking in this area in the week after the last IETF. This was requested by many people who wanted to know what we would do as a result of the CONFIG MANAGEMENT BOF we had at that IETF meeting in DC. I posted the IESG thinking of letting both COPS/PIB and SNMP/MIB work to go on concurrently. I posted that to at least 2 or 3 mailing lists, I need to check if you want to know the exact ones. It included a statement that we would consider chartering this new SNMPCONF WG. It also included the statement that RAP can continue with COPS/PIB and that Diffserv would do a PIB. When forming thsi SNMPCONF WG, we did discuss if the diffserv policy MIB that this WG is planning to do should be put into diffserv WG. But those WG chairs are of course not eager to entertain that (they were also quite reluctant to accept the PIB work). SO we have formulated it in this SNMPCONF WG in such a way that the WG needs to make sure they interact with the Diffserv WG. So... decision on if this WG is a good thing to do or not seem out of scope for this list. Feel free communicate with me or the IESG about the decision to start this WG, but do not clutter this list with that discussion. This WG has been chartered and I hope they will focus on meeting the milestones in the charter. Bert From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 10:05:17 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 KAA20777 for ; Tue, 1 Feb 2000 10:05:17 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id JAA25796 for snmpconf-outgoing; Tue, 1 Feb 2000 09:48:33 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <3896F1AC.90796A59@cabletron.com> Date: Tue, 01 Feb 2000 09:46:04 -0500 From: David Harrington X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconfig Re: Work on the Diff Serv Policy MIB References: <808F64DDB492D3119D3C00508B5D8D733EC4B0@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi Andrew, Andrew Smith wrote: > > > 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?]. > There are three deliverables - one BCP document and two MIBs. The MIBs will not be BCP status, only the BCP document will have that status. The appropriate status for the MIB documents will be determined once the MIBs are completed. dbh@cabletron.com From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 11:56:42 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 LAA25114 for ; Tue, 1 Feb 2000 11:56:42 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id LAA29807 for snmpconf-outgoing; Tue, 1 Feb 2000 11:39:22 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC4B3@SOL> From: Andrew Smith To: "'Bert Wijnen '" , "'snmpconf@snmp.com '" Cc: "'sob@harvard.edu'" Subject: RE: snmpconfig Re: Work on the Diff Serv Policy MIB Date: Tue, 1 Feb 2000 08:38:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Bert, I think that "the WG chairs wouldn't want to do it" is a very poor reason to change a fairly well-established IESG principle that Scott has been defending for for quite a while. Such principles should either be applied uniformly or discarded: pick one. Andrew -----Original Message----- From: Bert Wijnen To: andrew@extremenetworks.com; snmpconf@snmp.com Sent: 02/01/2000 3:44 AM Subject: snmpconfig Re: Work on the Diff Serv Policy MIB Ref: Your note of Mon, 31 Jan 2000 16:06:48 -0800 Subject: Re: snmpconfig Re: Work on the Diff Serv Policy MIB Andrew, new (planned) work and WGs are normally something that the IESG decides upon in collaboration with IAB and potential WG chairs for the new WG. We basically have two cycles. In the first cycle we "approve/agree" to the new work in the IESG. It then gets posted to new-work and IETF-announce mailing lists. This is to sollicit general public and other standards bodies to let us know if they see any trouble with the proposed work. Normal review time is one week. If we do not get any comments, then in the seconf cycle we (IESG) "approove/agree" the new work and Steve announces that the WG has been formed. We did go through that process, and the initial announce was on 24 march. So I agree that the final announce was immediately after the timeout.. but then, we did not get any feedback that there would be any problem. W.r.t. to this WG, you also knew (or could have known) that it was coming, because I did sort of pre-announce our IESG thinking in this area in the week after the last IETF. This was requested by many people who wanted to know what we would do as a result of the CONFIG MANAGEMENT BOF we had at that IETF meeting in DC. I posted the IESG thinking of letting both COPS/PIB and SNMP/MIB work to go on concurrently. I posted that to at least 2 or 3 mailing lists, I need to check if you want to know the exact ones. It included a statement that we would consider chartering this new SNMPCONF WG. It also included the statement that RAP can continue with COPS/PIB and that Diffserv would do a PIB. When forming thsi SNMPCONF WG, we did discuss if the diffserv policy MIB that this WG is planning to do should be put into diffserv WG. But those WG chairs are of course not eager to entertain that (they were also quite reluctant to accept the PIB work). SO we have formulated it in this SNMPCONF WG in such a way that the WG needs to make sure they interact with the Diffserv WG. So... decision on if this WG is a good thing to do or not seem out of scope for this list. Feel free communicate with me or the IESG about the decision to start this WG, but do not clutter this list with that discussion. This WG has been chartered and I hope they will focus on meeting the milestones in the charter. Bert From owner-snmpconf@seymour39.SNMP.COM Tue Feb 1 12:09: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 MAA25491 for ; Tue, 1 Feb 2000 12:09:05 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id LAA00156 for snmpconf-outgoing; Tue, 1 Feb 2000 11:50:50 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38970E78.24A06935@cabletron.com> Date: Tue, 01 Feb 2000 11:48:56 -0500 From: David Harrington X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf Editor Task Lists References: <3895FD65.3FB5A76C@mediaone.net> <3896B693.C6952BB4@ctit.utwente.nl> <3896E3BD.DFFF05AD@mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, We have a very short period to complete the initial drafts of the documents. To help focus your efforts and to improve communication within each team and between teams, would the editor-teams please prepare a quick task list/outline for the document they plan to produce, and choose a lead editor for each document as the point of contact for the chairs to beat up on (ahh, the fun part of this job)? This task list can help the teams to divide the work between the editors so they can work in parallel, and will highlight the areas where we need the WG to propose specific engineering solutions, i.e. everything other than the general MIB format, recognized best-current-practices, and initial proposed text. The task list will also provide the chairs and ADs some insight as to your planned directions to be sure your plans are in scope and focused on the deliverables, and will serve as a public announcement to the WG of the planned directions of the documents, to keep us all representing WG consensus. To be clear, this is an effort to keep you focused on the deliverables, not to micro-manage your efforts. Neither Jon nor I will have the time to watch your efforts closely, so we need to know that you are heading in the right directions, that you have enough background info to proceed independently, that the team agrees on its direction, and that all members have assignments. The main thing I will be watching closely is that you are acting as editors, reflecting WG consensus, and not as independent authors, promoting only your own ideas. I consider that role especially important since many of our editors have limited IETF experience and are unaccustomed to the consensus constraint. Please get your task list/outline to the chairs by February 7. Thanks, dbh From owner-snmpconf@seymour39.SNMP.COM Sun Feb 6 21:07: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 VAA14308 for ; Sun, 6 Feb 2000 21:07:07 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id UAA02448 for snmpconf-outgoing; Sun, 6 Feb 2000 20:50:36 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 06 Feb 2000 17:49:56 -0800 To: Andrew Smith , "'Ken Roberts'" From: "John C. Strassner" Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com A role is just one of possibly many selectors that is used to download a subset of appropriate policies from a much larger set of availale policies. A role can be specified as part of a policy condition or action, both of which are components of a policy rule as defined in the Policy Core Information Model. HTH, John At 05:23 PM 1/31/00 -0800, Andrew Smith wrote: >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 Tue Feb 8 12:23:32 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 MAA03066 for ; Tue, 8 Feb 2000 12:23:30 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id LAA06613 for snmpconf-outgoing; Tue, 8 Feb 2000 11:23:36 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 08:22:33 -0800 To: Shai Herzog , "John C. Strassner" , Andrew Smith , "'Ken Roberts'" From: "John C. Strassner" Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: <4.2.0.58.20000206232138.02f037b0@209.3.6.76> References: <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com> <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_43600744==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_43600744==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Shai, comments inline. regards, John At 11:48 PM 2/6/00 -0500, Shai Herzog wrote: >I think that one of the problems is that we're confusing the >various levels of "roles". Let me try to make the following >observations: Levels of roles? If a role is indeed an attribute used as a selector, this translates to levels of attributes. My head is hurting. ;-) More to the point, I don't know what you mean by "levels" of roles... I humbly submit that you're making this too complicated. Instead, thinking of roles as a means to select from among a larger subset is appealing because it always means the same thing each time it is used. >1. Roles and Role Combinations have only meaning (in the > definition sense) in the PEP. I disagree. Granted that for the cases we've considered so far, it has been tied specifically to device interfaces. But a "role" is an age-old concept, and can be used equally in other contexts as well - roles as a selector to the type of job that a person is performing, for example. Which can be tied back to networking (Shai's CTO role gets him on the Engineering subnet, whereas Shai's marketing role gets him onto the Marketing subnet). I suspect that as IPSP gets kicked off, they will want to use a more general definition of roles than just to describe the capabilities of a device interface. >2. PDPs and DEN Policy Schemas may or may not take advantage of PEP > roles. > > For example: > > PEP Roles: Edge+Ethernet, Edge+T1 > PDP Policy: If User=Joe, Mark (Traffic Desc) DSCP=AF11. > > Here the PDP may actually track down the ingress router and > mark on ALL of its interfaces, regardless of Roles. It will > produce the following instructions: > > Role = Edge+Ethernet: Mark (Traffic Desc) DSCP AF11 > Role = Edge+T1 : Mark (Traffic Desc) DSCP AF11 > > My point is that we should stop thinking that the policy is bound > to roles 1:1. I certainly never said that. A policy can contain multiple roles, and a role can be used by multiple policies. In fact, if you think of a role as a selector, you couldn't draw that conclusion anyway. So at least we agree here. ;-) >3. PEPs are not expected to be able to merge policies for Roles in > Role combination. > > Given the previous example, the PDP is not allowed to send the > following to the PEP: > > Role=Edge : Conf1 > Role=Ethernet: Conf2 > > Since the PEP that has an interface with both roles in a role > combination (Edge+Ethernet) is now required to merge Conf1+Conf2. > This merge is a big NO NO, since the whole point about external > policy processing is that the PEP doesn't understand policy > implications and complications and needs to receive very specific > instructions. Agreed >4. PDPs may be smart enough to merge roles (and therefore deal with > individual roles within a role combination). This is actually > an implication of observation (2) but I though it needs to be > clarified. > > For example, in the PDP, lets assume Ethernets get special > treatment (higher precedence rule). > > Role=Edge : If Service=Gold then Mark DSCP=xxx > Role=Ethernet: If Service=Gold then Mark DSCP=yyy > > This will produce the following configuration (using COPS, or equiv): > > Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy > Role=Edge+T1 : Mark (Traffic Desc) DSCP=xxx > >So, going back to the definition I gave a while back, the reason for >the "ALL" comes from observation 3. > >PDPs can process policy whatever the hell they wish (within reason) >but they have to respond to the PEP with specific policy for each >COMPLETE role combination, and cannot respond to partial role >combination or a specific role which is only a part of a role >combination. Seems to me that you want to differentiate between roles as used to influence device configuration on the PEP level vs. roles as used to build policy statements at the PDP level. Is this what you meant by "levels" of roles? If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith suggested earlier) vs. roles as a selector (to make me happy ;-) ) >Shai > >At 05:49 PM 02/06/2000, John C. Strassner wrote: >>A role is just one of possibly many selectors that is used to download a >>subset of appropriate policies from a much larger set of availale policies. >> >>A role can be specified as part of a policy condition or action, both of >>which are components of a policy rule as defined in the Policy Core >>Information Model. >> >>HTH, >>John >> >>At 05:23 PM 1/31/00 -0800, Andrew Smith wrote: >>>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). > > >__________________________________________________________________ >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 > > > > > > --=====================_43600744==_.ALT Content-Type: text/html; charset="us-ascii" Hi Shai, comments inline.

regards,
John

At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
I think that one of the problems is that we're confusing the
various levels of "roles". Let me try to make the following
observations:

<js>
Levels of roles? If a role is indeed an attribute used as a selector, this translates to levels of attributes. My head is hurting. ;-) More to the point, I don't know what you mean by "levels" of roles...

I humbly submit that you're making this too complicated. Instead, thinking of roles as a means to select from among a larger subset is appealing because it always means the same thing each time it is used.
</js>

1. Roles and Role Combinations have only meaning (in the
   definition sense) in the PEP.

<js>
I disagree. Granted that for the cases we've considered so far, it has been tied specifically to device interfaces. But a "role" is an age-old concept, and can be used equally in other contexts as well - roles as a selector to the type of job that a person is performing, for example. Which can be tied back to networking (Shai's CTO role gets him on the Engineering subnet, whereas Shai's marketing role gets him onto the Marketing subnet).

I suspect that as IPSP gets kicked off, they will want to use a more general definition of roles than just to describe the capabilities of a device interface.
</js>

2. PDPs and DEN Policy Schemas may or may not take advantage of PEP
   roles.

   For example:

   PEP Roles: Edge+Ethernet, Edge+T1
   PDP Policy: If User=Joe, Mark (Traffic Desc) DSCP=AF11.

   Here the PDP may actually track down the ingress router and
   mark on ALL of its interfaces, regardless of Roles. It will
   produce the following instructions:

   Role = Edge+Ethernet: Mark (Traffic Desc) DSCP AF11
   Role = Edge+T1      : Mark (Traffic Desc) DSCP AF11

   My point is that we should stop thinking that the policy is bound
   to roles 1:1.

<js>
I certainly never said that. A policy can contain multiple roles, and a role can be used by multiple policies. In fact, if you think of a role as a selector, you couldn't draw that conclusion anyway. So at least we agree here. ;-)
</js>

3. PEPs are not expected to be able to merge policies for Roles in
   Role combination.

   Given the previous example, the PDP is not allowed to send the
   following to the PEP:

   Role=Edge    : Conf1
   Role=Ethernet: Conf2

   Since the PEP that has an interface with both roles in a role
   combination (Edge+Ethernet) is now required to merge Conf1+Conf2.
   This merge is a big NO NO, since the whole point about external
   policy processing is that the PEP doesn't understand policy
   implications and complications and needs to receive very specific
   instructions.

<jcs> Agreed </js>

4. PDPs may be smart enough to merge roles (and therefore deal with
   individual roles within a role combination). This is actually
   an implication of observation (2) but I though it needs to be
   clarified.

   For example, in the PDP, lets assume Ethernets get special
   treatment (higher precedence rule).

   Role=Edge    : If Service=Gold then Mark DSCP=xxx
   Role=Ethernet: If Service=Gold then Mark DSCP=yyy

   This will produce the following configuration (using COPS, or equiv):

   Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy
   Role=Edge+T1      : Mark (Traffic Desc) DSCP=xxx

So, going back to the definition I gave a while back, the reason for
the "ALL" comes from observation 3.

PDPs can process policy whatever the hell they wish (within reason)
but they have to respond to the PEP with specific policy for each
COMPLETE role combination, and cannot respond to partial role
combination or a specific role which is only a part of a role
combination.

<js>
Seems to me that you want to differentiate between roles as used to influence device configuration on the PEP level vs. roles as used to build policy statements at the PDP level. Is this what you meant by "levels" of roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>


Shai

At 05:49 PM 02/06/2000, John C. Strassner wrote:
A role is just one of possibly many selectors that is used to download a subset of appropriate policies from a much larger set of availale policies.

A role can be specified as part of a policy condition or action, both of which are components of a policy rule as defined in the Policy Core Information Model.

HTH,
John

At 05:23 PM 1/31/00 -0800, Andrew Smith wrote:
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).


__________________________________________________________________
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




                            

--=====================_43600744==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 12:28:44 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 MAA03347 for ; Tue, 8 Feb 2000 12:28:43 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id MAA07760 for snmpconf-outgoing; Tue, 8 Feb 2000 12:11:52 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 12:11:24 -0500 To: "John C. Strassner" , "John C. Strassner" , Andrew Smith , "'Ken Roberts'" From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com> References: <4.2.0.58.20000206232138.02f037b0@209.3.6.76> <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com> <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_344563736==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_344563736==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:22 AM 02/08/2000, John C. Strassner wrote: >Hi Shai, comments inline. > >regards, >John > >At 11:48 PM 2/6/00 -0500, Shai Herzog wrote: >>I think that one of the problems is that we're confusing the >>various levels of "roles". Let me try to make the following >>observations: > > >Levels of roles? If a role is indeed an attribute used as a selector, this >translates to levels of attributes. My head is hurting. ;-) More to the >point, I don't know what you mean by "levels" of roles... Sorry, didn't mean to hurt anyone ;-) I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our head, etc.... >I humbly submit that you're making this too complicated. Instead, thinking >of roles as a means to select from among a larger subset is appealing >because it always means the same thing each time it is used. > I think the two of us have been discussing this for perhaps years ;-) I believe that the input to the PDP (schema, GUI, whatever) isn't necessarily mapped 1:1 with PEP configuration (In fact, it better not be). This means that the PDP may have as input an E-2-E definition w/o roles ( this user gets gold service (low delay, drop) ) The PDP gets this non-role info and converts it into COPS commands to configure the PEP based on roles: Role=Edge, DS GOLD Service -> Mark DSCP AF11 So, the schema didn't have roles, but roles were used in configuring the edge router. So, the role isn't a selector in the schema (although simple schema may use it) it is also not a selector at the PDP, but only a selector for the PEP to advertise the kind of roles it has, and receive policy for each one of its roles. ... > >Seems to me that you want to differentiate between roles as used to >influence device configuration on the PEP level vs. roles as used to build >policy statements at the PDP level. Is this what you meant by "levels" of >roles? > >If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith >suggested earlier) vs. roles as a selector (to make me happy ;-) ) > YES YES YES, you hit it bulls eye! I was talking about PEP roles only and was trying (clumsily) to express myself, thanks! So, lets call it "PEP ROLES" As for the other one, I believe PDP is merely an interpreter (in comes abstract policy, out goes device policy) so it doesn't really have roles. So, we should find another name for the second type that you described, perhaps "Profile" (as in "user profile, application profile,...)? or "Usage Roles". 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 --=====================_344563736==_.ALT Content-Type: text/html; charset="us-ascii" At 08:22 AM 02/08/2000, John C. Strassner wrote:
Hi Shai, comments inline.

regards,
John

At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
I think that one of the problems is that we're confusing the
various levels of "roles". Let me try to make the following
observations:

<js>
Levels of roles? If a role is indeed an attribute used as a selector, this translates to levels of attributes. My head is hurting. ;-) More to the point, I don't know what you mean by "levels" of roles...

Sorry, didn't mean to hurt anyone ;-)
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our
head, etc....


I humbly submit that you're making this too complicated. Instead, thinking of roles as a means to select from among a larger subset is appealing because it always means the same thing each time it is used.
</js>

I think the two of us have been discussing this for perhaps years ;-)
I believe that the input to the PDP (schema, GUI, whatever) isn't
necessarily mapped 1:1 with PEP configuration (In fact, it better
not be). This means that the PDP may have as input an E-2-E definition
w/o roles ( this user gets gold service (low delay, drop) ) The PDP
gets this non-role info and converts it into COPS commands to
configure the PEP based on roles:

Role=Edge, DS GOLD Service -> Mark DSCP AF11

So, the schema didn't have roles, but roles were used in configuring the
edge router.

So, the role isn't a selector in the schema (although simple schema may
use it) it is also not a selector at the PDP, but only a selector
for the PEP to advertise the kind of roles it has, and receive policy
for each one of its roles.
...

<js>
Seems to me that you want to differentiate between roles as used to influence device configuration on the PEP level vs. roles as used to build policy statements at the PDP level. Is this what you meant by "levels" of roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>

YES YES YES, you hit it bulls eye! I was talking about PEP roles only
and was trying (clumsily) to express myself, thanks!

So, lets call it "PEP ROLES"

As for the other one, I believe PDP is merely an interpreter (in comes
abstract policy, out goes device policy) so it doesn't really have
roles. So, we should find another name for the second type that you
described, perhaps "Profile" (as in "user profile, application
profile,...)? or "Usage Roles".

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
                                             

        
                                
                             --=====================_344563736==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 14:18:00 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 OAA08288 for ; Tue, 8 Feb 2000 14:17:59 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA10865 for snmpconf-outgoing; Tue, 8 Feb 2000 14:00:55 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208134959.01ac2500@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 14:00:46 -0500 To: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com, kjr@nortelnetworks.com From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Yap. It just dawned on me that a roles are "logical interfaces" in the router, as opposed to "physical interfaces". So, in a router with physical interfaces S0..S4, rather than SNMP: "Configure interface S0 with ....." "Configure interface S1 with ....." "Configure interface S2 with ....." "Configure interface S3 with ....." "Configure interface S4 with ....." The PDP says (using COPS or similar): "Configure role "Edge+Serial" with ....." And the PEP knows that it has 5 serial physical interfaces with this role combination and configures S0..S4 with .... Shai P.S., ...With a note regarding "user profiles" and other attributes used in the schema, which may overload the term Roles but aren't related to the PEP roles. I call it user profiles since this is the terminology used in security, access policies, and many other areas of networking. At 12:44 PM 02/08/2000, avri.doria@nokia.com wrote: >So, the role isn't a selector in the schema (although simple schema may >use it) it is also not a selector at the PDP, but only a selector >for the PEP to advertise the kind of roles it has, and receive policy >for each one of its roles. >... > > > > > > > > >Seems to me that you want to differentiate between roles as used to >influence device configuration on the PEP level vs. roles as used to build >policy statements at the PDP level. Is this what you meant by "levels" of >roles? > >If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith >suggested earlier) vs. roles as a selector (to make me happy ;-) ) > > > > >YES YES YES, you hit it bulls eye! I was talking about PEP roles only >and was trying (clumsily) to express myself, thanks! > >So, lets call it "PEP ROLES" > >As for the other one, I believe PDP is merely an interpreter (in comes >abstract policy, out goes device policy) so it doesn't really have >roles. So, we should find another name for the second type that you >described, perhaps "Profile" (as in "user profile, application >profile,...)? or "Usage Roles". > >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 > > > > > __________________________________________________________________ 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 owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 15:04: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 PAA09720 for ; Tue, 8 Feb 2000 15:04:07 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA11906 for snmpconf-outgoing; Tue, 8 Feb 2000 14:45:53 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC504@SOL> From: Andrew Smith To: "'Shai Herzog'" Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com Subject: snmpconf RE: Policy issues: definition of Roles Date: Mon, 7 Feb 2000 15:07:55 -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 Shai, In the worst case then, yes, you're right, the PDP has to multiply out the role combinations and send them all to the PEP. But there will be many cases where the PDP knows that a policy does not need to distinguish between "T1" and "Ethernet": then, the PDP can download a policy for role-combination "Edge". In that case, the ALL in your definition is not applicable. That is what I was trying to explain in my response to Bob Natale last week (1/31). Andrew > From: Shai Herzog [mailto:herzog@iphighway.com] > Sent: Sunday, February 06, 2000 8:48 PM > To: John C. Strassner; Andrew Smith; 'Ken Roberts' > Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'; rap@iphighway.com > Subject: RE: Policy issues: definition of Roles > ... > > 4. PDPs may be smart enough to merge roles (and therefore deal with > individual roles within a role combination). This is actually > an implication of observation (2) but I though it needs to be > clarified. > > For example, in the PDP, lets assume Ethernets get special > treatment (higher precedence rule). > > Role=Edge : If Service=Gold then Mark DSCP=xxx > Role=Ethernet: If Service=Gold then Mark DSCP=yyy > > This will produce the following configuration (using > COPS, or equiv): > > Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy > Role=Edge+T1 : Mark (Traffic Desc) DSCP=xxx > > So, going back to the definition I gave a while back, the reason for > the "ALL" comes from observation 3. > > PDPs can process policy whatever the hell they wish (within reason) > but they have to respond to the PEP with specific policy for each > COMPLETE role combination, and cannot respond to partial role > combination or a specific role which is only a part of a role > combination. From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 15:10:34 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 PAA09853 for ; Tue, 8 Feb 2000 15:10:33 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA12303 for snmpconf-outgoing; Tue, 8 Feb 2000 14:57:04 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208145449.00ab6c60@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 14:56:54 -0500 To: avri.doria@nokia.com, policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com, ipsec-policy@vpnc.org From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_354483590==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_354483590==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:52 PM 02/08/2000, avri.doria@nokia.com wrote: > >So, the role isn't a selector in the schema (although simple schema may > >use it) it is also not a selector at the PDP, but only a selector > >for the PEP to advertise the kind of roles it has, and receive policy > >for each one of its roles. > > >I do not understand why roles are not used at the PDP. >I thought that roles was the way the PDP determined >which policies needed to be applied to the PEPs it was >dealing with. Of course the PDP uses them, but only the way they are created by the PEP. The PDP has two sides to it, one that understands PEP stuff (hence uses Roles) and the other that understands schemas (no roles required). >In fact I was thinking that roles where the main link >between policies and the objects they affected, no matter >were in the architecture this occurs (e.g. at the PDP). Absolutely. See my previous message (sent after you sent this one). I think we are in Sync. Shai >Regards, > >a. >----------------------------------- >avri doria >Office: +1 781 993 4645 >Mobile: +1 781 308 7680 > __________________________________________________________________ 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 --=====================_354483590==_.ALT Content-Type: text/html; charset="us-ascii" At 12:52 PM 02/08/2000, avri.doria@nokia.com wrote:
>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.


I do not understand why roles are not used at the PDP.
I thought that roles was the way the PDP determined
which policies needed to be applied to the PEPs it was
dealing with.

Of course the PDP uses them, but only the way they are created by
the PEP. The PDP has two sides to it, one that understands PEP stuff
(hence uses Roles) and the other that understands schemas (no roles
required).

In fact I was thinking that roles where the main link
between policies and the objects they affected, no matter
were in the architecture this occurs (e.g. at the PDP).

Absolutely. See my previous message (sent after you sent this one).

I think we are in Sync.

Shai

Regards,

a.
-----------------------------------
avri doria
Office: +1 781 993 4645
Mobile: +1 781 308 7680               
 


__________________________________________________________________
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
                                             

        
                                
                             --=====================_354483590==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 15:52:05 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 PAA10865 for ; Tue, 8 Feb 2000 15:52:03 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id PAA13122 for snmpconf-outgoing; Tue, 8 Feb 2000 15:33:08 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208145823.00ab6c60@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 15:32:13 -0500 To: Andrew Smith From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC504@SOL> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_356649234==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_356649234==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:07 PM 02/07/2000, Andrew Smith wrote: >Shai, > >In the worst case then, yes, you're right, the PDP has to multiply out the >role combinations and send them all to the PEP. But there will be many cases >where the PDP knows that a policy does not need to distinguish between "T1" >and "Ethernet": then, the PDP can download a policy for role-combination >"Edge". In that case, the ALL in your definition is not applicable. That is >what I was trying to explain in my response to Bob Natale last week (1/31). I think I am beginning to understand what you mean... ;-) with two Role Combinations "Edge+Ethernet" and "Edge+T1" the PDP normally would send two different configurations such as "Edge+T1": Mark DSCP AF21 "Edge+Ether": Mark DSCP AF11 If it turns out that the instructions for these two are the same (by chance) meaning (Policy1): "Edge+T1": Mark DSCP AF11 "Edge+Ether": Mark DSCP AF11 Then perhaps we'd want to have a wildcard that says (Policy2): "Edge+*": Mark DSCP AF11 BUT, Policy2 is merely a short hand for Policy1 but they mean the same. The important distinction in my view is that the PDP cannot send a policy "T1+*" and expect the PEP to merge the policy in "Edge+*" with "T1+*" into "Edge+T1". So, when receiving a policy for "Edge+*" the PEP interprets it as "Replace/override the policy for all role combinations with Edge in them with the following"... If a "T1+*" comes later, it will REPLACE (not merge) the configuration installed on "Edge+T1". This is why I insist on the "ALL" in the role combination: The PDP must provide a policy that is clearly for a specific COMPLETE role combination, and the PEP isn't expected to merge policy for roles into role combination. BUT as you suggested a shorthand representation may be made for the purpose of saving bits and overhead but that has the same meaning as the "ALL". I am not sure if my description is clear, but I hope ;-) 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 --=====================_356649234==_.ALT Content-Type: text/html; charset="us-ascii" At 03:07 PM 02/07/2000, Andrew Smith wrote:
Shai,

In the worst case then, yes, you're right, the PDP has to multiply out the
role combinations and send them all to the PEP. But there will be many cases
where the PDP knows that a policy does not need to distinguish between "T1"
and "Ethernet": then, the PDP can download a policy for role-combination
"Edge". In that case, the ALL in your definition is not applicable. That is
what I was trying to explain in my response to Bob Natale last week (1/31).

I think I am beginning to understand what you mean... ;-)

with two Role Combinations "Edge+Ethernet" and "Edge+T1" the PDP
normally would send two different configurations such as

"Edge+T1":    Mark DSCP AF21
"Edge+Ether": Mark DSCP AF11

If it turns out that the instructions for these two are the same
(by chance) meaning (Policy1):

"Edge+T1":    Mark DSCP AF11
"Edge+Ether": Mark DSCP AF11

Then perhaps we'd want to have a wildcard that says (Policy2):

"Edge+*":     Mark DSCP AF11

BUT, Policy2 is merely a short hand for Policy1 but they mean the same.
The important distinction in my view is that the PDP cannot send
a policy "T1+*" and expect the PEP to merge the policy
in "Edge+*" with "T1+*" into "Edge+T1".

So, when receiving a policy for "Edge+*" the PEP interprets it
as

"Replace/override the policy for all role combinations with Edge
in them with the following"...

If a "T1+*" comes later, it will REPLACE (not merge) the configuration
installed on "Edge+T1".

This is why I insist on the "ALL" in the role combination: The PDP
must provide a policy that is clearly for a specific COMPLETE
role combination, and the PEP isn't expected to merge policy
for roles into role combination. BUT as you suggested a shorthand
representation may be made for the purpose of saving bits and overhead
but that has the same meaning as the "ALL".

I am not sure if my description is clear, but I hope ;-)

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
                                             

        
                                
                             --=====================_356649234==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 16:54:59 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 QAA12296 for ; Tue, 8 Feb 2000 16:54:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id QAA15436 for snmpconf-outgoing; Tue, 8 Feb 2000 16:38:30 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208162852.00ab6c60@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 16:29:37 -0500 To: James_Binder@3com.com From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com, kjr@nortelnetworks.com, policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: <8825687F.007370B2.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 12:56 PM 02/08/2000, James_Binder@3com.com wrote: And what is T1's responsibility? ;-) (...to deliver data faster than dial-up and slower than T3? ;-) Shai >Maybe we should be thinking terms of "Responsibilities" as well as "Roles". >That is, Edge is "responsible" for packet classification, marking, shapping, >ect.. > >/jsb > > > > > >Shai Herzog on 02/08/2000 11:00:46 AM > >To: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com, > kjr@nortelnetworks.com >cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com, > ipsec-policy@vpnc.org (bcc: James Binder/HQ/3Com) > >Subject: RE: Policy issues: definition of Roles > > > > >Yap. > >It just dawned on me that a roles are "logical interfaces" in the >router, as opposed to "physical interfaces". > >So, in a router with physical interfaces S0..S4, rather than > >SNMP: > >"Configure interface S0 with ....." >"Configure interface S1 with ....." >"Configure interface S2 with ....." >"Configure interface S3 with ....." >"Configure interface S4 with ....." > >The PDP says (using COPS or similar): > >"Configure role "Edge+Serial" with ....." > >And the PEP knows that it has 5 serial physical interfaces with this >role combination and configures S0..S4 with .... > >Shai > >P.S., ...With a note regarding "user profiles" and other attributes >used in the schema, which may overload the term Roles but aren't >related to the PEP roles. I call it user profiles since this >is the terminology used in security, access policies, and many >other areas of networking. > > >At 12:44 PM 02/08/2000, avri.doria@nokia.com wrote: > >So, the role isn't a selector in the schema (although simple schema may > >use it) it is also not a selector at the PDP, but only a selector > >for the PEP to advertise the kind of roles it has, and receive policy > >for each one of its roles. > >... > > > > > > > > > > > > > > > > > >Seems to me that you want to differentiate between roles as used to > >influence device configuration on the PEP level vs. roles as used to build > >policy statements at the PDP level. Is this what you meant by "levels" of > >roles? > > > >If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith > >suggested earlier) vs. roles as a selector (to make me happy ;-) ) > > > > > > > > > >YES YES YES, you hit it bulls eye! I was talking about PEP roles only > >and was trying (clumsily) to express myself, thanks! > > > >So, lets call it "PEP ROLES" > > > >As for the other one, I believe PDP is merely an interpreter (in comes > >abstract policy, out goes device policy) so it doesn't really have > >roles. So, we should find another name for the second type that you > >described, perhaps "Profile" (as in "user profile, application > >profile,...)? or "Usage Roles". > > > >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 > > > > > > > > > > > > >__________________________________________________________________ >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 > > > > > > __________________________________________________________________ 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 owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 16:57:27 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 QAA12356 for ; Tue, 8 Feb 2000 16:57:26 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id QAA15359 for snmpconf-outgoing; Tue, 8 Feb 2000 16:35:49 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38A08B90.FA4B2A3A@cabletron.com> Date: Tue, 08 Feb 2000 16:33:04 -0500 From: David Harrington X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf document task lists Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, There are three initial drafts due for Adelaide - the BCP document, the Capacity and Capabilities MIB document, and a sample configuration mib using diffserv. Over the next day or so, each edit-team will be posting the task list for their document. Each posting will have a subject name of "Tasks - ". These lists are being posted for two reasons: 1) to ensure that the WG at large is aware of the plan of how to get the work done, as agreed between the editors and the chairs. The discussions about the tasks to be done have been held in private email between the editors and chairs for focused expediency. We want to be sure everybody is informed of the plan to complete the deliverables, and has an opportunity to provide input regarding the tasks to be accomplished. 2) to focus subsequent discussion to the appropriate deliverable. Because we have a very aggressive deadline for our first deliverables, any discussion should be focused on the tasks related to one of the three documents. Thanks, Dave Harrington dbh@cabletron From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 19:44:57 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 TAA14120 for ; Tue, 8 Feb 2000 19:44:56 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id TAA19292 for snmpconf-outgoing; Tue, 8 Feb 2000 19:26:06 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f From: Jeff Case Date: Tue, 8 Feb 2000 19:26:02 -0500 (EST) Message-Id: <200002090026.TAA27804@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf RE: Policy issues: definition of Roles Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com shai>The PDP says (using COPS or similar): shai> shai>"Configure role "Edge+Serial" with ....." may i please ask a question? when you read this aloud, do you say edge plus serial...as in math edge or serial ... as in digital logic edge and serial ...as in alta vista search i think you mean "and", but the electrical engineer/hardware background in me says you are saying "or" ... maybe a personality defect of mine regards, jdc From owner-snmpconf@seymour39.SNMP.COM Tue Feb 8 21:42:20 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 VAA15185 for ; Tue, 8 Feb 2000 21:42:19 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id VAA21350 for snmpconf-outgoing; Tue, 8 Feb 2000 21:20:31 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000208211737.00ab6c60@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 08 Feb 2000 21:20:26 -0500 To: snmpconf@snmp.com, snmpconf@snmp.com From: Shai Herzog Subject: Re: snmpconf RE: Policy issues: definition of Roles In-Reply-To: <200002090026.TAA27804@seymour4.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Say "Plus" Mean "and" I guess I am a verbal mathematician but like the view from High Grounds (alta vista ;-) Shai At 07:26 PM 02/08/2000, Jeff Case wrote: >shai>The PDP says (using COPS or similar): >shai> >shai>"Configure role "Edge+Serial" with ....." > >may i please ask a question? > >when you read this aloud, do you say > edge plus serial...as in math > edge or serial ... as in digital logic > edge and serial ...as in alta vista search > >i think you mean "and", but the electrical engineer/hardware background >in me says you are saying "or" ... maybe a personality defect of mine > >regards, >jdc __________________________________________________________________ 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 owner-snmpconf@seymour39.SNMP.COM Wed Feb 9 08:57:14 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 IAA06306 for ; Wed, 9 Feb 2000 08:57:13 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id IAA11649 for snmpconf-outgoing; Wed, 9 Feb 2000 08:37:32 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002091336.IAA21351@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Wed, 09 Feb 2000 08:37:32 -0500 Subject: snmpconf Document Summaries From: "Jon Saperia" To: snmpconf Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit As David Harrington noted yesterday, there will be a number of postings about the tasks planned for each of the three deliverables on the current charter that we are working on. These are: 1. A Best Current Practices Document 2. A MIB Module - the Capabilities and Capacities MIB Module 3. A MIB Module - the Differentiated Services Policy MIB Module Before we start posting individual work items, it might be helpful to give a bit of additional information to that already posted on the charter page found at: http://www.ietf.org/html.charters/snmpconf-charter.html 1. Best Current Practices Document The Best Current Practices Document will be designed to recommend how to best to design, implement and deploy configuration management systems based on the Internet Standard Management Framework (SNMP). Some important goals for this work include the ability to coexist with other management access methods such as a Command Line Interface. For the purposes of this document, configuration management includes what we have historically called device or instance specific configuration data. Examples of this are per instance/interface IP address or subnet information. This document also includes best current practices for realizing what has come to be known as policy (or network-wide) configuration management. The most common example of this type of configuration activity is the expression of Quality of Service policy to managed devices. The other deliverables currently on the working group charter will address MIB Modules which will facilitate policy based management. Another area of the BCP Document is to include how to tie together, fault, configuration and other types of management into an integrated system using the SNMP Framework. Additional details about this document will be published over the next few days. For additional information on the BCP series see the initial document: ftp://ftp.isi.edu/in-notes/bcp/bcp1.txt 2. The Capabilities and Capacities MIB Module In order to effectively perform either device specific, or network wide policy configuration it is necessary to know what capabilities and capacity for performing a particular type of work a device has. This MIB module will be used to convey to management systems the abilities of a device to carry out policy (e.g., deliver a particularly quality of service to IP packets with a specific DSCP value) as well as its capacity for taking on that work. This MIB will also have indices which connect it to MIB Modules which carry policy information and through them MIB Modules which carry related instance specific information. 3. The Differentiated Services Policy MIB Module The focus of the snmpconf WG is not exclusive to differentiated services. A policy MIB for this area is provided partly because it has been a catalyst for interest in policy based management and many people strongly believe in the need to be able to efficiently convey to a managed device this type of configuration information. This module will also be used to show how device specific and policy based configuration can be integrated in a single system through the use of the Capability and Capacity MIB Module, Policy MIB Modules such as the Differentiated Services Policy MIB Module, and other standard modules such as the Differentiated Unlike many other extant MIB Modules, this module will not convey instance specific information but will act as a potential source of information which a managed entity can use to create instance specific information. As such there are likely to be pointers to the Management Information Base for the Differentiated Services Architecture currently under development in the Differentiated Services WG. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Feb 9 11:03:37 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 LAA08827 for ; Wed, 9 Feb 2000 11:03:36 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id KAA15271 for snmpconf-outgoing; Wed, 9 Feb 2000 10:30:35 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002091529.QAA19263@y5m602.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Task list for the Differentiated Services Policy MIB Module From: David Partain X-Mailer: Proudly sent by nmh-1.0.2 X-Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19260.950110196.1@y5m602> Date: Wed, 09 Feb 2000 16:29:56 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id KAA15267 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings, Here is my proposed work schedule for the Differentiated Services Policy MIB Module. I hope this will help begin the discussion. For an overview of the goals, please see Jon's mail with the subject "Document Summaries". Task Complete by ------------------------------------------------------------------------ Determine which PIBs to use as a baseline February 9 (very fast) Determine what additional functions are February 18 (slower) useful/helpful/necessary Define tables and their indices and February 18 relationships - also relationship to Differentiated services MIB in the DiffServ WG. Publish the pre-Adelaide draft February 25 Revise and publish based on input April 14 in Adelaide Revise and publish based on interim May 5 meeting (if that happens) Work with people who can do some (unknown at this time) interoperability test in June Revise again and publish in July July 30 With kind regards, -- David Partain David.Partain@ericsson.com Ericsson Radio Systems AB Tel: +46 13 28 41 44 Research and Innovation Fax: +46 13 28 75 67 P.O. Box 1248 SE-581 12 Linköping, Sweden From owner-snmpconf@seymour39.SNMP.COM Wed Feb 9 11:40: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 LAA09847 for ; Wed, 9 Feb 2000 11:40:50 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id LAA16637 for snmpconf-outgoing; Wed, 9 Feb 2000 11:19:03 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000209074033.00c1b1d0@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 09 Feb 2000 08:18:14 -0800 To: Shai Herzog , "John C. Strassner" , Andrew Smith , "'Ken Roberts'" From: "John C. Strassner" Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76> References: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com> <4.2.0.58.20000206232138.02f037b0@209.3.6.76> <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com> <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3426967==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_3426967==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Comments inline. regards, John At 12:11 PM 2/8/00 -0500, Shai Herzog wrote: >At 08:22 AM 02/08/2000, John C. Strassner wrote: >>Hi Shai, comments inline. >> >>regards, >>John >> >>At 11:48 PM 2/6/00 -0500, Shai Herzog wrote: >>>I think that one of the problems is that we're confusing the >>>various levels of "roles". Let me try to make the following >>>observations: >> >> >>Levels of roles? If a role is indeed an attribute used as a selector, >>this translates to levels of attributes. My head is hurting. ;-) More to >>the point, I don't know what you mean by "levels" of roles... > >Sorry, didn't mean to hurt anyone ;-) >I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our >head, etc.... OK, fine. You're talking about different uses of the term "role". >>I humbly submit that you're making this too complicated. Instead, >>thinking of roles as a means to select from among a larger subset is >>appealing because it always means the same thing each time it is used. >> > >I think the two of us have been discussing this for perhaps years ;-) seems longer ;-) >I believe that the input to the PDP (schema, GUI, whatever) isn't >necessarily mapped 1:1 with PEP configuration (In fact, it better >not be). This means that the PDP may have as input an E-2-E definition >w/o roles ( this user gets gold service (low delay, drop) ) The PDP >gets this non-role info and converts it into COPS commands to >configure the PEP based on roles: > >Role=Edge, DS GOLD Service -> Mark DSCP AF11 > >So, the schema didn't have roles, but roles were used in configuring the >edge router. The schema may have just had policy configuration information and no roles as you suggest, but in this case I wonder how we achieve consistent device configuration? It is the role that is used to define how the edge is to be configured. Therefore, if each PDP defines its own role, you have chaos. On the other hand, if the PDP knows about a certain set of roles, then it can distribute these to other PDPs so that each may consistently configure the set of devices that it controls. >So, the role isn't a selector in the schema (although simple schema may >use it) it is also not a selector at the PDP, but only a selector >for the PEP to advertise the kind of roles it has, and receive policy >for each one of its roles. >... I have no problem with your above example, and is certainly a valid use of roles. However, it is not the only use of roles, right? Equally correct would be to describe the provisioning of the system using roles. There are two obvious examples of using roles as selectors: 1) as a way to select the subset of policies from a large set of policies that are stored in the repository. 2) as a way to retrieve the subset of policies that pertain to a specific set of devices or interfaces The first way assumes that the provisioning of the system is described in terms of roles. This is in contrast to your example, where roles can be used to provision the system. The second uses roles as a selector to retrieve policies for specific devices or device interfaces. This is slightly different than the first. The first describes the behavior of the system. The second describes the capabilities of a device in the form of roles (note that this is NOT the only way, but rather ONE way, that the PEP can do this) so that the PDP can retrieve the policies that affect that device. >> >>Seems to me that you want to differentiate between roles as used to >>influence device configuration on the PEP level vs. roles as used to >>build policy statements at the PDP level. Is this what you meant by >>"levels" of roles? >> >>If so, then I suggest that we talk about PEP roles vs. PDP roles (as >>Keith suggested earlier) vs. roles as a selector (to make me happy ;-) ) >> > >YES YES YES, you hit it bulls eye! I was talking about PEP roles only >and was trying (clumsily) to express myself, thanks! > >So, lets call it "PEP ROLES" > >As for the other one, I believe PDP is merely an interpreter (in comes >abstract policy, out goes device policy) so it doesn't really have >roles. So, we should find another name for the second type that you >described, perhaps "Profile" (as in "user profile, application >profile,...)? or "Usage Roles". Well, we're getting very close here. Let me propose a summary to see if we can agree. Roles have three fundamentally different uses: 1) to directly influence device configuration - let's call this PEP ROLES for now 2) to translate from a high-level description of policy into one that configures the device either directly or indirectly - let's call this PDP ROLES for now 3) to be used as a selector to retrieve a subset of applicable policies from a larger set of available policies - let's call this SELECTOR ROLES for now Note that the second use is subtlely different than the third. The second uses roles as a means to translate between expressing policy in general terms and in configuring the device to implement or support that policy. So in Shai's example, the PDP has two inputs. One input is the definition of the policy from the administrator's point-of-view, which probably can not be used in its current form to configure devices. The other is from the devices that it controls. They announce their capabilities in terms of roles. The PDP then uses roles to translate policy from a business expression (Gold service, or don't allow more than 30% of my core bandwidth to be devoted to a certain type of traffic, or...) to a form that is used to ultimately configure the devices that it controls. The third use is not focused on translation. Rather, it is a way of selecting policies and/or policy information to be retrieved for further processing. >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 --=====================_3426967==_.ALT Content-Type: text/html; charset="us-ascii" Comments inline.

regards,
John

At 12:11 PM 2/8/00 -0500, Shai Herzog wrote:
At 08:22 AM 02/08/2000, John C. Strassner wrote:
Hi Shai, comments inline.

regards,
John

At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
I think that one of the problems is that we're confusing the
various levels of "roles". Let me try to make the following
observations:

<js>
Levels of roles? If a role is indeed an attribute used as a selector, this translates to levels of attributes. My head is hurting. ;-) More to the point, I don't know what you mean by "levels" of roles...

Sorry, didn't mean to hurt anyone ;-)
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our
head, etc....

<js> OK, fine. You're talking about different uses of the term "role". </js>


I humbly submit that you're making this too complicated. Instead, thinking of roles as a means to select from among a larger subset is appealing because it always means the same thing each time it is used.
</js>

I think the two of us have been discussing this for perhaps years ;-)

<js> seems longer ;-) </js>

I believe that the input to the PDP (schema, GUI, whatever) isn't
necessarily mapped 1:1 with PEP configuration (In fact, it better
not be). This means that the PDP may have as input an E-2-E definition
w/o roles ( this user gets gold service (low delay, drop) ) The PDP
gets this non-role info and converts it into COPS commands to
configure the PEP based on roles:

Role=Edge, DS GOLD Service -> Mark DSCP AF11

So, the schema didn't have roles, but roles were used in configuring the
edge router.

<js>
The schema may have just had policy configuration information and no roles as you suggest, but in this case I wonder how we achieve consistent device configuration? It is the role that is used to define how the edge is to be configured. Therefore, if each PDP defines its own role, you have chaos. On the other hand, if the PDP knows about a certain set of roles, then it can distribute these to other PDPs so that each may consistently configure the set of devices that it controls.
</js>

So, the role isn't a selector in the schema (although simple schema may
use it) it is also not a selector at the PDP, but only a selector
for the PEP to advertise the kind of roles it has, and receive policy
for each one of its roles.
...

<js>
I have no problem with your above example, and is certainly a valid use of roles. However, it is not the only use of roles, right? Equally correct would be to describe the provisioning of the system using roles. There are two obvious examples of using roles as selectors:

  1) as a way to select the subset of policies from a large
     set of policies that are stored in the repository.
  2) as a way to retrieve the subset of policies that pertain
     to a specific set of devices or interfaces

The first way assumes that the provisioning of the system is described in terms of roles. This is in contrast to your example, where roles can be used to provision the system. The second uses roles as a selector to retrieve policies for specific devices or device interfaces. This is slightly different than the first. The first describes the behavior of the system. The second describes the capabilities of a device in the form of roles (note that this is NOT the only way, but rather ONE way, that the PEP can do this) so that the PDP can retrieve the policies that affect that device.
</js>


<js>
Seems to me that you want to differentiate between roles as used to influence device configuration on the PEP level vs. roles as used to build policy statements at the PDP level. Is this what you meant by "levels" of roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>

YES YES YES, you hit it bulls eye! I was talking about PEP roles only
and was trying (clumsily) to express myself, thanks!

So, lets call it "PEP ROLES"

As for the other one, I believe PDP is merely an interpreter (in comes
abstract policy, out goes device policy) so it doesn't really have
roles. So, we should find another name for the second type that you
described, perhaps "Profile" (as in "user profile, application
profile,...)? or "Usage Roles".

<js>
Well, we're getting very close here. Let me propose a summary to see if we can agree. Roles have three fundamentally different uses:

  1) to directly influence device configuration - let's
     call this PEP ROLES for now
  2) to translate from a high-level description of policy
     into one that configures the device either directly
     or indirectly - let's call this PDP ROLES for now
  3) to be used as a selector to retrieve a subset of
     applicable policies from a larger set of available
     policies - let's call this SELECTOR ROLES for now

Note that the second use is subtlely different than the third. The second uses roles as a means to translate between expressing policy in general terms and in configuring the device to implement or support that policy. So in Shai's example, the PDP has two inputs. One input is the definition of the policy from the administrator's point-of-view, which probably can not be used in its current form to configure devices. The other is from the devices that it controls. They announce their capabilities in terms of roles. The PDP then uses roles to translate policy from a business expression (Gold service, or don't allow more than 30% of my core bandwidth to be devoted to a certain type of traffic, or...) to a form that is used to ultimately configure the devices that it controls.

The third use is not focused on translation. Rather, it is a way of selecting policies and/or policy information to be retrieved for further processing.
</js>
 
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
--=====================_3426967==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Wed Feb 9 14:31:29 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 OAA19103 for ; Wed, 9 Feb 2000 14:31:25 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA21698 for snmpconf-outgoing; Wed, 9 Feb 2000 14:02:49 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000209093146.00b7ae70@omega.cisco.com> X-Sender: jstrassn@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 09 Feb 2000 09:56:47 -0800 To: avri.doria@nokia.com, herzog@iphighway.com, jstrassn@cisco.com, andrew@extremenetworks.com, kjr@nortelnetworks.com From: "John C. Strassner" Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Hi Avri, please see my last response. Roles have three fundamentally different uses. One is as a selector of policy, independent of whether the PDP or the PEP is involved. A second is as a translation between different forms of policy (e.g., a high-level business specification vs. a low-level device configuration specification). A third is to be able to directly influence device configuration. At 12:44 PM 2/8/00 -0600, avri.doria@nokia.com wrote: >So, the role isn't a selector in the schema (although simple schema may >use it) it is also not a selector at the PDP, but only a selector >for the PEP to advertise the kind of roles it has, and receive policy >for each one of its roles. >... > > > > > > > > >Seems to me that you want to differentiate between roles as used to >influence device configuration on the PEP level vs. roles as used to build >policy statements at the PDP level. Is this what you meant by "levels" of >roles? > >If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith >suggested earlier) vs. roles as a selector (to make me happy ;-) ) > > > > >YES YES YES, you hit it bulls eye! I was talking about PEP roles only >and was trying (clumsily) to express myself, thanks! > >So, lets call it "PEP ROLES" > >As for the other one, I believe PDP is merely an interpreter (in comes >abstract policy, out goes device policy) so it doesn't really have >roles. So, we should find another name for the second type that you >described, perhaps "Profile" (as in "user profile, application >profile,...)? or "Usage Roles". > >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 owner-snmpconf@seymour39.SNMP.COM Wed Feb 9 20:16:04 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 UAA29044 for ; Wed, 9 Feb 2000 20:15:59 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id TAA02018 for snmpconf-outgoing; Wed, 9 Feb 2000 19:57:11 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <010101bf737b$103a6fa0$f25c8d86@ctron.com> From: "Thippann Hongal" To: "David Harrington" , "Jon Saperia" , Cc: "Steve Waldbusser" , "Szabolcs Boros" , "David Partain" , , "Aiko Pras" , "Harrie Hazewinkel" , "Mike MacFaden" Subject: snmpconf Tasks - "Capabilities and Capacities MIB" Date: Wed, 9 Feb 2000 19:57:50 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01BF7337.F1A0B560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. ------=_NextPart_000_00FE_01BF7337.F1A0B560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Capabilities and Capacities MIB Task List Complete = by -------------------------------------------------------------------------= ----------------------------- 1. Write a draft with good introductory material = February 22 Define Tables and their indices and relationships 2. Publish the pre-adelaide draft = February 27 =20 3. Revise and publish based on input in Adelaide April 20 4. Revise and publish based on interim May 5 meeting =20 5. Work with people who can do some June 15 interoperability test =20 6. Revise again and publish in July July = 30=20 thanks Thippanna Hongal ------=_NextPart_000_00FE_01BF7337.F1A0B560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Capabilities and Capacities MIB Task=20 List           &nb= sp;          =20 Complete by
----------------------------------------------------------------= --------------------------------------
1. Write a draft with good introductory = material           = ;     =20 February 22
   Define Tables = and their indices and relationships
 
2. Publish the pre-adelaide=20 draft           &n= bsp;           &nb= sp;           &nbs= p;  February=20 27
          &nbs= p;=20
3. Revise and publish based on input in = Adelaide           = ;  =20 April 20
 
4. Revise and publish based on interim = =20             =     May=20 5
    meeting 
 
5. Work with people who can do some = =20             June = 15
    interoperability = test  =20
 
6. Revise again and publish in July = =20             =    =20   July 30
 
thanks
Thippanna = Hongal
------=_NextPart_000_00FE_01BF7337.F1A0B560-- From owner-snmpconf@seymour39.SNMP.COM Fri Feb 11 09:23:47 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 JAA09532 for ; Fri, 11 Feb 2000 09:23:38 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id JAA04401 for snmpconf-outgoing; Fri, 11 Feb 2000 09:07:46 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000211090103.02de3f10@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 11 Feb 2000 09:05:23 -0500 To: "John C. Strassner" , "John C. Strassner" , Andrew Smith , "'Ken Roberts'" From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" , rap@iphighway.com, ipsec-policy@vpnc.org In-Reply-To: <4.2.0.58.20000209074033.00c1b1d0@omega.cisco.com> References: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76> <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com> <4.2.0.58.20000206232138.02f037b0@209.3.6.76> <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com> <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_592727597==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_592727597==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:18 AM 02/09/2000, John C. Strassner wrote: > >Well, we're getting very close here. Let me propose a summary to see if we >can agree. Roles have three fundamentally different uses: > > 1) to directly influence device configuration - let's > call this PEP ROLES for now > 2) to translate from a high-level description of policy > into one that configures the device either directly > or indirectly - let's call this PDP ROLES for now > 3) to be used as a selector to retrieve a subset of > applicable policies from a larger set of available > policies - let's call this SELECTOR ROLES for now > >Note that the second use is subtlely different than the third. The second >uses roles as a means to translate between expressing policy in general >terms and in configuring the device to implement or support that policy. >So in Shai's example, the PDP has two inputs. One input is the definition >of the policy from the administrator's point-of-view, which probably can >not be used in its current form to configure devices. The other is from >the devices that it controls. They announce their capabilities in terms of >roles. The PDP then uses roles to translate policy from a business >expression (Gold service, or don't allow more than 30% of my core >bandwidth to be devoted to a certain type of traffic, or...) to a form >that is used to ultimately configure the devices that it controls. > >The third use is not focused on translation. Rather, it is a way of >selecting policies and/or policy information to be retrieved for further >processing. The #1 is agreed upon, but I fail to see the #2 & #3 being separate and I have a hard time with "PDP" roles given that PDP is a translation machine and doe not have its own definition or determination of policy (or roles for that matter). It takes two types of input, one from above (schema) and one from bellow (device). Those inputs may have roles in them, but those are different "role types". PEP Roles <-----------> PDP <---------------> Schema Roles The job of the PDP is to bridge between PEPs and Schema, but it doesn't have roles or policy per se. 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 --=====================_592727597==_.ALT Content-Type: text/html; charset="us-ascii" At 08:18 AM 02/09/2000, John C. Strassner wrote:

<js>
Well, we're getting very close here. Let me propose a summary to see if we can agree. Roles have three fundamentally different uses:

  1) to directly influence device configuration - let's
     call this PEP ROLES for now
  2) to translate from a high-level description of policy
     into one that configures the device either directly
     or indirectly - let's call this PDP ROLES for now
  3) to be used as a selector to retrieve a subset of
     applicable policies from a larger set of available
     policies - let's call this SELECTOR ROLES for now

Note that the second use is subtlely different than the third. The second uses roles as a means to translate between expressing policy in general terms and in configuring the device to implement or support that policy. So in Shai's example, the PDP has two inputs. One input is the definition of the policy from the administrator's point-of-view, which probably can not be used in its current form to configure devices. The other is from the devices that it controls. They announce their capabilities in terms of roles. The PDP then uses roles to translate policy from a business expression (Gold service, or don't allow more than 30% of my core bandwidth to be devoted to a certain type of traffic, or...) to a form that is used to ultimately configure the devices that it controls.

The third use is not focused on translation. Rather, it is a way of selecting policies and/or policy information to be retrieved for further processing.

The #1 is agreed upon, but I fail to see the #2 & #3 being separate
and I have a hard time with "PDP" roles given that PDP is a translation
machine and doe not have its own definition or determination of policy
(or roles for that matter). It takes two types of input, one from above
(schema) and one from bellow (device). Those inputs may have roles in
them, but those are different "role types".


PEP Roles <-----------> PDP <---------------> Schema Roles

The job of the PDP is to bridge between PEPs and Schema, but it doesn't
have roles or policy per se.

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
                                             

        
                                
                             --=====================_592727597==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Fri Feb 11 09:38:32 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 JAA09531 for ; Fri, 11 Feb 2000 09:23:37 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id JAA04402 for snmpconf-outgoing; Fri, 11 Feb 2000 09:07:47 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <4.2.0.58.20000211085610.02facc10@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 11 Feb 2000 08:58:51 -0500 To: "Jon Sjoberg" , "Andrew Smith" From: Shai Herzog Subject: snmpconf RE: Policy issues: definition of Roles Cc: , , In-Reply-To: References: <4.2.0.58.20000208145823.00ab6c60@209.3.6.76> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_592727537==_.ALT" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --=====================_592727537==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:59 AM 02/09/2000, Jon Sjoberg wrote: >Shai, > >Correct me if I'm wrong, but I read the below to say that the "ALL" in >your definition means that all the roles in a role combination associated >to a policy must be a proper subset of the roles on a PEP for the policy >to be loaded. > >So, for your example: > >If I had a QoS policy P1 associated with the combination "Edge+Ethernet", >and a PEP that supported the roles >"Edge+Ethernet+TrustedInterface+Engineering", then P1 would be appropriate >for that PEP. Correct? > >In this case, a security policy, P2, for all TrustedInterface PEPs would >be merged with P1. Correct? This is too vague, what do you mean by "associated" so you mean that it is sent to the PEP with the role "Edge+Ethernet", or do you mean that it is associated in the policy DB? I must understand the level your talking about. > What I'm also understanding that may be wrong is that this position > further holds that the association between Edge+Ethernet and P1 is not > stored in the schema but the PDP comes up with this out of some learned > or intrinsic network knowledge (proprietary). What is stored in the > schema, and associated with a policy in the schema, is some set of > identifiers as to the general functionality that a policy pertains to > (Configuration, QoS, Security, etc.). > >Am I close? > >Jon >>-----Original Message----- >>From: policy-owner@raleigh.ibm.com >>[mailto:policy-owner@raleigh.ibm.com]On Behalf Of Shai Herzog >>Sent: Tuesday, February 08, 2000 12:32 PM >>To: Andrew Smith >>Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'; rap@iphighway.com >>Subject: RE: Policy issues: definition of Roles >> >>At 03:07 PM 02/07/2000, Andrew Smith wrote: >>>Shai, >>> >>>In the worst case then, yes, you're right, the PDP has to multiply out the >>>role combinations and send them all to the PEP. But there will be many cases >>>where the PDP knows that a policy does not need to distinguish between "T1" >>>and "Ethernet": then, the PDP can download a policy for role-combination >>>"Edge". In that case, the ALL in your definition is not applicable. That is >>>what I was trying to explain in my response to Bob Natale last week (1/31). >> >>I think I am beginning to understand what you mean... ;-) >> >>with two Role Combinations "Edge+Ethernet" and "Edge+T1" the PDP >>normally would send two different configurations such as >> >>"Edge+T1": Mark DSCP AF21 >>"Edge+Ether": Mark DSCP AF11 >> >>If it turns out that the instructions for these two are the same >>(by chance) meaning (Policy1): >> >>"Edge+T1": Mark DSCP AF11 >>"Edge+Ether": Mark DSCP AF11 >> >>Then perhaps we'd want to have a wildcard that says (Policy2): >> >>"Edge+*": Mark DSCP AF11 >> >>BUT, Policy2 is merely a short hand for Policy1 but they mean the same. >>The important distinction in my view is that the PDP cannot send >>a policy "T1+*" and expect the PEP to merge the policy >>in "Edge+*" with "T1+*" into "Edge+T1". >> >>So, when receiving a policy for "Edge+*" the PEP interprets it >>as >> >>"Replace/override the policy for all role combinations with Edge >>in them with the following"... >> >>If a "T1+*" comes later, it will REPLACE (not merge) the configuration >>installed on "Edge+T1". >> >>This is why I insist on the "ALL" in the role combination: The PDP >>must provide a policy that is clearly for a specific COMPLETE >>role combination, and the PEP isn't expected to merge policy >>for roles into role combination. BUT as you suggested a shorthand >>representation may be made for the purpose of saving bits and overhead >>but that has the same meaning as the "ALL". >> >>I am not sure if my description is clear, but I hope ;-) >> >>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 >> >> >> >> >> __________________________________________________________________ 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 --=====================_592727537==_.ALT Content-Type: text/html; charset="us-ascii" At 05:59 AM 02/09/2000, Jon Sjoberg wrote:
Shai,
 
Correct me if I'm wrong, but I read the below to say that the "ALL" in your definition means that all the roles in a role combination associated to a policy must be a proper subset of the roles on a PEP for the policy to be loaded.
 
So, for your example:
 
If I had a QoS policy P1 associated with the combination "Edge+Ethernet", and a PEP that supported the roles "Edge+Ethernet+TrustedInterface+Engineering", then P1 would be appropriate for that PEP.  Correct?
 
In this case, a security policy, P2, for all TrustedInterface PEPs would be merged with P1.  Correct?

This is too vague, what do you mean by "associated" so you mean that
it is sent to the PEP with the role "Edge+Ethernet", or do you
mean that it is associated in the policy DB? I must understand the
level your talking about.

 What I'm also understanding that may be wrong is that this position further holds that the association between Edge+Ethernet and P1 is not stored in the schema but the PDP comes up with this out of some learned or intrinsic network knowledge (proprietary).  What is stored in the schema, and associated with a policy in the schema, is some set of identifiers as to the general functionality that a policy pertains to (Configuration, QoS, Security, etc.).
 
Am I close?
 
Jon
-----Original Message-----
From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Shai Herzog
Sent: Tuesday, February 08, 2000 12:32 PM
To: Andrew Smith
Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'; rap@iphighway.com
Subject: RE: Policy issues: definition of Roles

At 03:07 PM 02/07/2000, Andrew Smith wrote:
Shai,

In the worst case then, yes, you're right, the PDP has to multiply out the
role combinations and send them all to the PEP. But there will be many cases
where the PDP knows that a policy does not need to distinguish between "T1"
and "Ethernet": then, the PDP can download a policy for role-combination
"Edge". In that case, the ALL in your definition is not applicable. That is
what I was trying to explain in my response to Bob Natale last week (1/31).

I think I am beginning to understand what you mean... ;-)

with two Role Combinations "Edge+Ethernet" and "Edge+T1" the PDP
normally would send two different configurations such as

"Edge+T1":    Mark DSCP AF21
"Edge+Ether": Mark DSCP AF11

If it turns out that the instructions for these two are the same
(by chance) meaning (Policy1):

"Edge+T1":    Mark DSCP AF11
"Edge+Ether": Mark DSCP AF11

Then perhaps we'd want to have a wildcard that says (Policy2):

"Edge+*":     Mark DSCP AF11

BUT, Policy2 is merely a short hand for Policy1 but they mean the same.
The important distinction in my view is that the PDP cannot send
a policy "T1+*" and expect the PEP to merge the policy
in "Edge+*" with "T1+*" into "Edge+T1".

So, when receiving a policy for "Edge+*" the PEP interprets it
as

"Replace/override the policy for all role combinations with Edge
in them with the following"...

If a "T1+*" comes later, it will REPLACE (not merge) the configuration
installed on "Edge+T1".

This is why I insist on the "ALL" in the role combination: The PDP
must provide a policy that is clearly for a specific COMPLETE
role combination, and the PEP isn't expected to merge policy
for roles into role combination. BUT as you suggested a shorthand
representation may be made for the purpose of saving bits and overhead
but that has the same meaning as the "ALL".

I am not sure if my description is clear, but I hope ;-)

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
                                             

        
                                
                            


__________________________________________________________________
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
                                             

        
                                
                             --=====================_592727537==_.ALT-- From owner-snmpconf@seymour39.SNMP.COM Sat Feb 12 17:59:24 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 RAA27428 for ; Sat, 12 Feb 2000 17:59:24 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id RAA19192 for snmpconf-outgoing; Sat, 12 Feb 2000 17:42:09 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f From: "Michael MacFaden" To: "SNMPCONF List" Subject: Tasks - draft-ietf-snmpconf-bcp.txt Date: Sat, 12 Feb 2000 14:42:44 -0800 Message-ID: <001101bf75aa$7a809340$90ae8d86@bilbo.yagosys.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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the proposed agenda for the best common practices (BCP) document. Comments to the list welcome. Capabilities and Capacities MIB Task List / Complete by 1. Discuss on the working group list what experience has shown to be the Best common Practices for Configuration / Mar5 using snmpv1 and v3. 2. Publish the pre-Adelaide draft / Mar 10 3. Revise and publish bcp based on Adelaide discussions / April 20 4. Revise and publish bcp based on interim meeting discussion / May 5 5. Work with people who can validate BCP design guidelines / June 15 6. Final revisions to bcp & publish / July 30 Regards, Mike MacFaden Riverstone Networks Inc. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.2 iQA/AwUBOKXh0GcXXy72LDDlEQI3CACg+yJJrtJsMP2iuhfcM0Z4lkKne3gAn1LK MuFviBZHy1mxb2XhjyxRbrYe =cKpS -----END PGP SIGNATURE----- From owner-snmpconf@seymour39.SNMP.COM Wed Feb 16 12:14: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 MAA06737 for ; Wed, 16 Feb 2000 12:14:05 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id LAA06923 for snmpconf-outgoing; Wed, 16 Feb 2000 11:53:27 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38AAD572.E07BBB90@cabletron.com> Date: Wed, 16 Feb 2000 11:50:58 -0500 From: David Harrington X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf interim meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, My employer, Enterasys (a subsidiary of Cabletron) will sponsor the interim meeting. We need to establish the dates and the support requirements. Please make any recommendations for support requirements. I will plan on: a conference room for 3 days for 12 people. lunch, snacks, beverages provided. power strips for laptops. overhead projector for transparencies laptop projector thing I can't remember the name of. teleconference phone Unless there is a need, I will NOT request internet access hub for interconnecting our laptops printer access videoconference capabilities I will have access to the corporate network, and thus to printers and the internet via my computer. I will see if we can arrange special rates at a local hotel. dbh From owner-snmpconf@seymour39.SNMP.COM Wed Feb 16 15:17:00 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 PAA12246 for ; Wed, 16 Feb 2000 15:16:53 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA11644 for snmpconf-outgoing; Wed, 16 Feb 2000 14:55:18 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Date: Wed, 16 Feb 2000 11:54:02 -0800 (PST) From: Randy Presuhn Message-Id: <200002161954.LAA29606@dorothy.peer.com> To: snmpconf@snmp.com Subject: Re: snmpconf interim meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi - > Message-ID: <38AAD572.E07BBB90@cabletron.com> > Date: Wed, 16 Feb 2000 11:50:58 -0500 > From: David Harrington > To: "snmpconf@snmp.com" > Subject: snmpconf interim meeting ... > I will see if we can arrange special rates at a local hotel. ... Local = Adelaide? ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Wed Feb 16 16:17:29 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 QAA14127 for ; Wed, 16 Feb 2000 16:17:22 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id PAA13136 for snmpconf-outgoing; Wed, 16 Feb 2000 15:59:12 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38AB0EDC.60386CF7@cabletron.com> Date: Wed, 16 Feb 2000 15:55:56 -0500 From: David Harrington X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf interim meeting References: <200002161954.LAA29606@dorothy.peer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi Randy, The meeting is an editors' meeting (hence only 12 people). I sent the notice to the public list by mistake. dbh Randy Presuhn wrote: > > Hi - > > > Message-ID: <38AAD572.E07BBB90@cabletron.com> > > Date: Wed, 16 Feb 2000 11:50:58 -0500 > > From: David Harrington > > To: "snmpconf@snmp.com" > > Subject: snmpconf interim meeting > ... > > I will see if we can arrange special rates at a local hotel. > ... > > Local = Adelaide? > > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Thu Feb 17 03:34:26 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 DAA07708 for ; Thu, 17 Feb 2000 03:34:24 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id DAA06199 for snmpconf-outgoing; Thu, 17 Feb 2000 03:19:31 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Date: Thu, 17 Feb 2000 09:18:38 +0100 Message-Id: <200002170818.JAA17108@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <38AB0EDC.60386CF7@cabletron.com> (message from David Harrington on Wed, 16 Feb 2000 15:55:56 -0500) Subject: Re: snmpconf interim meeting References: <200002161954.LAA29606@dorothy.peer.com> <38AB0EDC.60386CF7@cabletron.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> David Harrington writes: David> The meeting is an editors' meeting (hence only 12 people). I David> sent the notice to the public list by mistake. So who are these editors? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Feb 18 10:17:44 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 KAA24856 for ; Fri, 18 Feb 2000 10:17:40 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id JAA10207 for snmpconf-outgoing; Fri, 18 Feb 2000 09:55:27 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002181454.JAA07597@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Fri, 18 Feb 2000 09:55:50 -0500 Subject: Re: snmpconf interim meeting From: "Jon Saperia" To: snmpconf@snmp.com CC: saperia@mediaone.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > > > So who are these editors? > > /js Juergen, There are 3 teams, each working on 1 of the documents we described on the list the other week. They are: BCP Document: Mike MacFaden Jon Saperia Jeff Case Configuration and Capacity MIB Module Steve Waldbusser Thippanna Hongal Jon Saperia Carl Kalbfleish Differentiated Services Policy MIB Module David Partain Aiko Pras Harrie Hazewinkel Szabolcs Boros /jon From owner-snmpconf@seymour39.SNMP.COM Fri Feb 18 10:48:25 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 KAA25429 for ; Fri, 18 Feb 2000 10:48:23 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id KAA11370 for snmpconf-outgoing; Fri, 18 Feb 2000 10:27:12 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38AD64F9.1B769EDA@cisco.com> Date: Fri, 18 Feb 2000 07:27:53 -0800 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf interim meeting References: <200002161954.LAA29606@dorothy.peer.com> <38AB0EDC.60386CF7@cabletron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit David Harrington wrote: > > Hi Randy, > > The meeting is an editors' meeting (hence only 12 people). > I sent the notice to the public list by mistake. > The meeting was also called a WG interim meeting by mistake. You meant to say it was an Editors Workshop meeting -- for the purpose of furthering work on individual submissions to a new WG. You didn't mean to imply that a new WG was starting out of the gate with an invitation-only meeting, for the purpose of handing the WG a set of baseline drafts. Right? > dbh Andy > > Randy Presuhn wrote: > > > > Hi - > > > > > Message-ID: <38AAD572.E07BBB90@cabletron.com> > > > Date: Wed, 16 Feb 2000 11:50:58 -0500 > > > From: David Harrington > > > To: "snmpconf@snmp.com" > > > Subject: snmpconf interim meeting > > ... > > > I will see if we can arrange special rates at a local hotel. > > ... > > > > Local = Adelaide? > > > > ------------------------------------------------------------------------ > > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > > Fax: +1 408 965-0359 San Jose, California 95131 USA > > ------------------------------------------------------------------------ > > Any relationship between my opinions and BMC's should be coincidental. > > ------------------------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Fri Feb 18 13:11: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 NAA28491 for ; Fri, 18 Feb 2000 13:11:57 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id MAA17342 for snmpconf-outgoing; Fri, 18 Feb 2000 12:54:05 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-ID: <38AD7DA3.AD6E15D5@cabletron.com> Date: Fri, 18 Feb 2000 12:13:07 -0500 From: David Harrington Organization: Cabletron Systems Inc X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf interim meeting References: <200002161954.LAA29606@dorothy.peer.com> <38AB0EDC.60386CF7@cabletron.com> <38AD64F9.1B769EDA@cisco.com> Content-Type: multipart/mixed; boundary="------------5209809F74A0B4ABAFCA88AB" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------5209809F74A0B4ABAFCA88AB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I couldn't have said it better. Thanks, dbh Andy Bierman wrote: > > David Harrington wrote: > > > > Hi Randy, > > > > The meeting is an editors' meeting (hence only 12 people). > > I sent the notice to the public list by mistake. > > > > The meeting was also called a WG interim meeting by mistake. > You meant to say it was an Editors Workshop meeting -- for the > purpose of furthering work on individual submissions to a > new WG. > > You didn't mean to imply that a new WG was starting out of the > gate with an invitation-only meeting, for the purpose of handing > the WG a set of baseline drafts. > > Right? > > > dbh > > Andy > > > > > Randy Presuhn wrote: > > > > > > Hi - > > > > > > > Message-ID: <38AAD572.E07BBB90@cabletron.com> > > > > Date: Wed, 16 Feb 2000 11:50:58 -0500 > > > > From: David Harrington > > > > To: "snmpconf@snmp.com" > > > > Subject: snmpconf interim meeting > > > ... > > > > I will see if we can arrange special rates at a local hotel. > > > ... > > > > > > Local = Adelaide? > > > > > > ------------------------------------------------------------------------ > > > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > > > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > > > Fax: +1 408 965-0359 San Jose, California 95131 USA > > > ------------------------------------------------------------------------ > > > Any relationship between my opinions and BMC's should be coincidental. > > > ------------------------------------------------------------------------ -- David Harrington Spectrum for Smart Networking dbh@cabletron.com Cabletron Systems Inc. --------------5209809F74A0B4ABAFCA88AB Content-Type: text/x-vcard; charset=us-ascii; name="dbh.vcf" Content-Description: Card for David Harrington Content-Disposition: attachment; filename="dbh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Harrington;David x-mozilla-html:FALSE org:Cabletron Systems Inc adr:;;35 Industrial Way;Rochester;NH;03867;USA version:2.1 email;internet:dbh@cabletron.com tel;fax:603-337-7370 tel;work:603-337-7357 x-mozilla-cpt:;0 fn:Harrington, David end:vcard --------------5209809F74A0B4ABAFCA88AB-- From owner-snmpconf@seymour39.SNMP.COM Fri Feb 18 14:49:14 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 OAA00134 for ; Fri, 18 Feb 2000 14:49:14 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id OAA20114 for snmpconf-outgoing; Fri, 18 Feb 2000 14:30:29 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Date: Fri, 18 Feb 2000 11:29:12 -0800 (PST) From: Randy Presuhn Message-Id: <200002181929.LAA25633@dorothy.peer.com> To: snmpconf@snmp.com Subject: Re: snmpconf interim meeting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi - > Message-ID: <38AD7DA3.AD6E15D5@cabletron.com> > Date: Fri, 18 Feb 2000 12:13:07 -0500 > From: David Harrington > To: snmpconf@snmp.com > Subject: Re: snmpconf interim meeting > References: <200002161954.LAA29606@dorothy.peer.com> <38AB0EDC.60386CF7@cabletron.com> <38AD64F9.1B769EDA@cisco.com> ... > I couldn't have said it better. ... > > The meeting was also called a WG interim meeting by mistake. > > You meant to say it was an Editors Workshop meeting -- for the > > purpose of furthering work on individual submissions to a > > new WG. ... Presumably to avoid running afoul of RFC 2148 clause 3.1 paragraph 3 by putting it under the purview of clause 6.5. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-snmpconf@seymour39.SNMP.COM Fri Feb 18 17:43:51 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 RAA03421 for ; Fri, 18 Feb 2000 17:43:50 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id RAA25310 for snmpconf-outgoing; Fri, 18 Feb 2000 17:22:55 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002182222.RAA18344@aix43.snmp.com> to: snmpconf@snmp.com Subject: http archive at http://www.escribe.com/computing/snmpconf Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 18 Feb 2000 17:22:52 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit In response to several requests for a searchable http archive of the snmpconf mailing list, this list is now being archived at http://www.escribe.com/computing/snmpconf. All submissions must still take place through snmpconf@majordomo.snmp.com. --- 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 To subscribe, send "subscribe snmpconf" to snmpconf-request@majordomo.snmp.com To unsubscribe, send "unsubscribe snmpconf" to the same address. From owner-snmpconf@seymour39.SNMP.COM Mon Feb 21 08:18:39 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 IAA05815 for ; Mon, 21 Feb 2000 08:18:38 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id HAA15920 for snmpconf-outgoing; Mon, 21 Feb 2000 07:57:43 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002211257.HAA148000@northrelay03.pok.ibm.com> Date: Mon, 21 Feb 00 13:57:32 CET From: "Bert Wijnen" To: snmpconf@snmp.com cc: saperia@mediaone.net, dbh@cabletron.com, randy@psg.com Subject: http archive at http://www.escribe.com/computing/snmpconf Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Ref: Your note of Fri, 18 Feb 2000 17:22:52 -0500 Subject: Re: http archive at http://www.escribe.com/computing/snmpconf Steve, is this in addition to the old archive, or does it replace the old archive. If the latter, then we need to inform Steve Coya, so he can update the charter page. Bert From owner-snmpconf@seymour39.SNMP.COM Mon Feb 21 08:19:59 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 IAA05851 for ; Mon, 21 Feb 2000 08:19:58 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id IAA16094 for snmpconf-outgoing; Mon, 21 Feb 2000 08:03:34 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002211302.IAA40392@southrelay03.raleigh.ibm.com> Date: Mon, 21 Feb 00 14:02:58 CET From: "Bert Wijnen" To: snmpconf@snmp.com, saperia@mediaone.net cc: randy@psg.com Subject: snmpconf interim meeting Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Ref: Your note of Wed, 16 Feb 2000 11:50:58 -0500 Subject: Re: snmpconf interim meeting Mmm... too bad you posted it to WG list and mis-named it. But at the other hand, it is good if the other WG members know that the meeting is taking place. You could actually sollicit input that people may have. I am checking with Randy if there are any issues. Bert From owner-snmpconf@seymour39.SNMP.COM Mon Feb 21 09:00:07 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 JAA07137 for ; Mon, 21 Feb 2000 09:00:06 -0500 (EST) Received: by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id IAA16963 for snmpconf-outgoing; Mon, 21 Feb 2000 08:42:43 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002211342.IAA03118@aix43.snmp.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: snmpconf@snmp.com Subject: Re: http archive at http://www.escribe.com/computing/snmpconf In-reply-to: Your message of Mon, 21 Feb 2000 13:57:32 +0700. <200002211257.HAA148000@northrelay03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 21 Feb 2000 08:42:40 -0500 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Good Morning, Bert, This is in addition to the majordomo archive. This is not intended to be any sort of official archive, merely a tool to allow folks to do http-based browses. The majordomo-based archive will continue to be maintained. I don't think any update to the charter page is necessary. If you think it would be helpful, I will post a clarification to that effect. If I had my preference, I would have set up the software to do it here (at SNMP Research) so people would not be annoyed by the banner ads that pay for the service. Unfortunately, there are only so many hours in the day, and there was not a large number of people requesting it. - Steve On Monday, February 21 2000, "Bert Wijnen" wrote: > Ref: Your note of Fri, 18 Feb 2000 17:22:52 -0500 > > Subject: Re: http archive at http://www.escribe.com/computing/snmpconf > > Steve, is this in addition to the old archive, or does it replace > the old archive. If the latter, then we need to inform Steve Coya, > so he can update the charter page. > > Bert --- 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 Feb 21 09:07:38 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 JAA07454 for ; Mon, 21 Feb 2000 09:07:36 -0500 (EST) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) id IAA17346 for snmpconf-outgoing; Mon, 21 Feb 2000 08:51:19 -0500 (EST) X-Authentication-Warning: seymour39.SNMP.COM: majordomo set sender to owner-snmpconf@majordomo.snmp.com using -f Message-Id: <200002211350.GAA186568@westrelay03.boulder.ibm.com> Date: Mon, 21 Feb 00 14:50:44 CET From: "Bert Wijnen" To: snmpconf@snmp.com Subject: http archive at http://www.escribe.com/computing/snmpconf Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Ref: Your note of Mon, 21 Feb 2000 08:42:40 -0500 Subject: Re: http archive at http://www.escribe.com/computing/snmpconf Thanks Steve. No additional clarification needed I think. Bert