From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 06:19:45 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 GAA18260 for ; Thu, 1 Jun 2000 06:19:45 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA15583 for snmpconf-outgoing; Thu, 1 Jun 2000 06:02:02 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB077FEAE2@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 Date: Thu, 1 Jun 2000 12:01:17 +0200 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 Seems you missed out your co-chair as an attendee?? I am also missing Dave Durham (intel) on that list. Bert From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 06:59:18 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 GAA18936 for ; Thu, 1 Jun 2000 06:59:17 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA16265 for snmpconf-outgoing; Thu, 1 Jun 2000 06:43:45 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB077FEB57@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jon Saperia , snmpconf@snmp.com Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 Date: Thu, 1 Jun 2000 12:42:59 +0200 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 Some comments on parts of the minutes: > In the afternoon of the second day (Thursday) we had a long discussion of > the architecture. There seems to be general agreement on the chosen > approach > though more work needs to be done to express this. The relationships (the > ones presented in Jon's slides and later represented by Steve) seem to be > the right ones and could be beneficial. Andrew suggested that a team might > want to do more work on this. From what I gathered, Andrew suggested this because he feels (and I believe most of us agreed) that this architecture could be done in a generic (solution independent way) and that such an architecture would be very important for whichever solution we come up with in the IETF. > Next Interim Meeting: > > June 28-30 Boston is cancelled because certain people cannot make it that > week, and the consensus of the attendees is that the time to produce > modified documents, review them, and meet again, then produce modified > documents and review them before the IETF meeting is too demanding a > schedule. > Not sure... but I though we agreed that the authors would still deliver a revised set of documents towards the end of June, so that we also have ample time to dicsuss things on the mailing list before the next IETF/Interim. Then, at the otherhand, this may be just wishfull think from an AD. Bert From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 12:15:56 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 MAA26582 for ; Thu, 1 Jun 2000 12:15:55 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA24569 for snmpconf-outgoing; Thu, 1 Jun 2000 12:00:42 -0400 (EDT) Message-ID: <1E06B998E00BD311A7410008C7BF2D8F24EDB5@us-exch2-210.apptitude.com> From: Russell Dietz To: "'snmpconf@snmp.com'" Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 Date: Thu, 1 Jun 2000 08:59:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCBE2.5EF8E7E2" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCBE2.5EF8E7E2 Content-Type: text/plain; charset="windows-1252" Maybe the co-chair did NOT sign the 'so-called' blue sheet... :-) Russ -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, June 01, 2000 3:01 AM To: snmpconf@snmp.com Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 Seems you missed out your co-chair as an attendee?? I am also missing Dave Durham (intel) on that list. Bert ------_=_NextPart_001_01BFCBE2.5EF8E7E2 Content-Type: text/html; charset="windows-1252" RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19

Maybe the co-chair did NOT sign the 'so-called' blue sheet... :-)

Russ

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, June 01, 2000 3:01 AM
To: snmpconf@snmp.com
Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting
h eld in San Francisco May 17 - 19


Seems you missed out your co-chair as an attendee??
I am also missing Dave Durham (intel) on that list.

Bert

------_=_NextPart_001_01BFCBE2.5EF8E7E2-- From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 12:59:06 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27423 for ; Thu, 1 Jun 2000 12:59:05 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA26188 for snmpconf-outgoing; Thu, 1 Jun 2000 12:41:49 -0400 (EDT) Message-ID: <39369162.7B6E17F5@enterasys.com> Date: Thu, 01 Jun 2000 12:37:54 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held in San Francisco May 17 - 19 References: <1E06B998E00BD311A7410008C7BF2D8F24EDB5@us-exch2-210.apptitude.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, I see that the list I sent to Jon did not include myself or Dave Durham. Checking for a pattern, I do see that I included Dave Perkins, so I didn't just drop all Dave packets. ;-) dbh Russell Dietz wrote: > > Maybe the co-chair did NOT sign the 'so-called' blue sheet... :-) > > Russ > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, June 01, 2000 3:01 AM > To: snmpconf@snmp.com > Subject: RE: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of > meeting > h eld in San Francisco May 17 - 19 > > Seems you missed out your co-chair as an attendee?? > I am also missing Dave Durham (intel) on that list. > > Bert -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 14:12:15 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 OAA28954 for ; Thu, 1 Jun 2000 14:12:14 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA28251 for snmpconf-outgoing; Thu, 1 Jun 2000 13:55:35 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 01 Jun 2000 13:56:10 -0400 Subject: Re: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 From: Jon Saperia To: Message-ID: In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB077FEB57@nl0006exch002u.nl.lucent.com> 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 on 06/01/2000 6:42 AM, Wijnen, Bert (Bert) at bwijnen@lucent.com wrote: >> > Not sure... but I though we agreed that the authors would still deliver a > revised set of documents towards the end of June, so that we also have > ample time to dicsuss things on the mailing list before the next > IETF/Interim. > Then, at the otherhand, this may be just wishfull think from an AD. Bert, For the SNMP Configuration WG, under the current plan we would need to have the documents published no later than the ID cut off date for the next IETF. I spoke with Steve Waldbusser yesterday about this for the Policy MIB Module. We talked about having a goal of publishing the documents a week or two before the cut off date to give even more time for discussion. Not a cast in stone promise yet, but something I will work with all the editors to do. Over the next few weeks we will also be working on the issues on this list. This will also serve to help people get additional background. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 14:12:15 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 OAA28955 for ; Thu, 1 Jun 2000 14:12:15 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA28360 for snmpconf-outgoing; Thu, 1 Jun 2000 13:59:06 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 01 Jun 2000 13:59:43 -0400 Subject: Re: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting h eld in San Francisco May 17 - 19 From: Jon Saperia To: Message-ID: In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB077FEAE2@nl0006exch002u.nl.lucent.com> 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 on 06/01/2000 6:01 AM, Wijnen, Bert (Bert) at bwijnen@lucent.com wrote: > Seems you missed out your co-chair as an attendee?? He must have missed adding his name to the list. He provided that part of the notes :-) I will add it. > I am also missing Dave Durham (intel) on that list. > Added as well. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 14:53:33 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 OAA00276 for ; Thu, 1 Jun 2000 14:53:33 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA29605 for snmpconf-outgoing; Thu, 1 Jun 2000 14:39:11 -0400 (EDT) Message-ID: <3936ACF9.839E90F1@enterasys.com> Date: Thu, 01 Jun 2000 14:35:37 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "snmpconf@snmp.com" Subject: snmpconf comments on the minutes 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, A couple comments. "During discussion, it was observed that capacity and usage/utilization feedback is an important part of the process." was changed from what I sent in. My original was an observation that feedback is important. I don't think it was meant to be limited to feedback about capacity and usage/utilization. I think it was meant to also include verification of appropriate expansions, etc. I didn't capitalize a number of vendor names in the attendees list. they should be capitalized. A paragraph about scheduling being a particular type of mode shift was removed, even though it was discussed. Was there a reason for removing it? We discussed whether operators should be allowed to override policy. That discussion was removed from your version. "The BNF expressing the expression" might be better as "expressing the syntax." This was changed so as to not use "language" to describe the expression expression, but we have a whole section in day two relating to language issues. It might be wise to change the use "language" there as well. "SETs and compund statements - are not allowed in filters." Why the '-'? In the mention of Perl, I should have made environment plural. You changed my spelling of accessor to acessor, which I questioned. I cannot find accessor or acessor in the dictionary, my C++ books, or my Java books. Maybe we should change it to "access" functions everywhere. "assessor functions" should be made consistent with other usage. I would change "Conflict Issues" to "Conflict Resolution Issues" to differentiate it from issues where the WG has conflict ;-) Under conflict issues, you have used single-spacing, while you used double spacing in other lists. I suggest you use a [end of list] marker in the minutes, to make it more apparent when the context has changed. "Andrew suggested that a team might want to do more work on this" was changed from my version that said "A design team was proposed by Andrew to capture the relationships for use not only by snmpconf, but by other working groups as well." I think my version better reflected the original proposal. dbh -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 16:53: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 QAA03517 for ; Thu, 1 Jun 2000 16:53:58 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id QAA03828 for snmpconf-outgoing; Thu, 1 Jun 2000 16:37:29 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 01 Jun 2000 16:38:01 -0400 Subject: Re: snmpconf comments on the minutes From: Jon Saperia To: Message-ID: In-Reply-To: <3936ACF9.839E90F1@enterasys.com> 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 on 06/01/2000 2:35 PM, David Harrington at dbh@enterasys.com wrote: > Hi, > > A couple comments. > > "During discussion, it was observed that capacity and usage/utilization > feedback is an important part of the process." was changed from what I > sent in. My original was an observation that feedback is important. I > don't think it was meant to be limited to feedback about capacity and > usage/utilization. I think it was meant to also include verification of > appropriate expansions, etc. Ahh...I see your point. The change was to reflect other notes I made and a comment I made on this point. I will add in your comment about including verification etc. > > I didn't capitalize a number of vendor names in the attendees list. they > should be capitalized. > Done. > A paragraph about scheduling being a particular type of mode shift was > removed, even though it was discussed. Was there a reason for removing > it? Yes, I was not able to understand what you wrote. If you would like to reword it I will be happy to include it. > > We discussed whether operators should be allowed to override policy. > That discussion was removed from your version. Probably I had the same problem. If you would like to write a sentence or two, I will be happy to include it. > > "The BNF expressing the expression" might be better as "expressing the > syntax." This was changed so as to not use "language" to describe the > expression expression, but we have a whole section in day two relating done. > to language issues. It might be wise to change the use "language" there > as well. Same comment as above. > > "SETs and compund statements - are not allowed in filters." Why the '-'? > don't know why, it is fixed now. > In the mention of Perl, I should have made environment plural. done. > > You changed my spelling of accessor to acessor, which I questioned. I > cannot find accessor or acessor in the dictionary, my C++ books, or my > Java books. Maybe we should change it to "access" functions everywhere. I had trouble with this as well though I think I had a correct spelling at one time. The change may have been the auto correction helping me :-( I checked and found it changed only in one place. It is now how you had it. Steve Waldbusser, you started using the term. What is the spelling you intended? > > "assessor functions" should be made consistent with other usage. > > I would change "Conflict Issues" to "Conflict Resolution Issues" to > differentiate it from issues where the WG has conflict ;-) Done. > > Under conflict issues, you have used single-spacing, while you used > double spacing in other lists. Fixed. > > I suggest you use a [end of list] marker in the minutes, to make it more > apparent when the context has changed. Done for my lists. > > "Andrew suggested that a team might want to do more work on this" was > changed from my version that said "A design team was proposed by Andrew > to capture the relationships for use not only by snmpconf, but by other > working groups as well." I think my version better reflected the > original proposal. > I think I have pretty his intent at the meeting correctly captured given some of his email. If I have made an error, Andrew perhaps you could offer some text. > dbh David, thanks for the notes and for the careful review. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 17:01: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 RAA03751 for ; Thu, 1 Jun 2000 17:01:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA04026 for snmpconf-outgoing; Thu, 1 Jun 2000 16:43:40 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 01 Jun 2000 16:44:15 -0400 Subject: FW: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held in San Francisco May 17 - 19 From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: <200005312117.RAA05331@spumoni.engeast> 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 Deborah Thanks also for the review of the notes. I have forwarded your comments to the working group list so that we can benefit from other peoples recollections as well. I think you are correct in that some of these were summarized down. I noticed that when I took my notes which had the extensive listings, added my comments, the large volume of notes David Harrington and Barr provided, we were getting pretty large. That does not mean that we should not add your comments below. I am happy to do so. If you or others would like specific additions based on your comments, please provide me a sentence or two on each and where you would like to have it added in the notes. Thanks /jon ---------- > From: Deborah Fitzgerald > Date: Wed, 31 May 2000 17:17:05 -0400 > To: saperia@mediaone.net > Cc: defitzger@nortelnetworks.com > Subject: Re: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held > in San Francisco May 17 - 19 > > > Hello Jon, > > The minutes are very good. I noticed that my notes covered a couple of other > things...was not sure if you just included them in a bigger topic. > > 1.) There was a discussion regarding whether the right side should limit > the actions to SNMP events rather than more complex expressions. This > led to some debate; further, the idea of the script MIB was introduced. > I did not notice the use of the script MIB for breaking expressions or for > triggering actions in the minutes nor a discussion of this as a possible > restriction. > > 2.) There was also a discussion on role. (How it is defined, expanded, > interoperability, etc. and whether it should be in the policy statement) > Also, didn't see mention of that notification of proper role and definition > of appropriate types that realize that role was still a little fuzzy. > > 3.) In addition to discussing the size of expressions, I believe there was > a question as to whether they really needed to be user readable (especially > when stored). > > 4.) Andrew, I think, asked whether the working group needed to constrain > the scope. I'm not sure whether the axioms or assumptions were ever clearly > defined regarding this. Further, Steve had mentioned possibly doing a > mock-up of several (he said 30ish) cases. > > 5.) I'm not sure that questions about grouping captured the question of > whether all evaluations (in a given group) must be performed prior to > any actions or how this should be handled. Did not seem like there was > agreement on this issue...maybe it falls under one of the broader questions > like scheduling though. > > 6.) I saw wildcarding -- was not sure if this included globbing. > > Thanks, > > -Deb From owner-snmpconf@seymour39.SNMP.COM Thu Jun 1 17:15: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 RAA03969 for ; Thu, 1 Jun 2000 17:15:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA04775 for snmpconf-outgoing; Thu, 1 Jun 2000 17:01:33 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC917@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Subject: RE: snmpconf comments on the minutes Date: Thu, 1 Jun 2000 13:57:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I'm happy with either formulation: Dave's is more informative though. Andrew > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Thursday, June 01, 2000 1:38 PM > To: snmpconf@snmp.com > Subject: Re: snmpconf comments on the minutes ... > > "Andrew suggested that a team might want to do more work on > this" was > > changed from my version that said "A design team was > proposed by Andrew > > to capture the relationships for use not only by snmpconf, > but by other > > working groups as well." I think my version better reflected the > > original proposal. > > > > I think I have pretty his intent at the meeting correctly > captured given > some of his email. If I have made an error, Andrew perhaps > you could offer > some text. From owner-snmpconf@seymour39.SNMP.COM Sat Jun 3 11:29: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 LAA09155 for ; Sat, 3 Jun 2000 11:29:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA15570 for snmpconf-outgoing; Sat, 3 Jun 2000 11:09:39 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 03 Jun 2000 11:10:13 -0400 Subject: snmpconf Minutes of interim SNMPCONF WG Meeting in San Francisco May 17 - 19 - Reported by Jon Saperia From: Jon Saperia To: , snmpconf , Bert Wijnen , Randy Bush Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id LAA15565 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit What follows are the notes taken and the SNMPCONF WG interim meeting held in San Francisco May 17 - 19, 2000. I would like to thank David Harrington and Barr Hibbs for their contributions to these minutes and to members of the SNMPCONF working group mailing list that sent comments in on the draft. The slide presentations given at the meeting that were available in .ppt or .pdf format will be sent separately. Attendees: Jon Saperia, JDS Consulting Andy Bierman, Cisco Dan Romascanu, Lucent Steve Waldbusser, Lucent Andrew Smith, Extreme Jeff Case, SNMP Research Joel Halpern, Ivyplan Bert Wijnen, Lucent Walter Weiss, Lucent David Harrington, Enterasys Dave Durham, Intel Harrie Hazewinkel, Covalent Mike MacFaden, Riverstone Thippanna Hongal, Riverstone Deb Fitzgerald, Nortel Ken White, IBM Xiang Li, IWL Barr Hibbs, Ultraradus Chris Wellens, IWL Dave Perkins, Randy Presuhn, BMC Don Goodnature, BMC Dale Francisco, Cisco Overall Summary: This interim meeting was to have advanced the work of all three documents on the working group charter. Time limitations and a desire to resolve some pressing issues limited the focus to the Policy and Differentiated Services Policy MIB modules. Work on the Best Current Practices Document (BCP) will continue. The meeting served as a way for attendees to exchange ideas and become familiar with a proposed architecture. The main result of the meeting is a fairly extensive set of issues that will be reviewed and discussed on the working group email list. That list is contained in this summary. Day One: Agenda Bashing - In summary, we agreed to start with the Policy MIB Module, then work on the Differentiated Services Policy MIB Module, then the BCP Document. Architecture presentation: Jon Saperia presented slides describing the overall architecture of the SNMPCONF approach. These slides showed the relationship of the different levels of policy information and how the different parts of the proposed SNMP Configuration architecture realize this information. The presentation will be made available on line separately. There were a number of persons present who had not been greatly involved yet, and it led to some useful discussions about and refinements of the concepts. There was a debate about terminology for device-type, or implementation-specific or implementation-version-dependent. The group preferred implementation-dependent over device-dependent. It was pointed out that mechanism-specific is akin to standard MIB modules, while device-specific (implementation-specific) was akin to vendor-extension MIB modules. It was pointed out that the BCP terminology/descriptions were not consistent with other documents and we agreed to make fixes to the BCP document where necessary. There was significant discussion about details and layers. There is a continuum. Something (like time filters) can be high (in the manager) or low (within the device). Sometimes, it is desirable to specify the specifics at the high level, and at other times it is desirable to hide the low-level details. Example: one customer wants a Holly four-barrel carburetor installed; another customer just wants their car to go as fast as possible, and allow the mechanic to select the best approach. Since policies may be multi-conditional, it should be possible to create a policy that is part abstract and part specific. We discussed the presentation of levels of abstraction. There was discussion about whether it should be described as levels, or whether device/instance should be one axis in a matrix with domain/mechanism as the other axis? Are there only four levels? Are the levels ordered? In the end we learned that part of the confusion was that one slide was representing a simple taxonomy while the other was attempting to represent a more detailed view of the functions and data at a particular level of abstraction. Policy MIB Presentation: Steve Waldbusser presented slides on the design of the Policy MIB. The purpose of the Policy MIB is to use SNMP to move policies to places that can execute them. There is a rich set of attributes that can be examined to determine the state of the network/device/etc. There is a less rich set of attributes that can be set (either by SNMP or other management-interface). During discussion, it was observed feedback is an important part of the process. This feedback can take a number of forms from correct expansion of the policy to capacity and usage/utilization information and feedback, some of this information is already available in MIB objects. Capabilities is a Boolean optimization: it is a true/false determination of what is supported by a device. This Boolean is provided to make it easier to determine what a device supports than by discovering and examining specific MIB attributes. The Boolean could be incorrect, so Policy filters should still check to verify that application of the policy may be inappropriate. During the time between determining which policies should be distributed to a device, and the time the policies should be applied to the device, the capabilities may change. It is important to use these capabilities optimizations carefully. Policies may be downloaded when not necessary; policies may not be downloaded when needed. These error conditions need to be detectable, and there should be some standardization in error handling. Capabilities may exist at different levels of abstraction. Do we need to clarify our terminology for capabilities, such as type and subtype? A discussion on "scheduling ­ must we use a particular approach? " was shelved for later discussion. The BNF expressing the syntax in the current document needs close inspection and corrections. There are some problems. One issue is the length of the OCTET STRINGs. This discussion can be done on-list, rather than face-to-face. The efficiency of evaluating filters may need to be improved by having some standard expression pieces that constrain the scope of managed objects to be considered. Requiring that all expressions begin with the roles would reduce the costs of evaluation. We need to be careful to allow the initial expression to be multi-valued, to reduce duplication of policies, and to handle different vendors referring to something using different OIDs (Bay MIBs vs. IETF MIBs) Roles in SNMPCONF differ from roles in policy framework. Framework assumes a centralized PDP that determines role combinations. The assumption is being made that PDP has a semantic understanding of roles. SNMPCONF has found a way to store "roles" on the target devices. This may not be lightweight. We need to discuss whether iterations exist outside the rule, or inside the rule. We need to discuss scoping versus filtering regarding the level of abstraction. Some use rules to express policies, while others are using policy to determine which rules should be distributed. There are rules about what is allowed in the filters and in the actions. SETS and compound statements may not be used in filters. Should the preferred language for expressions be C or maybe Perl, since Perl is commonly used by operators and is commonly built into embedded environments. What should we do with an error? How do we handle runtime exceptions? We may need exists() and isInstanced(). Do we need IPAddress, engineID, and context to properly qualify objects? How do we handle error conditions with requests to remote devices. We need to determine how to wildcard roles (ifIndex.*). Should we support if-then-else? For time determination, should we use rfc2591, additional accessor functions, or separate MIB objects designed for our purposes. It is useful to have the time calculations at the device so there is no dependency on a connection between manager and device. Rfc2591 resolves issues of local time, daylight savings, etc. Is there a need for duration-based time stuff? Does device need to understand time? There was a discussion of needed debugging capability. Do we need a test and verify function? Does the pmTrackingElementToPolicyTable allow one to get at the necessary information to debug the problems? Should we somehow log the SETs when a policy is applied, with a time limit for persistence? Does this table offer sufficient value to justify its existence? Should it be possible to forceOFF the application of a policy to an element via this table? That would provide one central MIB to control the forceOFF. This suggestion needs to be discussed on the mailing list. Do we need to have standard notification when policy is overridden? Should we add a last-update field to pmTable? Should we add current_version field? Which policy group is this part of? Day Two Review of Issues: We reviewed topics to be discussed, both from yesterday¹s meeting and new topics proposed by the attendees. The following lists were produced during an extended conversation designed to generate topics for discussion both for the remainder of the meeting and on the SNMPCONF mailing list. These issues will be published again to the mailing list in groups to foster discussion and resolution of issues. A Meta-question was raised: how do we add items to the list of features, and how do we resolve whether they will be accepted? Do we need to consider the costs/benefits? General Functional Questions: 1. Should operators be able to override policy? Where is it useful to restrict this in the architecture - fall out issues? 2. We need to more fully specify terminology regarding capabilities type and sub-type. 3. What do we call capabilities that are beyond type and sub-type such as those found in the mechanism and implementation specific modules? The mechanism for their discovery is? 4. Are capabilities and capacity information part of the policy decision? 5. How do we do duration time calculations? 6. How do we represent and deal with time of day in the policy expression? 7. Time based rules are good things, there are some scheduling approach options: What light weight options do we want to allow? Do we require the device to know about time of day? 8. Would like to test a filter to get to the pointer to the attributes that have been changed as a result of the policy. 9. Do the debug tables do enough? Do they need to change or should they be removed? What is needed to improve them and is it worth the cost? 10. When was a system last touched? What was changed and when was a constellation of policies changed? 11. How do capabilities work? 12. How do we represent capacity and information about utilization? 13. General issue of debugging policies and the PmTracking table. How useful is this and how do we want to support the function? Is more needed for these tables? 14. How do we deal with revision of a single policy and sets of policies? Do we have policy groups, and policy priorities. How will we represent them? 15. Is there fate sharing between policies in groups, if so how is this specified? 16. How often do policy evaluations run? 17. Storage-type clarification for policies, are they all non-volitile? 18. Do/can-we start/stop polices as groups? 19. Resolution of the forced off in the pmTracking tracking table? 20. Do we want to allow cascading policy what are the implications? 21. What are legitimate policy names? 22. Notifications - what is the proper role, what are the proper notifications to be developed? [end of list] Execution Environment Questions: 1. What are the implementation target environment requirements for the work? 2. What are the minimal requirements for systems that participate in the policy work and configuration. 3. Would like clearer definition of what Œthis element¹ is. 4. What is the scheduling environment? [end of list] Policy Processing Questions: 1. An agent that gets a bad policy should do the right thing where right thing is to be defined. 2. Expression examples would be helpful: can we get (a+b) and ((a+B)*c) or a+(bxc) or (A+B)xc? 3. How do we handle syntax errors? 4. How do we handle run time exceptions -How many errors are OK within a policy? 5. How to deal with partial failures - notification of policy in trouble? 6. Types of exceptions - e.g. divide by zero or parts of the system failures. Token and run time exceptions? 7. What is the role of the manager in evaluating expressions? 8. What type of error reporting from the agent is required. -agent validation functions and what type of errors -Policy testing/verification prior to putting into service 9. Is it a requirement that we support UTF8 in our accessor functions? 10. Do we want to feed values from filter in to the policy action? - Intermediate values? - After we get a return value do we want to fire an action, and if so with a parameter other than true false, passing arguments. 11. Is the constraint of left and right useful? 12. Do we need both action and filter or would one do? What are the interactions allowed? 13. Need to address the question of the syntax of an identifier - what is the proper syntax of ifType.$1 - what is the structure including wildcarding? 14. What are the implications of wildcarding and implications in both directions in the role tables. 15. How big should an expression be allowed to be? 16. Not possible to download all policies everywhere. Must subset what to send so must handle two errors: download superfluous policy, fail to download needed policy: Type I and Type II - false positives 17. How do we detect and how to standardize error handling. 18. Estimated number of policies that we need to handle - we need the architecture to be able to scale up and down - what attributes are required to meet this goal? 19.Where to start the policy evaluation? 20. How often to evaluate the filter and when? 21. Is iterator is outside or inside the filter statement? 22. Is one iterater sufficient or do we need nested iterators. 23. How do we select instances? 24. What do we want for role - iteraters how many where. [end of list] Language Related Questions: 1. Language for expressions. To what degree do we want to use an existing language, and to what extent do we want to define our own? If we leverage an existing language, but constrain it to behave in ways that make it incompatible with the original, then we do not get reuse of language implementation, although we may get reuse of operator knowledge of languages like Perl. 2. We need to discuss Choice of language and Richness of language. Temporary variables, garbage collection; do we support temps or not? 3. Is UTF-8 support required in the expression language? 4. Extensibility Questions: For language and assessor functions - a natural one that allows for extension without re-opening the standard? sub-setting the language (do we allow or prohibit it)? sub-setting the assessor functions ibid? 5. Accessor functions ­ work to be done; reviewing proposed list. How to add new ones as they are needed? Can they go outside the SNMP universe? Mapping of principals, etc? 6. How do we handle versioning issues? 7. There were some standardization questions: standardization of element identifiers? capability type and subtype? extensibility mechanisms - are these part of the expression language? 8. Is the attribute of the element predefined? Can there be multiple instances? 9. How big should an expression be? 10. What are the execution environment requirements? 11. Temporary variables - do we want them: How do you dispose of them if we have them? 12. There were a number of attributes that people felt were desired. These include: needs to be debug-able - want to avoid memory leaks want to have instrumentation that helps people find bugs, want to avoid loopers but want iterators. 13. Issues about comments - comments in the expression - are they allowed? [end of list] Architectural and Relationship with other Documents Questions: 1. How do we expect the mechanism and implementation specific policy modules to interact with the policy module? 2. The Policy MIB Module can manipulate any MIB object. Therefore, these MIB modules need to create objects that can be manipulated by the Policy Module. These need to be added to the Differentiated Services Policy MIB Module 3. Can policies cascade (nest)? Can filters or actions cascade? Can a policy reference another? How are policies named so they can be referenced? 4. Access control to the objects touched by the policy module need to be specified. In short, when a policy is run, whose security credentials are used? 5. How do we deal with security issues when a policy includes out of box or out of SNMP 'view' operations? 6. The policy module provides for instance expansion. The mechanism and implementation specific modules provide for object expansion. 7. What is the semantic method for expressing the fact that a policy has decided that a mechanism template is to be applied to a specific set of instances? Do we want to use language or specific MIB objects? One view is that the semantics are in the definition of the MIB object that is in the mechanism specific module. 8. Issues about indexing between policy module and the Diffserv MIB module need pointers in both directions. Linkages of the differentiated services policy MIB module to the Policy MIB Module relationship; of the DS MIB to our work. [end of list] Conflict Resolution Issues 1. How do we deal with intentional and unintended conflicts. 2. Is conflict detection or resolution a goal? 3. What happens when a policy is deleted? What if anything do you revert to? 4. How many errors are acceptable in a policy? How are they reported? 5. What happens when a configured element breaks that is executing a policy? [end of list] In the afternoon of the second day (Thursday) we had a long discussion of the architecture. There seems to be general agreement on the chosen approach though more work needs to be done to express this. The relationships (the ones presented in Jon's slides and later represented by Steve) seem to be the right ones and could be beneficial. A design team was proposed by Andrew to capture the relationships for use not only by snmpconf, but by other working groups as well. The theoretical approach is "for all elements, for all filters, then for each instance which triggers an action, perform the action". This is too inefficient, and we need to improve the scalability. One way is to define a standard order of evaluation that will yield fast elimination of large portions early in the process. Another approach is to preprocess the filter, such that the number of filters to be processed is reduced. (i.e. the PDP only sends appropriate role-based filters to the PEP) The amplification of instances promises greater savings than amplification of objects. The amplification of objects is useful when two vendors use different implementations of the same things. An agent should be able to determine which elements are supported for policy (and which existing functionality is not supported for policy). Not all functionality must be exposed to management via policy. Instance amplification happens in the device-specific component, and in the domain-specific evaluation. The most interesting is the expansion within the filter expansion applied over some set of objects, in a way to avoid evaluating the universe. The agent should know which things it should be able to iterate over. The manager should be able to determine which things the agent knows how to iterate over. To constrain the number of types of elements, an enumerated integer provides constraints to extensibility. A new proposal is to allow a manager to download an OID Prefix to identify what should be iterated over. Reuse of filters is unlikely to be frequent. Reuse of actions is more likely to have benefits. However, the cost of indirection may be more expensive than the benefits. Friday Agenda 9 - 12 day three: We agreed that we wanted to spend time on the following topics even though that meant that we would not get to the BCP document before the close of the meeting. MIB Relationships: Should Diffserv-Policy MIB Module refer to the Policy MIB Module, or should the Policy MIB Module refer to Diffserv-Policy MIB Module? i.e. where should the pointer (and dependencies/knowledge of relationship) be? Jeff Case wants Policy MIB to point to Diffserv Policy MIB because he expects to use a mid-level manager with a Policy MIB, and multiple Diffserv Policy MIB instantiations on various devices. The indexes used by both Policy MIB and Diffserv Policy MIB must be consistent across devices and across reboots. It is not always possible to determine from Diffserv Policy MIB entries which Policy MIB entries are associated; it will not be possible to determine from Diffserv Policy MIB entry which policies will be affected if the Diffserv Policy MIB entry is deleted. (This is similar to not understanding which programs will be impacted by deleting /etc/host file on UNIX or something.dll in WinXX). This may be made easier by having an installation log which keep track of which installed pieces have relationships, but this still wouldn¹t resolve all the possible anomalies of these relationships. We need to study the issues here and make sure we have a good design. Scalability: How often do policies execute, and where are the iterators? Continuously, event-driven, once, periodically, ad hoc, combination? We may need to consider the parts separately: How often do the filters get evaluated? How frequently do actions get enforced? How can the importance of filter evaluation be specified - which filters are the most important when determining evaluation frequency? (not precedence in conflict resolution)? How quickly will you notice state changes? Should we make it possible for the NMS to specify maximum acceptable latency? This doesn¹t imply polling; an async engine can provide very low latency without polling. Should we have a Reevaluate-All button to force all filters to be reevaluated? Should there be a lower bound for detection of the action, and an upper bound for the completion of the action Š these are two different things! Rollbacks ­ When a policy no longer exists or applies, in the absence of a specific policy which applies to the new state, what should the new settings be? Do we need to keep original state for re-application? Do we keep the same settings until a policy is found that tells us otherwise? Wrap Up: Conflict Resolution still needs to be discussed. We need to discuss how policies will be "packaged," and how packages are defined. Next Interim Meeting: June 28-30 Boston is cancelled because certain people cannot make it that week, and the consensus of the attendees is that the time to produce modified documents, review them, and meet again, then produce modified documents and review them before the IETF meeting is too demanding a schedule. The proposed alternative is to have an interim meeting on the Friday and Saturday following IETF Pittsburgh (with a full day Saturday). An early-week meeting would provide an opportunity for an overview of the work done during this interim meeting, plus questions and answers, and leave enough time for people to read all the necessary documents prior to the working sessions Friday and Saturday. From owner-snmpconf@seymour39.SNMP.COM Mon Jun 5 18:32:20 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11934 for ; Mon, 5 Jun 2000 18:32:20 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA08351 for snmpconf-outgoing; Mon, 5 Jun 2000 18:11:57 -0400 (EDT) Date: Mon, 5 Jun 2000 18:11:14 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held in San Francisco May 17 - 19 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Wed, 31 May 2000, Jon Saperia wrote: > The proposed alternative is to have an interim meeting on the Friday and > Saturday following IETF Pittsburgh (with a full day Saturday). An early-week > meeting would provide an opportunity for an overview of the work done during > this interim meeting, plus questions and answers, and leave enough time for > people to read all the necessary documents prior to the working sessions > Friday and Saturday. This would work well for me. -Matt From owner-snmpconf@seymour39.SNMP.COM Mon Jun 5 20:33:57 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12977 for ; Mon, 5 Jun 2000 20:33:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id UAA11042 for snmpconf-outgoing; Mon, 5 Jun 2000 20:17:04 -0400 (EDT) Message-Id: <200006060017.UAA26776@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf SNMPCONF WG Interim Meeting Slide Presentations Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 05 Jun 2000 20:16:59 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit The following is a submission by Jon Saperia. ------- Forwarded Message From: Jon Saperia To: , snmpconf, Jon Saperia Message-ID: Mime-version: 1.0 Content-type: multipart/mixed; boundary="MS_Mac_OE_3042881062_302988_MIME_Part" There are 4 attachments to this message that were referenced in the previously submitted minutes. 1. An overview of the agenda and logistics prepared by Jon Saperia 2. An overview of the architecture and our work prepared by Jon Saperia 3. An overview of the Policy MIB Module and additional explanatory detail prepared by Steve Waldbusser 4. A compressed tar file of the information interrelationships between the Differentiated Services MIB Module, the Differentiated Services Policy MIB Module and the Qos Device Model prepared by Harrie Hazewinkel. /jon ------- End of Forwarded Message As the combined mail message ran over 2mb (causing Majordomo to bounce it), slide documents have been made available via anonymous ftp at ftp://www.snmp.com/pub/snmpconf/interim-may-2000/ In this directory are the following files: 1 agenda.desc The mail message above 63 agenda.ppt Attachment 1 as discussed above 9 agenda.ppt.gz Attachment 1 as discussed above, compressed 1333 overview.ppt Attachment 2 as discussed above 850 overview.ppt.gz Attachment 2 as discussed above, compressed 633 policymodule.ppt Attachment 3 as discussed above 534 policymodule.ppt.gz Attachment 3 as discussed above, compressed 15 inforelationships.tar.gz Attachment 4 as discussed above 24 minutes The minutes of the meeting posted earlier These files are also available via the majordomo "get" command. For example, to retrieve the minutes of this meeting, send the command get snmpconf interim-may-2000/minutes to majordomo@snmp.com, and the file will be emailed to you automatically. I have also forwarded the complete original message to the http archive site at escribe.com. From owner-snmpconf@seymour39.SNMP.COM Wed Jun 7 11:17:49 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12700 for ; Wed, 7 Jun 2000 11:17:49 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA21681 for snmpconf-outgoing; Wed, 7 Jun 2000 10:56:12 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 07 Jun 2000 10:57:01 -0400 Subject: snmpconf Getting things moving again. From: Jon Saperia To: snmpconf Message-ID: 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 We made good progress while at the interim meeting and came up with a fairly significant listing of 'to do' items and issues. To get things moving again and make sure that the editors get good feedback for the current revisions that will be made available for the next IETF meeting, I am going to send a series of postings to the list. These postings will be the issues/questions from the meeting minutes. Each category will be divided into a separate note. I fully expect that for some of the longer lists, we may subdivide them further. Over the next few days, I will post these items and make comments under those questions that I have a strong feeling about. I am sure this will prompt some conversation :-) Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Wed Jun 7 11:42:40 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13545 for ; Wed, 7 Jun 2000 11:42:40 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA22524 for snmpconf-outgoing; Wed, 7 Jun 2000 11:28:17 -0400 (EDT) From: Dale Francisco Message-Id: <200006071527.IAA08436@itech-view2.cisco.com> Subject: Re: snmpconf Getting things moving again. To: snmpconf@snmp.com Date: Wed, 7 Jun 2000 08:27:41 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) In-Reply-To: from "Jon Saperia" at Jun 07, 2000 10:57:01 AM X-Mailer: ELM [version 2.5 PL1] 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 Jon, Are the snmpconf i-ds on the IETF web site all the latest versions (the ones discussed in SF)? Thanks, Dale > > We made good progress while at the interim meeting and came up with a fairly > significant listing of 'to do' items and issues. To get things moving again > and make sure that the editors get good feedback for the current revisions > that will be made available for the next IETF meeting, I am going to send a > series of postings to the list. > > These postings will be the issues/questions from the meeting minutes. Each > category will be divided into a separate note. I fully expect that for some > of the longer lists, we may subdivide them further. > > Over the next few days, I will post these items and make comments under > those questions that I have a strong feeling about. I am sure this will > prompt some conversation :-) > > Thanks > /jon > > From owner-snmpconf@seymour39.SNMP.COM Thu Jun 8 09:11:12 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03572 for ; Thu, 8 Jun 2000 09:11:10 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA02499 for snmpconf-outgoing; Thu, 8 Jun 2000 08:48:57 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 08 Jun 2000 08:49:48 -0400 Subject: snmpconf General Functional Questions From: Jon Saperia To: snmpconf Message-ID: 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 This note is the first in the series that I said I would send. It contains the items under the General Functional Questions heading that appeared in the minutes of our interim meeting. This time I have put in my 'editorial comments'. I would like to get feedback/consensus on these issues so that we can impact the appropriate draft documents. For those items that I do not have a strong feeling or view, I did not say much or said no comment. > General Functional Questions: > > 1. Should operators be able to override policy? Where is it useful to > restrict this in the architecture - fall out issues? Yes. It is an essential operational component for operators to be able to change one or more elements that are under policy control. For the purposes of this discussion, an element could be anything from an entire system, software that runs on it, or an individual queue on an interface. I do not believe we should restrict the ability to override policy in the architecture. I believe that this approach raises several issues. I have added my suggestions for their resolution - I am sure there may be others. A. Notification of the change to operators - I believe that a notification should be sent from the managed element to the configured managers for the system. The notification should contain the following information: user, time of change, and the objects that were changed. The instance values will be known to the system and would be conveyed to the manager as in any other notification. The preferred notification for all of our would should be an inform. B. Where is the override shown on managed system. The managed system should reflect this in the status objects contained in the the Policy Table, and when an implementation and/or mechanism specific Module is in use, the change(s) should be reflected in the relevant status objects contained in that modules table. We may want to consider a marking for the Role table so show when an element that is under policy control contains one or more objects that have other than 'default' values. C. How long is the override in effect? I recommend until one of two events. First, some source outside the policy system changes the value(s) back to the defaults. In which case there will no longer be the difference detected in point B above. The most common source will be the CLI. Second, a policy is reloaded to a system which should override the overrides. D. What if the override causes a fault or failure in one or more operating policies? - I see this as no different than failures under other circumstances. The same rules (that we have not yet worked out) should apply. > > 2. We need to more fully specify terminology regarding capabilities type and > sub-type. I would like to propose the following hierarchy for capabilities that uses the same terms we agreed on at the interim meeting: Capability Type - Support for a particular technology domain such as DIFFSERV or INTSERV or WEB Services or DNS. Capability Sub-Type - support for a particular mechanism such as RED, WRED, APACHE, BIND, etc. Capability type and sub-type should be standardized values. > > 3. What do we call capabilities that are beyond type and sub-type such as > those found in the mechanism and implementation specific modules? The > mechanism for their discovery is? If an implementation specific technology were also available that would appear as a vendor specific sub-type. Note that this does not include the specific parameters that would appear in a mechanism or implementation specific policy module. A policy management application would know of the presence of such a module from the sub type value(s) in the policy module and would be able to learn the details through a direct query to tables in the implementation and mechanism specific tables. This is not unlike some SNMP based discovery methods used for network topology today where the results returned from the query of one table lead to the interrogation of other tables. There is an implication here for tables that have not yet been populated since there will be no instances. This can be worked out without adding additional MIB objects. One method is to create a reserved row that is the first row of the table. I would also like to suggest that as sub-systems go up or down and make their information available to the Policy Module, that an INFORM be sent to make things more efficient. > > 4. Are capabilities and capacity information part of the policy decision? There are several questions here: A. Where is the policy decision made? Ultimately capabilities and capacity do impact what happens in the real world. For example, if we attempt to configure name server parameters on a system without a name server one would expect a no such error from an agent. In a sense this is a type of capability check. If I attempt to provision a new service on a router and the packet forwarding engine is already at capacity, ultimately the policy will fail - though the failures might occur at very small time intervals. The question posed by this point is - Should these factors impact a policy management applications decision about whether or not to send or modify a policy in a managed device. I think the answer should be yes. A. Is this a mandatory requirement of the architecture, or is it allowed within the architecture that these factors impact the decision? I believe that within the architecture of SNMP based configuration, there is no restriction or requirement that these factors be taken into account. Even though the architecture does not require it, I believe it is a useful optimization for these factors to be taken into consideration since it will be operationally beneficial. B. Can/Should capabilities impact what an application sends to an element. This question would be relevant regardless of where the application ran, in a managed element itself, in a 'mid-level' manager, or in a centralized station? Yes. C. Can/Should capacity information similarly impact the policy decision? Yes. These answers beg the question about where does the information come from? The capability information is described in the previous question. Capacity information has several relevant sub parts. - First is total capacity for a system to perform some function. - Second is the amount of that capacity that remains averaged over some time interval. - Third is amount desired/needed for the new policy. - Fourth is reserve to be held (some systems are under-provisioned as a matter of policy for backup in certain failure conditions) In some cases, the capacity information will be directly available such as with ifSpeed. In some cases, objects that are direct reflections of capacity may not be available or algorithmically determinable, though they can be counted as in the number of packets forwarded, or the number of WEB pages served. In these cases, I would say that we should consider the addition of a table that can be used similar to our role tables. This would contain total capacity, reserved capacity, and allow for the aggregation of used resources. The concept of policy groups is helpful here since we may want to aggregate usage based on related policies. In some cases, capacity is not relevant as in the case of a policy that requires a particular version of software. In this case it would be allowable for the capacity object to be null. > > 5. How do we do duration time calculations? Before the Interim meeting, Hongal had started some work on time, schedules, etc as had Steve. I have no strong feelings in this are or specific suggestions. > > 6. How do we represent and deal with time of day in the policy expression? > ibid., except we should be able to express things with durations and single/one time fire rules. > 7. Time based rules are good things, there are some scheduling approach > options: > What light weight options do we want to allow? > Do we require the device to know about time of day? Same, perhaps Steve, Hongal and others could make suggestions. > > 8. Would like to test a filter to get to the pointer to the attributes that > have been changed as a result of the policy. I agree this would be a good function. We talked very briefly during the meeting about testing. We need a specific proposal about testing and verification. > > 9. Do the debug tables do enough? Do they need to change or should they be > removed? What is needed to improve them and is it worth the cost? This is related to the previous question. I believe the answer is that there is high value. The question is what is the cost and until we can evaluate a specific proposal that is hard to judge. Does anyone have a specific proposal. Mike MacFaden has been a strong supporter of testing and verification - any suggestions? > > 10. When was a system last touched? What was changed and when was a > constellation of policies changed? > I see value in last changed objects for several of the tables including most of the tables in the Policy Module. The reason is that when debugging a network, the network engineer may not have access to the centralized management information so having it available 'on the box' would be of benefit. > 11. How do capabilities work? See previous comments. > > 12. How do we represent capacity and information about utilization? See previous comments, though I know we need to do more work here. > > 13. General issue of debugging policies and the PmTracking table. How useful > is this and how do we want to support the function? Is more needed for these > tables? See comments on question 9. > > 14. How do we deal with revision of a single policy and sets of policies? Do > we have policy groups, and policy priorities. How will we represent them? I believe that groups are helpful for some of the reasons previously stated. I also think that priority is helpful. Unfortunately this raises the question of whether priority spans groups. I believe it should and that we can construct the policy tables to accommodate this with a single object and some rules. For example if there are 32 policies, and a new policy is added that needs to be number 2. The previous number 2 becomes 3 and so on. > > 15. Is there fate sharing between policies in groups, if so how is this > specified? I am not sure this is necessarily a good idea. Do others have comments? > > 16. How often do policy evaluations run? > My view is that this will need to vary, but his does not answer the question. I believe that this will get resolved when we have the 'iteration' discussions. Andy had some views and Steve is working on this. Any proposals? > 17. Storage-type clarification for policies, are they all non-volitile? > I am not sure we should mandate this, but I would recommend they be non-volatile. > 18. Do/can-we start/stop polices as groups? I believe that this is 'a good thing' if not too costly and that we should specifically support it with policy group objects. > > 19. Resolution of the forced off in the pmTracking tracking table? > no comment. > 20. Do we want to allow cascading policy what are the implications? nc. for now. > > 21. What are legitimate policy names? > I do not believe the architecture or our recommended approach to implementation should pose many limitations. Are there specific recommendations. > 22. Notifications - what is the proper role, what are the proper > notifications to be developed? See previous comments. > > [end of list] From owner-snmpconf@seymour39.SNMP.COM Thu Jun 8 10:46:39 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08773 for ; Thu, 8 Jun 2000 10:46:39 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA05853 for snmpconf-outgoing; Thu, 8 Jun 2000 10:24:27 -0400 (EDT) Message-Id: <4.2.2.20000608101213.00a842d0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 08 Jun 2000 10:22:16 -0400 To: snmpconf From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions 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 I would agree that the ability to override policy on a "local" basis is important. There are several ways to look at this, some of which I think are problematic. 1) Unless we change the SNMP semantics (something we all agree we should not do), there is a basic multi-manager capability of SNMP. As such, something set at a policy level can be changed at the instance level. I think it would both be significant effort and undesirable to change this. 1a) The immediate question then becomes what indications one expects of this change. Trying to keep enough track of what objects are effected by policies such that when a person changes an instance object a higher level policy marking is automatically created reflecting the override seems problematic. 1b) There is the whole question of how / when policies are neforced. if we consider that policy actions are taken when policy conditions are checked and verified, we still have the question of when the conditions are rechecked. If they are rechecked periodically, and if the conditions include the state of the variable to be changed, then it is quite easy to see that a human being trying to change an isntance object might find it continually changing back. He would then need to somehow track down the policy that is controlling that, and somehow have a way to disable the policy. 1b') The disabling of the policy is probably only supposed to happen for some specific instance, not all instances in the box. But one would not want to have to change the roles attached to an instance just to disable a policy, would you? Similarly, what happens if the manager sends a new set of policies? How will those effect this override? 1c) There can easily be more than one policy which affects an instance variable (for example, different policies for different times of day). I can not see an obvious heuristic for deciding what the operator wants done with the nighttime policy when he changes a variable and turns off the daytime policy. My own conclusion is that A) we need to spell out clearly how and when policies take effect and maintain effect. B) That most of the rest needs to be left to the structuring of the policy conditions. For example, one could add a role that is "exempted", and in all ones policies include "and not exempted". That may not be the best solution, and we certainly can not mandate it. But trying to solve all of the interactions in "override are simply impractical. The only alternative I can see is a COPS-like mechanism where there is no override at all. Yours, Joel M. Halpern At 08:49 AM 6/8/00 -0400, Jon Saperia wrote: > > General Functional Questions: > > > > 1. Should operators be able to override policy? Where is it useful to > > restrict this in the architecture - fall out issues? > >Yes. It is an essential operational component for operators to be able to >change one or more elements that are under policy control. For the purposes >of this discussion, an element could be anything from an entire system, >software that runs on it, or an individual queue on an interface. I do not >believe we should restrict the ability to override policy in the >architecture. I believe that this approach raises several issues. I have >added my suggestions for their resolution - I am sure there may be others. > > A. Notification of the change to operators - I believe that a >notification should be sent from the managed element to the configured >managers for the system. The notification should contain the following >information: user, time of change, and the objects that were changed. The >instance values will be known to the system and would be conveyed to the >manager as in any other notification. The preferred notification for all of >our would should be an inform. > > B. Where is the override shown on managed system. The managed system >should reflect this in the status objects contained in the the Policy Table, >and when an implementation and/or mechanism specific Module is in use, the >change(s) should be reflected in the relevant status objects contained in >that modules table. We may want to consider a marking for the Role table so >show when an element that is under policy control contains one or more >objects that have other than 'default' values. > > C. How long is the override in effect? I recommend until one of two >events. First, some source outside the policy system changes the value(s) >back to the defaults. In which case there will no longer be the difference >detected in point B above. The most common source will be the CLI. Second, a >policy is reloaded to a system which should override the overrides. > > D. What if the override causes a fault or failure in one or more >operating policies? - I see this as no different than failures under other >circumstances. The same rules (that we have not yet worked out) should >apply. From owner-snmpconf@seymour39.SNMP.COM Thu Jun 8 12:56:52 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11984 for ; Thu, 8 Jun 2000 12:56:51 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA09629 for snmpconf-outgoing; Thu, 8 Jun 2000 12:35:53 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 08 Jun 2000 12:36:48 -0400 Subject: Re: snmpconf Getting things moving again. From: Jon Saperia To: CC: Dale Francisco Message-ID: In-Reply-To: <200006071527.IAA08436@itech-view2.cisco.com> 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 on 06/07/2000 11:27 AM, Dale Francisco at dfrancis@cisco.com wrote: > Jon, > > Are the snmpconf i-ds on the IETF web site all the latest > versions (the ones discussed in SF)? > > Thanks, > Dale Yes, I just checked the Policy and Diffserv Policy documents from the SNMPCONF WG page and they are current. We have more work to do and we did do a lot at the interim meeting. We will be making significant updates prior to the next IETF. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 08:52:57 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10501 for ; Fri, 9 Jun 2000 08:52:57 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA14892 for snmpconf-outgoing; Fri, 9 Jun 2000 08:34:25 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 08:35:19 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000608101213.00a842d0@omniplex.mcquillan.com> 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 Joel, Thanks very much for the thoughtful comments. Some of the issues I think I have some ideas about. Others are a bit more difficult. Perhaps others have ideas. /jon on 06/08/2000 10:22 AM, Joel M. Halpern at joel@mcquillan.com wrote: > I would agree that the ability to override policy on a "local" basis is > important. There are several ways to look at this, some of which I think > are problematic. > > 1) Unless we change the SNMP semantics (something we all agree we should > not do), there is a basic multi-manager capability of SNMP. As such, > something set at a policy level can be changed at the instance level. I > think it would both be significant effort and undesirable to change this. agreed. > > 1a) The immediate question then becomes what indications one expects of > this change. Trying to keep enough track of what objects are effected by > policies such that when a person changes an instance object a higher level > policy marking is automatically created reflecting the override seems > problematic. Perhaps I am being dense about this point because I do not understand why this is true. We know exactly what instances are in a policy because we evaluated the role table and it was based on the result of the evaluation that we knew which instances the policy was applied to. Additionally when we made the atomic change either via cli or and non-policy enabled SNMP system, the instance that was touched was part of the configuration command. What have I missed. > > 1b) There is the whole question of how / when policies are neforced. if we > consider that policy actions are taken when policy conditions are checked > and verified, we still have the question of when the conditions are > rechecked. If they are rechecked periodically, and if the conditions > include the state of the variable to be changed, then it is quite easy to > see that a human being trying to change an isntance object might find it > continually changing back. He would then need to somehow track down the It is for this reason that I suggested that if an object is brought out of the policy by having a value changed that it be some marked (perhaps in the role table, perhaps elsewhere). The object stays out of the policy until either the big hammer is used and the entire policy is loaded again. This is different than the policy being evaluated again - which will happen on a routine basis in the managed device, how routing we still have not established. You point made me see two things: 1. The element does not need to inform software that realizes the Policy Module when such a change is made. This is true because it is only really relevant when the policy is re-evaluated. The disadvantage of this approach is that some time might lag between the change and the time the notification is sent to the central policy manager. This can be somewhat mitigated by the configuration of informs from the managed object to the management system. This will only work in the case of configuration change notifications built into the basis system outside of any policy. Not common today, but not hard to add in the future. It can be further mitigated, depending on the policy re-evaluation interval. 2. The second point that your comment made me think about is that it is probably wrong to have suggested that the element be moved back into policy when the value that was changed was made the same again through any means other than the policy mechanism. For example if a value of 2 is the policy and a user makes it 3 and then later changes it back to a 2, I suggest that the object is still outside the scope of the policy and should be so marked. The way it becomes a member again is if the value that I have talked about in the role table is deleted, or the entire policy is reloaded - the big hammer approach that I am not real fond of. > policy that is controlling that, and somehow have a way to disable the policy. > 1b') The disabling of the policy is probably only supposed to happen for > some specific instance, not all instances in the box. But one would not > want to have to change the roles attached to an instance just to disable a > policy, would you? Similarly, what happens if the manager sends a new set > of policies? How will those effect this override? I like this idea of disabling parts of the policy. I suggest exactly the same mechanism as I described above. The only difference here is that the human sets an attribute value rather than the software that realizes the Policy MIB Module. > > 1c) There can easily be more than one policy which affects an instance > variable (for example, different policies for different times of day). I > can not see an obvious heuristic for deciding what the operator wants done > with the nighttime policy when he changes a variable and turns off the > daytime policy. This is much harder. My knee jerk reaction that probably is wrong is that the policy that is changed with regard to an element is the one in effect when the change is made. For example if there are two policies a work hours policy and a non-work hours policy and the value of a specific instance of an object is changed during the work hours policy then that object is no longer in the work hours policy. The non-work hours policy applies. > > My own conclusion is that > A) we need to spell out clearly how and when policies take effect and > maintain effect. agreed. proposals are welcome. > B) That most of the rest needs to be left to the structuring of the policy > conditions. For example, one could add a role that is "exempted", and in > all ones policies include "and not exempted". That may not be the best > solution, and we certainly can not mandate it. But trying to solve all of > the interactions in "override are simply impractical. The only alternative > I can see is a COPS-like mechanism where there is no override at all. > I was thinking something along the lines of what you said. An entry would be made in the role, or perhaps other table, that indicates that a policy has be exempted on this instance. That would be sufficient. One problem I have with the COPS-PR model is that it just does not deal with the inevitable fact that people will make micro adjustments other than to reload the entire policy. That could be a very expensive operation. > Yours, > Joel M. Halpern > > At 08:49 AM 6/8/00 -0400, Jon Saperia wrote: >>> General Functional Questions: >>> >>> 1. Should operators be able to override policy? Where is it useful to >>> restrict this in the architecture - fall out issues? >> >> Yes. It is an essential operational component for operators to be able to >> change one or more elements that are under policy control. For the purposes >> of this discussion, an element could be anything from an entire system, >> software that runs on it, or an individual queue on an interface. I do not >> believe we should restrict the ability to override policy in the >> architecture. I believe that this approach raises several issues. I have >> added my suggestions for their resolution - I am sure there may be others. >> >> A. Notification of the change to operators - I believe that a >> notification should be sent from the managed element to the configured >> managers for the system. The notification should contain the following >> information: user, time of change, and the objects that were changed. The >> instance values will be known to the system and would be conveyed to the >> manager as in any other notification. The preferred notification for all of >> our would should be an inform. >> >> B. Where is the override shown on managed system. The managed system >> should reflect this in the status objects contained in the the Policy Table, >> and when an implementation and/or mechanism specific Module is in use, the >> change(s) should be reflected in the relevant status objects contained in >> that modules table. We may want to consider a marking for the Role table so >> show when an element that is under policy control contains one or more >> objects that have other than 'default' values. >> >> C. How long is the override in effect? I recommend until one of two >> events. First, some source outside the policy system changes the value(s) >> back to the defaults. In which case there will no longer be the difference >> detected in point B above. The most common source will be the CLI. Second, a >> policy is reloaded to a system which should override the overrides. >> >> D. What if the override causes a fault or failure in one or more >> operating policies? - I see this as no different than failures under other >> circumstances. The same rules (that we have not yet worked out) should >> apply. > From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 13:42:36 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16021 for ; Fri, 9 Jun 2000 13:42:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA22866 for snmpconf-outgoing; Fri, 9 Jun 2000 13:28:19 -0400 (EDT) Date: Fri, 9 Jun 2000 13:27:45 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Fri, 9 Jun 2000, Jon Saperia wrote: > Perhaps I am being dense about this point because I do not understand why > this is true. We know exactly what instances are in a policy because we > evaluated the role table and it was based on the result of the evaluation > that we knew which instances the policy was applied to. Additionally when > we made the atomic change either via cli or and non-policy enabled SNMP > system, the instance that was touched was part of the configuration command. > What have I missed. In fact, we can probably store policy affected object identifiers in a table and then mark them when they are locally modified. To return that object to its policy based state, we simply remove the marking. The questions then become: * What happens to marked objects if the policy affecting them is removed? Are they removed from the table or do they remain in case the policy affecting them is reinstated? I lean towards the later due to time-based policies, if nothing else. * Do we want to mark local modifications prior to policies being applied? It seems to me that we want to do this as well. So maybe what we really want is a "Don't touch" table of locally configured OIDs and the ability to delete OIDs from that table when the local configuration is no longer relevant? -Matt ---- Matt White Ericsson IP Infrastructure From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 14:08:26 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16493 for ; Fri, 9 Jun 2000 14:08:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA23589 for snmpconf-outgoing; Fri, 9 Jun 2000 13:54:40 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 13:55:52 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: 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 on 06/09/2000 1:27 PM, Matt White at mwhite@torrentnet.com wrote: > In fact, we can probably store policy affected object identifiers in a > table and then mark them when they are locally modified. To return that > object to its policy based state, we simply remove the marking. Yes, I think we are saying the same thing. > > The questions then become: > * What happens to marked objects if the policy affecting them is removed? > Are they removed from the table or do they remain in case the policy > affecting them is reinstated? I lean towards the later due to > time-based policies, if nothing else. I think that the marking must be policy specific due to time. In one of my previous examples, I mentioned the work and non-work hours case. I think the exemption should contain the policyID and description. I know that the ids may get reused, that is why the description is helpful. > * Do we want to mark local modifications prior to policies being applied? > It seems to me that we want to do this as well. I am not sure what this means until an element has been identified as being associated with one or more policies. I think many items could be in the role table and never be in a policy. I think this only becomes interesting after an element has been put under policy control. That said as another part of this working group's activity, we are developing a BCP for configuration in which we suggest that any time a configuration is changed that the information about the change be send to the central manager. Seems like good management practice to me. > > So maybe what we really want is a "Don't touch" table of locally > configured OIDs and the ability to delete OIDs from that table when the > local configuration is no longer relevant? I think the 'don't touch' is an attribute of an element (instance) if it has been placed under policy control and has then been modified by something other than the policy system. The don't touch can only be helpful I think if it is that specific and the don't touch is associated with a policy. What do you think? /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 14:36:53 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16958 for ; Fri, 9 Jun 2000 14:36:51 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA24249 for snmpconf-outgoing; Fri, 9 Jun 2000 14:23:22 -0400 (EDT) Message-Id: <4.2.2.20000609141727.00a87b10@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Jun 2000 14:20:57 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: References: 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 It may be as straight-forward as you and Jon suggest. But, somehow, I can see ending up in interesting states. For example, using the daytime / nighttime case, someone overrides the current (daytime) policy on some instance. It becomes night, and the nighttime policy takes effect. It was not overriden. Then, it is no longer nighttime. But, the daytime policy is still overriden. So the instances remains set as the nighttime policy specified? That is unlikely to be the desired effect. But I tend to strongly shy away from policies which can unwind themselves to "previous" states where those are unspecified. The obvious alternative is that if an object is touched manually, then it is blocked from policy. Or maybe only from policies which were already in the box when the attribute was changed? Still looks complicated to me. Yours, Joel At 01:27 PM 6/9/00 -0400, Matt White wrote: >On Fri, 9 Jun 2000, Jon Saperia wrote: > > > Perhaps I am being dense about this point because I do not understand why > > this is true. We know exactly what instances are in a policy because we > > evaluated the role table and it was based on the result of the evaluation > > that we knew which instances the policy was applied to. Additionally when > > we made the atomic change either via cli or and non-policy enabled SNMP > > system, the instance that was touched was part of the configuration > command. > > What have I missed. > >In fact, we can probably store policy affected object identifiers in a >table and then mark them when they are locally modified. To return that >object to its policy based state, we simply remove the marking. > >The questions then become: >* What happens to marked objects if the policy affecting them is removed? > Are they removed from the table or do they remain in case the policy > affecting them is reinstated? I lean towards the later due to > time-based policies, if nothing else. >* Do we want to mark local modifications prior to policies being applied? > It seems to me that we want to do this as well. > >So maybe what we really want is a "Don't touch" table of locally >configured OIDs and the ability to delete OIDs from that table when the >local configuration is no longer relevant? > > >-Matt >---- >Matt White >Ericsson IP Infrastructure From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 14:47:06 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17142 for ; Fri, 9 Jun 2000 14:47:05 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA24595 for snmpconf-outgoing; Fri, 9 Jun 2000 14:33:08 -0400 (EDT) From: Dale Francisco Message-Id: <200006091832.LAA23652@itech-view2.cisco.com> Subject: Re: snmpconf General Functional Questions To: snmpconf@snmp.com Date: Fri, 9 Jun 2000 11:32:34 -0700 (PDT) In-Reply-To: <4.2.2.20000609141727.00a87b10@omniplex.mcquillan.com> from "Joel M. Halpern" at Jun 09, 2000 02:20:57 PM X-Mailer: ELM [version 2.5 PL1] 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 I think most of the override scenarios will revolve around debugging and firefighting. If an instance really needs to remain in an "override" state for a long time, then the policy itself needs to change. For simplicity, it seems to me that once a manual override happens, the instance variable has to stay in its new state until the manual override is manually removed. Dale > > It may be as straight-forward as you and Jon suggest. > But, somehow, I can see ending up in interesting states. > > For example, using the daytime / nighttime case, someone overrides the > current (daytime) policy on some instance. It becomes night, and the > nighttime policy takes effect. It was not overriden. Then, it is no > longer nighttime. But, the daytime policy is still overriden. So the > instances remains set as the nighttime policy specified? That is unlikely > to be the desired effect. But I tend to strongly shy away from policies > which can unwind themselves to "previous" states where those are unspecified. > > The obvious alternative is that if an object is touched manually, then it > is blocked from policy. Or maybe only from policies which were already in > the box when the attribute was changed? > Still looks complicated to me. > > Yours, > Joel From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 14:57:19 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17310 for ; Fri, 9 Jun 2000 14:57:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA24875 for snmpconf-outgoing; Fri, 9 Jun 2000 14:43:48 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 14:44:43 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <200006091832.LAA23652@itech-view2.cisco.com> 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 on 06/09/2000 2:32 PM, Dale Francisco at dfrancis@cisco.com wrote: > I think most of the override scenarios will revolve > around debugging and firefighting. If an instance > really needs to remain in an "override" state for > a long time, then the policy itself needs to change. > This is probably true. I think the way this would work is either by rewriting the policyFilter or by changing the role(s) for the elements that one does not want in the policy any more. > For simplicity, it seems to me that once a manual > override happens, the instance variable has to stay > in its new state until the manual override > is manually removed. > > Yes, I think so. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 15:02:56 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17470 for ; Fri, 9 Jun 2000 15:02:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA24995 for snmpconf-outgoing; Fri, 9 Jun 2000 14:47:47 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC955@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Cc: "rap (E-mail)" Subject: RE: snmpconf General Functional Questions Date: Fri, 9 Jun 2000 11:43:47 -0700 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 We dived into this can of worms with COPS-PR. We very quickly swam to the edge of the can and got out again and declared (a) time-of-day in the device and (b) multiple managers, to be out of scope. Yes, this limits the areas of application of the protocol but it does make it implementable and deployable. Andrew > -----Original Message----- > From: Joel M. Halpern [mailto:joel@mcquillan.com] > Sent: Friday, June 09, 2000 11:21 AM > To: snmpconf@snmp.com > Subject: Re: snmpconf General Functional Questions > > > It may be as straight-forward as you and Jon suggest. > But, somehow, I can see ending up in interesting states. > > For example, using the daytime / nighttime case, someone > overrides the > current (daytime) policy on some instance. It becomes night, and the > nighttime policy takes effect. It was not overriden. Then, it is no > longer nighttime. But, the daytime policy is still > overriden. So the > instances remains set as the nighttime policy specified? > That is unlikely > to be the desired effect. But I tend to strongly shy away > from policies > which can unwind themselves to "previous" states where those > are unspecified. > > The obvious alternative is that if an object is touched > manually, then it > is blocked from policy. Or maybe only from policies which > were already in > the box when the attribute was changed? > Still looks complicated to me. > > Yours, > Joel > > At 01:27 PM 6/9/00 -0400, Matt White wrote: > >On Fri, 9 Jun 2000, Jon Saperia wrote: > > > > > Perhaps I am being dense about this point because I do > not understand why > > > this is true. We know exactly what instances are in a > policy because we > > > evaluated the role table and it was based on the result > of the evaluation > > > that we knew which instances the policy was applied to. > Additionally when > > > we made the atomic change either via cli or and > non-policy enabled SNMP > > > system, the instance that was touched was part of the > configuration > > command. > > > What have I missed. > > > >In fact, we can probably store policy affected object > identifiers in a > >table and then mark them when they are locally modified. To > return that > >object to its policy based state, we simply remove the marking. > > > >The questions then become: > >* What happens to marked objects if the policy affecting > them is removed? > > Are they removed from the table or do they remain in > case the policy > > affecting them is reinstated? I lean towards the later due to > > time-based policies, if nothing else. > >* Do we want to mark local modifications prior to policies > being applied? > > It seems to me that we want to do this as well. > > > >So maybe what we really want is a "Don't touch" table of locally > >configured OIDs and the ability to delete OIDs from that > table when the > >local configuration is no longer relevant? > > > > > >-Matt > >---- > >Matt White > >Ericsson IP Infrastructure > From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 15:06:38 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17533 for ; Fri, 9 Jun 2000 15:06:38 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA25144 for snmpconf-outgoing; Fri, 9 Jun 2000 14:53:01 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 14:52:45 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000609141727.00a87b10@omniplex.mcquillan.com> 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 on 06/09/2000 2:20 PM, Joel M. Halpern at joel@mcquillan.com wrote: > It may be as straight-forward as you and Jon suggest. > But, somehow, I can see ending up in interesting states. > > For example, using the daytime / nighttime case, someone overrides the > current (daytime) policy on some instance. It becomes night, and the > nighttime policy takes effect. It was not overriden. Then, it is no > longer nighttime. But, the daytime policy is still overriden. So the > instances remains set as the nighttime policy specified? That is unlikely > to be the desired effect. But I tend to strongly shy away from policies > which can unwind themselves to "previous" states where those are unspecified. > > The obvious alternative is that if an object is touched manually, then it > is blocked from policy. Or maybe only from policies which were already in > the box when the attribute was changed? > Still looks complicated to me. You may be winning me over. What would you say to a rule: If an element under policy control has any attribute (read MIB Object) changed that is under policy control, then it has the exemption bit set that Matt and I wrote about (the don't touch bit) set. It remains in this state until manually changed back. Dale made a good point that is at some point the policy might need to change. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 15:37:39 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17915 for ; Fri, 9 Jun 2000 15:37:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA25899 for snmpconf-outgoing; Fri, 9 Jun 2000 15:23:47 -0400 (EDT) From: avri.doria@nokia.com Message-ID: To: snmpconf@snmp.com Subject: RE: snmpconf General Functional Questions Date: Fri, 9 Jun 2000 14:19:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com A question about the rule, > > You may be winning me over. What would you say to a rule: > > If an element under policy control has any attribute (read MIB Object) > changed that is under policy control, then it has the > exemption bit set that > Matt and I wrote about (the don't touch bit) set. It remains > in this state > until manually changed back. Dale made a good point that is > at some point > the policy might need to change. Is the policy system informed in some way of the changed attribute and especially of the setting of the exemption bit for the attribute? Or does this rely on human intervention for notification. Also, it seems that it should be possible to reset the exemption bit either manually or via a policy and thus put the attribute back under policy control without having to actually go and manually change it again. a. > From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 15:51:50 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18129 for ; Fri, 9 Jun 2000 15:51:50 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA26266 for snmpconf-outgoing; Fri, 9 Jun 2000 15:37:13 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 15:38:01 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: CC: "rap (E-mail)" Message-ID: In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC955@SOL> 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 on 06/09/2000 2:43 PM, Andrew Smith at andrew@extremenetworks.com wrote: > We dived into this can of worms with COPS-PR. We very quickly swam to the > edge of the can and got out again and declared (a) time-of-day in the device > and (b) multiple managers, to be out of scope. Yes, this limits the areas of > application of the protocol but it does make it implementable and > deployable. I can see how putting these items out of scope of that work does simplify things. I hope we can take a middle ground in terms of assumptions and yet get a good improvement. For example, by allowing for the 'override' but not attempting to roll back and keeping the element 'exempted' once a value has been overridden. One tool that we do have that may make it more reasonable is that we do have access and visibility into the instance specific data. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 15:57:15 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18184 for ; Fri, 9 Jun 2000 15:57:15 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA26443 for snmpconf-outgoing; Fri, 9 Jun 2000 15:45:06 -0400 (EDT) Message-Id: <4.2.2.20000609153559.00b14a40@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 09 Jun 2000 15:42:49 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: References: <4.2.2.20000609141727.00a87b10@omniplex.mcquillan.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 This is an implementable, well defined behavior. I could live with it. It would be nice if the implementation were simpler than I imagine, so let me describe what I think the implementation effect is: 1) There is a table of objects for which the "do not touch" bit has been set. When policy actions are being considered, such objects may not be effected. [This relates to the question of failures of policies which effect several related objects. TBD.] This table probably should be SNMP visible. 2) There must be a table (whether visible to SNMP or not) or all elements which have actually been touched by policy. [Removal of entries from this table must be tied to the maintenance of policy and the removal mechanisms for policy. It may need to know which policies touched the object to handle policy removal). 3) When an object is manipulated directly using low level mechanisms (CLI, SNMP, ...) the table in (2) is checked. If the object is in said table, then an entry is made in the table in (1). This does seem to require updating the direct manipulation subsystem when policy is added, which is unfortunate, but probably inevitable. Yours, Joel M. Halpern At 02:52 PM 6/9/00 -0400, Jon Saperia wrote: >If an element under policy control has any attribute (read MIB Object) >changed that is under policy control, then it has the exemption bit set that >Matt and I wrote about (the don't touch bit) set. It remains in this state >until manually changed back. Dale made a good point that is at some point >the policy might need to change. From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 16:18:08 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18391 for ; Fri, 9 Jun 2000 16:18:07 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA26977 for snmpconf-outgoing; Fri, 9 Jun 2000 16:00:07 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC95D@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Subject: RE: snmpconf General Functional Questions Date: Fri, 9 Jun 2000 12:56:06 -0700 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 > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Friday, June 09, 2000 12:38 PM > To: snmpconf@snmp.com > Cc: rap (E-mail) > Subject: Re: snmpconf General Functional Questions ... > I hope we can take a middle ground in terms of > assumptions and yet get a good improvement. That would be good. Some modularity would help here - only force the complexity on those that need to use the capabilities. Andrew From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 16:18:32 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18413 for ; Fri, 9 Jun 2000 16:18:32 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id QAA27100 for snmpconf-outgoing; Fri, 9 Jun 2000 16:04:15 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC95E@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Subject: RE: snmpconf General Functional Questions Date: Fri, 9 Jun 2000 13:00:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com And, as Avri hinted, table (1) does need to be SNMP-writeable to satisfy the operational requirement of not having to go visit the wiring-closet again to restore things to normality [you have to make the assumption that suitable authentication is in force: only authorised people/tools are allowed to change things at both SNMP manager and local interface]. Andrew > -----Original Message----- > From: Joel M. Halpern [mailto:joel@mcquillan.com] > Sent: Friday, June 09, 2000 12:43 PM > To: snmpconf@snmp.com > Subject: Re: snmpconf General Functional Questions > > > This is an implementable, well defined behavior. I could > live with it. > > It would be nice if the implementation were simpler than I > imagine, so let > me describe what I think the implementation effect is: > 1) There is a table of objects for which the "do not touch" > bit has been > set. When policy actions are being considered, such objects > may not be > effected. [This relates to the question of failures of > policies which > effect several related objects. TBD.] This table probably > should be SNMP > visible. > 2) There must be a table (whether visible to SNMP or not) or > all elements > which have actually been touched by policy. [Removal of > entries from this > table must be tied to the maintenance of policy and the > removal mechanisms > for policy. It may need to know which policies touched the object to > handle policy removal). > 3) When an object is manipulated directly using low level > mechanisms (CLI, > SNMP, ...) the table in (2) is checked. If the object is in > said table, > then an entry is made in the table in (1). > > This does seem to require updating the direct manipulation > subsystem when > policy is added, which is unfortunate, but probably inevitable. > > Yours, > Joel M. Halpern > > At 02:52 PM 6/9/00 -0400, Jon Saperia wrote: > >If an element under policy control has any attribute (read > MIB Object) > >changed that is under policy control, then it has the > exemption bit set that > >Matt and I wrote about (the don't touch bit) set. It remains > in this state > >until manually changed back. Dale made a good point that is > at some point > >the policy might need to change. > From owner-snmpconf@seymour39.SNMP.COM Fri Jun 9 16:48:13 2000 Received: from seymour39.SNMP.COM ([192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18708 for ; Fri, 9 Jun 2000 16:48:13 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA28294 for snmpconf-outgoing; Fri, 9 Jun 2000 16:34:09 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 09 Jun 2000 16:34:56 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC95E@SOL> 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 on 06/09/2000 4:00 PM, Andrew Smith at andrew@extremenetworks.com wrote: > And, as Avri hinted, table (1) does need to be SNMP-writeable to satisfy the > operational requirement of not having to go visit the wiring-closet again to > restore things to normality [you have to make the assumption that suitable > authentication is in force: only authorised people/tools are allowed to > change things at both SNMP manager and local interface]. > > Andrew > Sure. The table that I have been suggesting is our Role table. I do not think we need another and that seems like the right place for it. If we do that we meet the SNMP access rule. I seem to have missed a note by Avri so I do not know what he said. >> -----Original Message----- >> From: Joel M. Halpern [mailto:joel@mcquillan.com] >> Sent: Friday, June 09, 2000 12:43 PM >> To: snmpconf@snmp.com >> Subject: Re: snmpconf General Functional Questions >> >> >> This is an implementable, well defined behavior. I could >> live with it. >> >> It would be nice if the implementation were simpler than I imagine, so let me >> describe what I think the implementation effect is: 1) There is a table of >> objects for which the "do not touch" bit has been set. When policy actions >> are being considered, such objects may not be effected. [This relates to the >> question of failures of policies which effect several related objects. TBD.] >> This table probably should be SNMP visible. We are in agreement. For me this is the Role table. >> 2) There must be a table (whether visible to SNMP or not) or >> all elements >> which have actually been touched by policy. [Removal of >> entries from this >> table must be tied to the maintenance of policy and the >> removal mechanisms >> for policy. It may need to know which policies touched the object to >> handle policy removal). >> 3) When an object is manipulated directly using low level >> mechanisms (CLI, >> SNMP, ...) the table in (2) is checked. If the object is in >> said table, >> then an entry is made in the table in (1). >> >> This does seem to require updating the direct manipulation >> subsystem when >> policy is added, which is unfortunate, but probably inevitable. >> I agree. It is also true that many new systems are being developed such that the CLI and SNMP infrastructures are more closely integrated - that is a change by the CLI would be known by the SNMP infrastructure. There are important reasons for doing this beyond the policy management problem. For those vendors with other types of implementations connections can be made but they are not quite so clean. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 04:06:30 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 EAA26835 for ; Mon, 12 Jun 2000 04:06:30 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA28273 for snmpconf-outgoing; Mon, 12 Jun 2000 03:49:41 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA61412855C@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Cc: "rap (E-mail)" Subject: RE: snmpconf General Functional Questions Date: Mon, 12 Jun 2000 10:46:45 +0200 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 Jon, I think that making the solution TOO simple, may result it in being implementable and deployable, but not useful. We probably agree on this. However, I do not understand your example about the 'exempted' element. Do you mean that once a value was overridden, the respective instance can't be touched any longer, until the 'touch' bit in Joel's second table is cleared? Who clears this table? Regards, Dan > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Fri June 09 2000 21:38 > To: snmpconf@snmp.com > Cc: rap (E-mail) > Subject: Re: snmpconf General Functional Questions > > on 06/09/2000 2:43 PM, Andrew Smith at andrew@extremenetworks.com wrote: > > > We dived into this can of worms with COPS-PR. We very quickly swam to > the > > edge of the can and got out again and declared (a) time-of-day in the > device > > and (b) multiple managers, to be out of scope. Yes, this limits the > areas of > > application of the protocol but it does make it implementable and > > deployable. > > I can see how putting these items out of scope of that work does simplify > things. I hope we can take a middle ground in terms of assumptions and yet > get a good improvement. For example, by allowing for the 'override' but > not > attempting to roll back and keeping the element 'exempted' once a value > has > been overridden. One tool that we do have that may make it more reasonable > is that we do have access and visibility into the instance specific data. > > /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 08:24: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 IAA29757 for ; Mon, 12 Jun 2000 08:24:25 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA02841 for snmpconf-outgoing; Mon, 12 Jun 2000 08:09:40 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 12 Jun 2000 08:10:40 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: CC: "rap (E-mail)" Message-ID: In-Reply-To: <15F58915DF84D311AC7D0090279AA61412855C@ITC-EML2> 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 on 06/12/2000 4:46 AM, Dan Romascanu at dromasca@lucent.com wrote: > Jon, > > I think that making the solution TOO simple, may result it in being > implementable and deployable, but not useful. We probably agree on this. I think we do. > > However, I do not understand your example about the 'exempted' element. Do > you mean that once a value was overridden, the respective instance can't be > touched any longer, until the 'touch' bit in Joel's second table is cleared? > Who clears this table? > I mean that the respective instance will be skipped each time a policy is evaluated in the device that 'touches' that instance. This is like adding another attribute/role to the instance that causes it to 'fail' the role match in our system. This is how the policy system will know how to exempt it. The attribute might be the 'exempt' attribute. It would have been placed there if that instance had been touched by a mechanism other than the policy system, for example a CLI, web interface, or a non-policy SNMP manager. The way this works is that the policy system has access to the instances by definition. It also knows if it changed a value or not. I have not heard any objection to using the role table, so I assume for now that is where this attribute is stored though that is not very important. Once set the only way to reset it is by direct action on this attribute for this instance. In an SNMP case the manager would sent a set to remove the attribute. Certainly we have experience with enabling CLI's to have access to such objects and I would have the CLI also able to remove this attribute. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 12:19:31 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 MAA05734 for ; Mon, 12 Jun 2000 12:19:31 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA10406 for snmpconf-outgoing; Mon, 12 Jun 2000 12:02:34 -0400 (EDT) Date: Mon, 12 Jun 2000 12:01:59 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Fri, 9 Jun 2000, Jon Saperia wrote: > > So maybe what we really want is a "Don't touch" table of locally > > configured OIDs and the ability to delete OIDs from that table when the > > local configuration is no longer relevant? > > I think the 'don't touch' is an attribute of an element (instance) if it has > been placed under policy control and has then been modified by something > other than the policy system. The don't touch can only be helpful I think if > it is that specific and the don't touch is associated with a policy. What do > you think? The problem is what happens if an element is locally modified and then put under policy control? I don't think we want to allow policies to overwrite existing explicit (manual) configuration when they are first instantiated. The way I view this is that, at any given time, there will be some number of policies being enforced on a device. These policies will conflict with eachother (that seems unavoidable). We need a mechanism for resolving this conflict regardless. Now, if we view manual configuration as a "policy" of the highest priority, the conflict resolution mechanism that we already need can be used to give us the behaviour that we want. So, what I suggest is a table of OIDs and RowPointers to the policies that are modifying them (there can be multiple policies per OID). Manual configuration can be a special policy that always exists. Each policy then has a priority assigned to it that is used to determine which policy of the conflicting policies take effect. -Matt Matt White Ericsson IP Infrastructure From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 13:03:54 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 NAA06887 for ; Mon, 12 Jun 2000 13:03:54 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA11860 for snmpconf-outgoing; Mon, 12 Jun 2000 12:49:25 -0400 (EDT) Message-ID: <3945142A.D63A91BF@enterasys.com> Date: Mon, 12 Jun 2000 12:47:38 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: 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 Matt White wrote: > > The problem is what happens if an element is locally modified and then put > under policy control? I don't think we want to allow policies to > overwrite existing explicit (manual) configuration when they are first > instantiated. > If I understand correctly what you are arguing for, I think we do want to allow policies to override existing manual configuration when they are first instantiated. The purpose of putting something under policy control is to standardize the application of the policy throughout the system. When we first apply policy, we must assume that there is a desire to apply the policy to all appropriate elements, and we do not necessarily know the current state of the target elements. If we want something exempted from the standard policy, it should identified in the policy or in a higher-priority policy. If manual configuration occurs AFTER the policy has been applied, then that manual configuration should be a higher priority until the "touch-bit" has been cleared (or it is otherwise configured to resume standard policy). Iy may be that you are saying that once a manual configuration has been "logged" in the table being proposed to identify overrides (so that we do understand the current state of the element), then we don't want newly-instantiated policies to override the "logged" override, then I agree with you. dbh -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 13:11: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 NAA07088 for ; Mon, 12 Jun 2000 13:11:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA11924 for snmpconf-outgoing; Mon, 12 Jun 2000 12:51:33 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 12 Jun 2000 12:52:33 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: 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 on 06/12/2000 12:01 PM, Matt White at mwhite@torrentnet.com wrote: > The problem is what happens if an element is locally modified and then put > under policy control? I don't think we want to allow policies to > overwrite existing explicit (manual) configuration when they are first > instantiated. This is a good point and a bit of the chicken and egg problem. In an earlier posting I said another way to override a manual selection in addition to the one we have been discussing is to reload the policy. It seems this is an explicit user directed method. This is important since I agree we do not want to overwrite existing explicit manual configuration. That is why I also suggested that manual intervention on the role table is required in the case of an object that has been overridden by manual change. The meaning of reload (as opposed to update) policy is the same as first time load. I think these times, by definition you want to override manual settings. Remember that manual overrides can be added and maintained indefinitely as needed. Of course a policy full of manual overrides probably should not be a policy. > > The way I view this is that, at any given time, there will be some number > of policies being enforced on a device. These policies will conflict with > eachother (that seems unavoidable). We need a mechanism for resolving > this conflict regardless. Now, if we view manual configuration as a > "policy" of the highest priority, the conflict resolution mechanism that > we already need can be used to give us the behaviour that we want. > > So, what I suggest is a table of OIDs and RowPointers to the policies that > are modifying them (there can be multiple policies per OID). Manual > configuration can be a special policy that always exists. Each policy > then has a priority assigned to it that is used to determine which policy > of the conflicting policies take effect. I had not thought about the current mechanism as a conflict related one until you pointed it out. I do not want to start the general conflict discussion in this thread, so perhaps another separate email. I am not clear what OIDS you reference here, OIDs of the modified instances? Lets make this a separate thread. In a day or so, I will try to consolidate what we have discussed with regard to overrides. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 12 13:34: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 NAA07549 for ; Mon, 12 Jun 2000 13:34:27 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA12568 for snmpconf-outgoing; Mon, 12 Jun 2000 13:17:09 -0400 (EDT) Message-ID: <39451AAA.B44E91F8@enterasys.com> Date: Mon, 12 Jun 2000 13:15:22 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: 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, I think the exempt bit needs to be instance-specific, to tell which instance has been overridden. If the "touch-bit" can be cleared via SNMP, it will be important to know WHICH instance should be cleared if there are multiple instances that have been touched. It may also be important for tracking down a security breach to expose which instance was changed. Having the "touch-bit" at the role-abstraction level doesn't allow the necessary granularity. I think it might be nice to have a dirty-flag at the role level, to easily indicate that one or more instances of the role have been overridden. However, I am concerned that having the touch-bit at this level may be problematic. It may be difficult to go from the instance level to the role level easily, as has been discussed. This becomes harder in a mid-level manager situation, where the role evaluation may be done within a different engine, as discussed at the interim meeting. dbh Jon Saperia wrote: > > on 06/12/2000 4:46 AM, Dan Romascanu at dromasca@lucent.com wrote: > > > Jon, > > > > I think that making the solution TOO simple, may result it in being > > implementable and deployable, but not useful. We probably agree on this. > > I think we do. > > > > However, I do not understand your example about the 'exempted' element. Do > > you mean that once a value was overridden, the respective instance can't be > > touched any longer, until the 'touch' bit in Joel's second table is cleared? > > Who clears this table? > > > I mean that the respective instance will be skipped each time a policy is > evaluated in the device that 'touches' that instance. This is like adding > another attribute/role to the instance that causes it to 'fail' the role > match in our system. This is how the policy system will know how to exempt > it. The attribute might be the 'exempt' attribute. It would have been placed > there if that instance had been touched by a mechanism other than the policy > system, for example a CLI, web interface, or a non-policy SNMP manager. The > way this works is that the policy system has access to the instances by > definition. It also knows if it changed a value or not. > > I have not heard any objection to using the role table, so I assume for now > that is where this attribute is stored though that is not very important. > Once set the only way to reset it is by direct action on this attribute for > this instance. In an SNMP case the manager would sent a set to remove the > attribute. Certainly we have experience with enabling CLI's to have access > to such objects and I would have the CLI also able to remove this attribute. > > /jon -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Wed Jun 14 09:33: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 JAA20016 for ; Wed, 14 Jun 2000 09:33:38 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA18707 for snmpconf-outgoing; Wed, 14 Jun 2000 09:16:22 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 14 Jun 2000 09:15:47 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <39451AAA.B44E91F8@enterasys.com> 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 on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote: > Hi, > > I think the exempt bit needs to be instance-specific, to tell which > instance has been overridden. If the "touch-bit" can be cleared via > SNMP, it will be important to know WHICH instance should be cleared if > there are multiple instances that have been touched. Exactly so. We are all in agreement on this point. That is why I have proposed using the role table which is instance specific. > > It may also be important for tracking down a security breach to expose > which instance was changed. > > Having the "touch-bit" at the role-abstraction level doesn't allow the > necessary granularity. I think it might be nice to have a dirty-flag at > the role level, to easily indicate that one or more instances of the > role have been overridden. However, I am concerned that having the > touch-bit at this level may be problematic. It may be difficult to go > from the instance level to the role level easily, as has been discussed. > This becomes harder in a mid-level manager situation, where the role > evaluation may be done within a different engine, as discussed at the > interim meeting. > PmRoleESEntry ::= SEQUENCE { pmRoleESElement RowPointer, pmRoleESString SnmpAdminString, pmRoleESStatus RowStatus } Roles are assigned on an instance specific basis. That is the only way the local mechanisms can know were to apply the policy. I do not see the role evaluation taking place remotely. One a large machine with many interfaces and/or S/PVCs numbering into the many hundreds of thousands, the evaluation has to be done locally. This does not mean that a MLM can not participate since the MLM application would send the policy filters to the targets for evaluation. I propose that the pmRoleESStatus be the place for the dirty bit. If that is not acceptable, another object in this table. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 15 14:03:35 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 OAA10580 for ; Thu, 15 Jun 2000 14:03:34 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA12237 for snmpconf-outgoing; Thu, 15 Jun 2000 13:45:38 -0400 (EDT) Message-ID: <394915C3.5165AE15@enterasys.com> Date: Thu, 15 Jun 2000 13:43:31 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: 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, comments inline. dbh > Jon Saperia wrote: > > on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote: > > > Hi, > > > > I think the exempt bit needs to be instance-specific, to tell which > > instance has been overridden. If the "touch-bit" can be cleared via > > SNMP, it will be important to know WHICH instance should be cleared > if > > there are multiple instances that have been touched. > > Exactly so. We are all in agreement on this point. That is why I have > proposed using the role table which is instance specific. OK. I see my mistake. I read the text, which is ambiguous, and missed the implications of the RowPointer type. The role table is element-specific, with a pointer to a row of instances. Hence, knowing the row that managed object instance is in, you can derive the affected elements. The text is very ambiguous, and could stand tightening - "An element is a group of related MIB variables such as all the variables for interface#7." A group isn't necessarily a row, although a row is certainly a group. One row typically will not contain "all the variables" related to interface#7. Since element and row seem interchangeable here, why don't we just call it a row, pmRoleESRow or pmRoleESRowPointer, rather than an element, to reduce the indirection? Can I manage scalars within the scope of an element? i.e. SET function_enable=true? Is that just a row with length=1? RowPointer with instance 0? If I have an element pointing to a row, and I dynamically instatiate an AUGMENTing table, does the element now relate to the new objects as well? A role can presumably be related to multiple rows in different tables using multiple entries. If I have multiple ATM Permanent Virtual Circuits (I'm allowed to model circuits as elements), and each circuit requires multiple entries in the role table to point to the related variables, we end up with a potentially large number of rows in these tables for each circuit. We have a potentially huge number of rows for a whole device. Should we have some scalars or row objects that help to diminish the work necessary to determine what has changed? e.g. TimeFilter, or LastChanged, etc.? While notifications may help on this, it may also be necessary to poll sometimes, such as when a manager reboots. The search of these huge tables will need to be done for every command to modify an attribute, whether done by SNMP SET or CLI modify-command or COPS policy-dump, in order to set the dirty bit. This seems unreasonably high overhead for every modify command. > > > > It may also be important for tracking down a security breach to > expose > > which instance was changed. > > > > Having the "touch-bit" at the role-abstraction level doesn't allow > the > > necessary granularity. I think it might be nice to have a dirty-flag > at > > the role level, to easily indicate that one or more instances of the > > > role have been overridden. However, I am concerned that having the > > touch-bit at this level may be problematic. It may be difficult to > go > > from the instance level to the role level easily, as has been > discussed. > > This becomes harder in a mid-level manager situation, where the role > > > evaluation may be done within a different engine, as discussed at > the > > interim meeting. > > > > PmRoleESEntry ::= SEQUENCE { > pmRoleESElement RowPointer, > pmRoleESString SnmpAdminString, > pmRoleESStatus RowStatus > } > > Roles are assigned on an instance specific basis. > That is the only way > the > local mechanisms can know were to apply the policy. > I do not see the > role > evaluation taking place remotely. One a large machine with many > interfaces > and/or S/PVCs numbering into the many hundreds of thousands, the > evaluation > has to be done locally. It would certainly make sense to do so locally for performance reasons. Are you suggesting the document say that it MUST be done locally? For a legacy device without a policy engine, I might like to use a MLM to evaluate the conditions and perform the resulting SETs from the MLM. Certainly there will be issues of performance, and I may have to write my actions carefully to be sure one SET doesn't prevent subsequent SETS in the same action, but as far as I know, it is allowed, isn't it? Given the potential size of the role tables, and the limited NVRAM on many devices, and the CPU load imposed by searching these huge tables, I can definitely see a need for an MLM to process role evaluation to help offload these tables and processing. If it is allowed, then how does a SET to a managed object instance on remote row/element X by another management application get reflected in the entry for row/elementX in the role table in the MLM? Obviously notifications could help here, but are they adequate? For legacy devices, the notify-on-attribute-value-change functionality won't exist. > This does not mean that a MLM can not > participate > since the MLM application would send the policy filters to the targets > for > evaluation. > > I propose that the pmRoleESStatus be the place for the dirty bit. pmRoleESStatus is a RowStatus variable. I would think it not a good design to mix these two purposes. How would you mark a status of "active AND dirty" and stay within the enumerations of RowStatus? > If > that is > not acceptable, another object in this table. Yup. additional objects in these tables. > > /jon -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Mon Jun 19 09:26: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 JAA04570 for ; Mon, 19 Jun 2000 09:26:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA01149 for snmpconf-outgoing; Mon, 19 Jun 2000 08:57:21 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 19 Jun 2000 08:56:52 -0400 Subject: snmpconf Interesting Hotel Update From: Jon Saperia To: snmpconf , Dave Harrington Message-ID: 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 I must have missed the announcement for the Hotel Registration opening so I made my reservations this AM. The reason for posting to this list is that the IETF page now needs to be updated. The first two hotels told me there were no rooms available at any price for most of the nights needed. This includes the Friday night for those planning to stay over for the Interim Meeting. The third hotel, the Hilton Pittsburgh and Towers, does have rooms, but at least three of the nights during the week will be at a higher rate of 189.00. If you are planning on attending, and have not made your reservations you should do so ASAP. I will be on the road for much of this week. Dave Harrington is working on details for the Interim. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 19 15:22: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 PAA21146 for ; Mon, 19 Jun 2000 15:22:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA13253 for snmpconf-outgoing; Mon, 19 Jun 2000 15:08:23 -0400 (EDT) Date: Mon, 19 Jun 2000 15:07:48 -0400 (EDT) From: Matt White To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com On Wed, 14 Jun 2000, Jon Saperia wrote: > PmRoleESEntry ::= SEQUENCE { > pmRoleESElement RowPointer, > pmRoleESString SnmpAdminString, > pmRoleESStatus RowStatus > } > > I propose that the pmRoleESStatus be the place for the dirty bit. If that is > not acceptable, another object in this table. While this would work, I think I would prefer to look at the precedence issue first. We may come up with a solution to that problem that lends itself well to solving the manual configuration problem. Or we may not, but I'd at least like to see where that goes before we lock ourselves into a solution to this problem. -Matt From owner-snmpconf@seymour39.SNMP.COM Thu Jun 22 10:39:23 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 KAA06936 for ; Thu, 22 Jun 2000 10:39:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA15991 for snmpconf-outgoing; Thu, 22 Jun 2000 10:19:01 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 22 Jun 2000 10:18:35 -0400 Subject: snmpconf Conflict Resolution Issues From: Jon Saperia To: snmpconf Message-ID: 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 Here is the second in the group of issues that came out of our interim meeting. As before, I will put in my suggestions/thoughts where I have an opinion. Conflict Resolution Issues: 1. How do we deal with intentional and unintended conflicts. It is hard to tell between intentional and unintended conflicts between policies. My suggestion is that this function be left to the policy application function and not the managed element software. 2. Is conflict detection or resolution a goal? Both are hard. Unless someone has a specific proposal, I suggest that we omit this capability or recommend that it be left to the ingenuity of the equipment or manager software developers. 3. What happens when a policy is deleted? What if anything do you revert to? In the case of DIFFSERV, I do not see much of a problem since the traffic that would have been treated will in systems I know about, pass through the system subject to the same 'rules' as the rest of the traffic. The problem is for other types of policy. For example; a policy that causes the configuration of primary and secondary DNS servers. If the policy is removed, the systems could be left without knowing where to send DNS requests. I do not think we want to have the managed elements keep a scratch pad either (though some may choose to do this for a number of reasons - and we should not prohibit this). My suggestion is that we recommend in the BCP that policy managers that delete a policy, replace it with a default if appropriate or the parameters that existed prior to the installation of this policy. This will be a difficult problem to solve. 4. How many errors are acceptable in a policy? How are they reported? Just as with the override of policy, failures should be reported on a per instance basis. That is, if 5 instances fail a status object in the role table that indicates a policy that includes this instance based on the evaluation of the policy filter is not in force. This time the reason is a failure as opposed to an override. There is probably no need for a second object since the status can not both be failed and overridden. A notification should be sent in such failure situations only when the policy is first evaluated, not each time the policy is locally evaluated. Beyond a managed elements requirements for consistency, we could create another object that could deal with this, but it is probably best left to the management application. The management application would also be the place to determine if a particular value for a MIB Object under policy control is outside of a policy range which would be helpful. Particular instances may be tweaked that are under policy control due to a number of conditions. 5. What happens when a configured element breaks that is executing a policy? The object that reflects the element status in the role table should be updated and a notification sent. The policy ID should be part of all such notifications for override, failures on initial evaluation/set up and subsequent failures. [end of list] From owner-snmpconf@seymour39.SNMP.COM Thu Jun 22 14:09:16 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 OAA11950 for ; Thu, 22 Jun 2000 14:09:15 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA21083 for snmpconf-outgoing; Thu, 22 Jun 2000 13:52:17 -0400 (EDT) Message-ID: <39525225.3F13B21B@enterasys.com> Date: Thu, 22 Jun 2000 13:51:33 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Conflict Resolution Issues References: 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 Jon Saperia wrote: > > Here is the second in the group of issues that came out of our interim > meeting. > > As before, I will put in my suggestions/thoughts where I have an opinion. > > Conflict Resolution Issues: > > 1. How do we deal with intentional and unintended conflicts. > > It is hard to tell between intentional and unintended conflicts between > policies. Agreed. I don't think it is significant for us to differentiate these. > My suggestion is that this function be left to the policy > application function and not the managed element software. When you say "this function", do you mean the differentiation of intended vs. unintended, or the resolution of conflicts? > > 2. Is conflict detection or resolution a goal? > > Both are hard. Unless someone has a specific proposal, I suggest that we > omit this capability or recommend that it be left to the ingenuity of the > equipment or manager software developers. I think it needs to be a goal to detect conflict and we should decide how it should be handled. Conflict may result from situational factors. Trying to write conditions to consider every possible factor would make rules difficult to understand. If we leave resolution to the administrator, we need to provide a mechanism for the administrator to tell the policy application function that "here is how I want this conflict handled" without forcing the administrator to go rewrite the policies involved right then and there, and to ensure that the conflict is re-reported on the next evaluation. The same conflict may arise multiple times. We should allow the administrator to define a "policy" to indicate how to resolve such conflicts in the future. This may be able to be done using a MIB to drive the conflict resolution (rule 4 overrides rule 3 when conflicts arise). Thanks for getting these discussion points out to the list. dbh -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Thu Jun 22 14:31:21 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 OAA12470 for ; Thu, 22 Jun 2000 14:31:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA21727 for snmpconf-outgoing; Thu, 22 Jun 2000 14:13:21 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733ECA8D@SOL> From: Andrew Smith To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Conflict Resolution Issues Date: Thu, 22 Jun 2000 11:09:03 -0700 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 Not sure what "we omit this capability" means in this context. Conflict detection needs to be done, for efficiency reasons, as well as "correctness", at *each* level of a policy management system. e.g. - human has to not click on 2 contradictory things at the same time - policy mgmt system has to make sure that contradictory things are not stored in its database at the same time - SNMP MIB must not have 2 ways of configuring the same thing (else neither manager nor agent can check - see below) - SNMP manager has to make sure that it does not include 2 contradictory SET varbinds in the same PDU - SNMP agent has to check for same - low-level classifier has to be unambiguous etc. Some of these things are implementation common sense. Some of them involve sensible MIB design. Some of them involve providing hooks such that implementations can do the right thing (the "this instance is under local control" bit that we've discussed is an example of this). I don't have any firm proposals, but we cannot just sweep this one under the carpet. It needs to be considered at all stages in this WG's work and some sort of write-up needs to be present in the documents, even if there are no specific protocol or data structure implications. Just my 2c. Andrew > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Thursday, June 22, 2000 7:19 AM > To: snmpconf > Subject: snmpconf Conflict Resolution Issues ... > 2. Is conflict detection or resolution a goal? > > Both are hard. Unless someone has a specific proposal, I > suggest that we > omit this capability or recommend that it be left to the > ingenuity of the > equipment or manager software developers. From owner-snmpconf@seymour39.SNMP.COM Thu Jun 22 14:40:45 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 OAA12699 for ; Thu, 22 Jun 2000 14:40:44 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA21811 for snmpconf-outgoing; Thu, 22 Jun 2000 14:21:17 -0400 (EDT) Message-ID: <6399122981E1D211AB490090271E0AA33C9ED8@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Conflict Resolution Issues Date: Thu, 22 Jun 2000 14:15:42 -0400 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 Jon, quick question. What's an intentional conflict between policies? Thanks, -Fran > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Thursday, June 22, 2000 10:19 AM > To: snmpconf > Subject: snmpconf Conflict Resolution Issues > > > Here is the second in the group of issues that came out of our interim > meeting. > > As before, I will put in my suggestions/thoughts where I have > an opinion. > > Conflict Resolution Issues: > > 1. How do we deal with intentional and unintended conflicts. > > It is hard to tell between intentional and unintended > conflicts between > policies. My suggestion is that this function be left to the policy > application function and not the managed element software. > > 2. Is conflict detection or resolution a goal? > > Both are hard. Unless someone has a specific proposal, I > suggest that we > omit this capability or recommend that it be left to the > ingenuity of the > equipment or manager software developers. > > 3. What happens when a policy is deleted? What if anything do > you revert to? > > In the case of DIFFSERV, I do not see much of a problem since > the traffic > that would have been treated will in systems I know about, > pass through the > system subject to the same 'rules' as the rest of the > traffic. The problem > is for other types of policy. For example; a policy that causes the > configuration of primary and secondary DNS servers. If the policy is > removed, the systems could be left without knowing where to send DNS > requests. I do not think we want to have the managed elements > keep a scratch > pad either (though some may choose to do this for a number of > reasons - and > we should not prohibit this). > > My suggestion is that we recommend in the BCP that policy > managers that > delete a policy, replace it with a default if appropriate or > the parameters > that existed prior to the installation of this policy. This will be a > difficult problem to solve. > > 4. How many errors are acceptable in a policy? How are they reported? > > Just as with the override of policy, failures should be > reported on a per > instance basis. That is, if 5 instances fail a status object > in the role > table that indicates a policy that includes this instance based on the > evaluation of the policy filter is not in force. This time > the reason is a > failure as opposed to an override. There is probably no need > for a second > object since the status can not both be failed and overridden. > > A notification should be sent in such failure situations only when the > policy is first evaluated, not each time the policy is > locally evaluated. > > Beyond a managed elements requirements for consistency, we > could create > another object that could deal with this, but it is probably > best left to > the management application. The management application would > also be the > place to determine if a particular value for a MIB Object under policy > control is outside of a policy range which would be helpful. > Particular > instances may be tweaked that are under policy control due to > a number of > conditions. > > 5. What happens when a configured element breaks that is > executing a policy? > > The object that reflects the element status in the role table > should be > updated and a notification sent. The policy ID should be part > of all such > notifications for override, failures on initial evaluation/set up and > subsequent failures. > > [end of list] > From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 10:26:50 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 KAA11442 for ; Fri, 23 Jun 2000 10:26:50 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA09810 for snmpconf-outgoing; Fri, 23 Jun 2000 10:14:30 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 10:14:07 -0400 Subject: snmpconf Hotel Information From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: <719326787FAED311889B009027D5FE351F535E@NETSOL-NIC-EX03> 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 I do not normally forward this type of email, but since we are also working on setting up an interim meeting at the end of IETF week, this is especially relevant. I do not know if the information below is correct, that hotel was already booked when I made my reservations. David (H). do we have a hotel selected yet? /jon ---------- > From: "Hollenbeck, Scott" > Date: Fri, 23 Jun 2000 09:30:56 -0400 > To: "'ietf@ietf.org'" > Subject: DoubleTree Cancellations > > I just had a call from the DoubleTree Hotel in Pittsburgh -- they are > canceling a number of (70+) confirmed reservations for the next IETF meeting > due to overbooking. They're trying to arrange for alternative > accommodations, but if you had a confirmed reservation at the DoubleTree you > might want to check your confirmation status to be sure your reservation is > still valid. > > Scott Hollenbeck > Network Solutions, Inc. Registry > > - > This message was passed through ietf+censored@alvestrand.no, which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Harald Alvestrand. From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 12:36: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 MAA14493 for ; Fri, 23 Jun 2000 12:36:58 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA12608 for snmpconf-outgoing; Fri, 23 Jun 2000 12:21:21 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 12:20:56 -0400 Subject: Re: snmpconf Conflict Resolution Issues From: Jon Saperia To: Message-ID: In-Reply-To: <39525225.3F13B21B@enterasys.com> 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 on 06/22/2000 1:51 PM, David Harrington at dbh@enterasys.com wrote: >> >> Conflict Resolution Issues: >> >> 1. How do we deal with intentional and unintended conflicts. >> >> It is hard to tell between intentional and unintended conflicts between >> policies. > > Agreed. I don't think it is significant for us to differentiate these. > >> My suggestion is that this function be left to the policy >> application function and not the managed element software. > > When you say "this function", do you mean the differentiation of intended vs. > unintended, or the resolution of conflicts? > I mean the determination between intentional and unintended conflict. In the case of 'intended' the mechanism you desire in your comment below might be found in policy group and priority. An intended conflict is one where policy A sets a value of a particular MIB Object to X and policy B wants it to be B. Intended in this case means that both policies were 'provisioned' this way as might be the case of policies that deal with link failures etc. We have yet to discuss priorities and groups on the list. Specific proposals from people would be welcome. Anything beyond this should in my view be left with the application. >> >> 2. Is conflict detection or resolution a goal? >> >> Both are hard. Unless someone has a specific proposal, I suggest that we >> omit this capability or recommend that it be left to the ingenuity of the >> equipment or manager software developers. > > I think it needs to be a goal to detect conflict and we should decide > how it should be handled. > Conflict may result from situational factors. Trying to write conditions > to consider every possible factor would make rules difficult to > understand. > > If we leave resolution to the administrator, we need to provide a > mechanism for the administrator to tell the policy application function > that "here is how I want this conflict handled" without forcing the > administrator to go rewrite the policies involved right then and there, > and to ensure that the conflict is re-reported on the next evaluation. I believe this is part of the application that I suggested above. > > The same conflict may arise multiple times. We should allow the > administrator to define a "policy" to indicate how to resolve such > conflicts in the future. This may be able to be done using a MIB to > drive the conflict resolution (rule 4 overrides rule 3 when conflicts > arise). > See my comment above about priority and groups (work still needs to be done on this). Hongal was working on this. Hongal do you have a proposal? /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 12:40: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 MAA14568 for ; Fri, 23 Jun 2000 12:40:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA12714 for snmpconf-outgoing; Fri, 23 Jun 2000 12:27:54 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 12:27:30 -0400 Subject: Re: snmpconf Conflict Resolution Issues From: Jon Saperia To: Message-ID: In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733ECA8D@SOL> 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 on 06/22/2000 2:09 PM, Andrew Smith at andrew@extremenetworks.com wrote: > Not sure what "we omit this capability" means in this context. > > Conflict detection needs to be done, for efficiency reasons, as well as > "correctness", at *each* level of a policy management system. e.g. > - human has to not click on 2 contradictory things at the same time > - policy mgmt system has to make sure that contradictory things are not > stored in its database at the same time Agreed. This is part of what I mentioned in an earlier posting in response to David H. One place this may be noted is in the BCP. > - SNMP MIB must not have 2 ways of configuring the same thing (else neither > manager nor agent can check - see below) > - SNMP manager has to make sure that it does not include 2 contradictory SET > varbinds in the same PDU > - SNMP agent has to check for same > - low-level classifier has to be unambiguous > etc. > All these points make good sense to me and we should include them in the policy section of the BCP - I am going to focus on that between now and ID cutoff. > Some of these things are implementation common sense. Some of them involve > sensible MIB design. Some of them involve providing hooks such that > implementations can do the right thing (the "this instance is under local > control" bit that we've discussed is an example of this). > > I don't have any firm proposals, but we cannot just sweep this one under the > carpet. It needs to be considered at all stages in this WG's work and some > sort of write-up needs to be present in the documents, even if there are no > specific protocol or data structure implications. > Thanks for the suggestions. At least for now, we can hold these topics in the BCP. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 13:09:12 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 NAA15447 for ; Fri, 23 Jun 2000 13:09:11 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA13532 for snmpconf-outgoing; Fri, 23 Jun 2000 12:55:05 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 12:54:42 -0400 Subject: Re: snmpconf Conflict Resolution Issues From: Jon Saperia To: Message-ID: In-Reply-To: <6399122981E1D211AB490090271E0AA33C9ED8@BMAILNJ> 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 on 06/22/2000 2:15 PM, Francis Reichmeyer (IPHighway MA) at FranR@iphighway.com wrote: > Jon, quick question. What's an intentional conflict between policies? > Thanks, > -Fran I do not recall what others might have meant at the meeting. In simple terms, a conflict is one where provisioned (downloaded) policies are sent to a device that have conflicting values for an object. Andrew pointed out, and he is correct that this is to be avoided. The place where it will happen is when one policy is intended as a policy to become effective in failure conditions and replace another policy. This is where the idea of policy groups and priority are helpful. For example if a policy evaluates to 'true' when there is a failure condition of some sort and it has a higher priority, then it would overwrite the other policy. Actually there would not be a conflict. Hope this helps. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 13:10: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 NAA15472 for ; Fri, 23 Jun 2000 13:10:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA13590 for snmpconf-outgoing; Fri, 23 Jun 2000 12:57:45 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 12:57:23 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: 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 on 06/19/2000 3:07 PM, Matt White at mwhite@torrentnet.com wrote: > On Wed, 14 Jun 2000, Jon Saperia wrote: > >> PmRoleESEntry ::= SEQUENCE { >> pmRoleESElement RowPointer, >> pmRoleESString SnmpAdminString, >> pmRoleESStatus RowStatus >> } >> >> I propose that the pmRoleESStatus be the place for the dirty bit. If that is >> not acceptable, another object in this table. > > While this would work, I think I would prefer to look at the precedence > issue first. We may come up with a solution to that problem that lends > itself well to solving the manual configuration problem. Or we may not, > but I'd at least like to see where that goes before we lock ourselves into > a solution to this problem. > > > -Matt > > Matt, can you clarify what you mean by the precedence issue please? Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 14:55:46 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 OAA17429 for ; Fri, 23 Jun 2000 14:55:45 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA15248 for snmpconf-outgoing; Fri, 23 Jun 2000 14:40:50 -0400 (EDT) Message-ID: <3953AEBD.70B2ED7E@enterasys.com> Date: Fri, 23 Jun 2000 14:38:53 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Hotel Information References: 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 My reservations at Doubeltree was cancelled as well. They have moved me to the Hilton. Class act. The secretariat is checking for a room for us. dbh Jon Saperia wrote: > > I do not normally forward this type of email, but since we are also working > on setting up an interim meeting at the end of IETF week, this is especially > relevant. I do not know if the information below is correct, that hotel was > already booked when I made my reservations. > > David (H). do we have a hotel selected yet? > > /jon > ---------- > > From: "Hollenbeck, Scott" > > Date: Fri, 23 Jun 2000 09:30:56 -0400 > > To: "'ietf@ietf.org'" > > Subject: DoubleTree Cancellations > > > > I just had a call from the DoubleTree Hotel in Pittsburgh -- they are > > canceling a number of (70+) confirmed reservations for the next IETF meeting > > due to overbooking. They're trying to arrange for alternative > > accommodations, but if you had a confirmed reservation at the DoubleTree you > > might want to check your confirmation status to be sure your reservation is > > still valid. > > > > Scott Hollenbeck > > Network Solutions, Inc. Registry > > > > - > > This message was passed through ietf+censored@alvestrand.no, which > > is a sublist of ietf@ietf.org. Not all messages are passed. > > Decisions on what to pass are made solely by Harald Alvestrand. -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 15:20: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 PAA17900 for ; Fri, 23 Jun 2000 15:20:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA15740 for snmpconf-outgoing; Fri, 23 Jun 2000 15:07:24 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 15:07:01 -0400 Subject: Re: snmpconf Hotel Information From: Jon Saperia To: Message-ID: In-Reply-To: <3953AEBD.70B2ED7E@enterasys.com> 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 on 06/23/2000 2:38 PM, David Harrington at dbh@enterasys.com wrote: > My reservations at Doubeltree was cancelled as well. They have moved me > to the Hilton. > Class act. > > The secretariat is checking for a room for us. Thanks very much. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 23 15:51:22 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 PAA18337 for ; Fri, 23 Jun 2000 15:51:21 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA16294 for snmpconf-outgoing; Fri, 23 Jun 2000 15:32:33 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 23 Jun 2000 15:32:11 -0400 Subject: snmpconf Language Related Questions From: Jon Saperia To: snmpconf , Steve Waldbusser Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id PAA16287 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit As most of you know Steve Waldbusser is leading the charge on this aspect of our work. During the interim meeting we spent quite a lot of time on this issue. Below are the same questions that I posted in the minutes without comment on my part. Steve, perhaps you could start the ball rolling on this by offering suggestions for these items based on the work you have been doing. Opinions from everyone are welcome. Thanks /jon Language Related Questions: 1. Language for expressions. To what degree do we want to use an existing language, and to what extent do we want to define our own? If we leverage an existing language, but constrain it to behave in ways that make it incompatible with the original, then we do not get reuse of language implementation, although we may get reuse of operator knowledge of languages like Perl. 2. We need to discuss Choice of language and Richness of language. Temporary variables, garbage collection; do we support temps or not? 3. Is UTF-8 support required in the expression language? 4. Extensibility Questions: For language and assessor functions - a natural one that allows for extension without re-opening the standard? sub-setting the language (do we allow or prohibit it)? sub-setting the assessor functions ibid? 5. Accessor functions ­ work to be done; reviewing proposed list. How to add new ones as they are needed? Can they go outside the SNMP universe? Mapping of principals, etc? 6. How do we handle versioning issues? 7. There were some standardization questions: standardization of element identifiers? capability type and subtype? extensibility mechanisms - are these part of the expression language? 8. Is the attribute of the element predefined? Can there be multiple instances? 9. How big should an expression be? 10. What are the execution environment requirements? 11. Temporary variables - do we want them: How do you dispose of them if we have them? 12. There were a number of attributes that people felt were desired. These include: needs to be debug-able - want to avoid memory leaks want to have instrumentation that helps people find bugs, want to avoid loopers but want iterators. 13. Issues about comments - comments in the expression - are they allowed? [end of list] From owner-snmpconf@seymour39.SNMP.COM Sat Jun 24 13:47:45 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 NAA14280 for ; Sat, 24 Jun 2000 13:47:44 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA04538 for snmpconf-outgoing; Sat, 24 Jun 2000 13:30:00 -0400 (EDT) Message-ID: <3954F148.11AE6DF5@cisco.com> Date: Sat, 24 Jun 2000 10:35:04 -0700 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Conflict Resolution Issues References: 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 Jon Saperia wrote: > > on 06/22/2000 2:15 PM, Francis Reichmeyer (IPHighway MA) at > FranR@iphighway.com wrote: > > > Jon, quick question. What's an intentional conflict between policies? > > Thanks, > > -Fran > > I do not recall what others might have meant at the meeting. In simple > terms, a conflict is one where provisioned (downloaded) policies are sent to > a device that have conflicting values for an object. I made some comments at the interim in this area, but it was to point out the need for explicit evaluation precedence. There are conflicts that can be detected at load time: Policy 1: All interfaces with ifSpeed from 10MBit to 100MBit get 'bronze' QoS Policy 2: All 100MBit interfaces connected to dept. WEB servers gets 'gold' QoS There are conflicts that can only be detected at run time: Policy 1: All interfaces with ifSpeed from 10MBit to 100MBit get 'bronze' QoS Policy 2: The interface attached to the Engineering WEB server gets 'gold' QoS In each of these cases, policy 2 must have higher precedence. This is no 'automatic' conflict resolution. You need a real development environment with a real debug tool, and some engineers who know what they're doing. Just moving the program to the device doesn't make the programming work go away. > > Andrew pointed out, and he is correct that this is to be avoided. The place > where it will happen is when one policy is intended as a policy to become > effective in failure conditions and replace another policy. This is where > the idea of policy groups and priority are helpful. For example if a policy > evaluates to 'true' when there is a failure condition of some sort and it > has a higher priority, then it would overwrite the other policy. Actually > there would not be a conflict. > > Hope this helps. > > /jon Andy From owner-snmpconf@seymour39.SNMP.COM Sat Jun 24 18:40: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 SAA15824 for ; Sat, 24 Jun 2000 18:40:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA05909 for snmpconf-outgoing; Sat, 24 Jun 2000 18:26:25 -0400 (EDT) Message-Id: <4.2.2.20000624182213.00baf440@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 24 Jun 2000 18:24:23 -0400 To: snmpconf From: "Joel M. Halpern" Subject: Re: snmpconf Conflict Resolution Issues 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 It is my opinion that deleting a policy should not directly cause a change in any attributes of any instances. It may be reasonable to expect (depending upon our evaluation model) that the set of policies in effect should be re-evaluated, which my cause some existing policy to change the values of some objects. Trying to perform a direct "unwinding" of a policy when it is deleted would, I think, be a very bad idea. Yours, Joel M. Halpern At 10:18 AM 6/22/00 -0400, Jon Saperia wrote: >3. What happens when a policy is deleted? What if anything do you revert to? > >In the case of DIFFSERV, I do not see much of a problem since the traffic >that would have been treated will in systems I know about, pass through the >system subject to the same 'rules' as the rest of the traffic. The problem >is for other types of policy. For example; a policy that causes the >configuration of primary and secondary DNS servers. If the policy is >removed, the systems could be left without knowing where to send DNS >requests. I do not think we want to have the managed elements keep a scratch >pad either (though some may choose to do this for a number of reasons - and >we should not prohibit this). > >My suggestion is that we recommend in the BCP that policy managers that >delete a policy, replace it with a default if appropriate or the parameters >that existed prior to the installation of this policy. This will be a >difficult problem to solve. From owner-snmpconf@seymour39.SNMP.COM Mon Jun 26 03:47: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 DAA27863 for ; Mon, 26 Jun 2000 03:47:25 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA16619 for snmpconf-outgoing; Mon, 26 Jun 2000 03:30:29 -0400 (EDT) Message-Id: <200006260729.JAA20160@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Interim meeting confirmation From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 X-Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10948.962004677.1@y5m638.lmera.ericsson.se> Date: Mon, 26 Jun 2000 09:31:17 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id DAA16614 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings, It would be very useful (critical, in fact) to know if it is settled that there will be an interim meeting. I need to purchase plane tickets and need to know that this is settled. Nothing against Pittsburgh, but I won't stay 'til Sunday if I don't have to. Something about this all interupting my vacation. So: - is it settled that we'll have an "interim" meeting on Friday afternoon and all day Saturday? - is it settled that it'll be in Pittsburgh? (I assume yes) Thanks. -- 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 Mon Jun 26 07:29: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 HAA00588 for ; Mon, 26 Jun 2000 07:29:46 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA19958 for snmpconf-outgoing; Mon, 26 Jun 2000 07:15:47 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA614233910@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Conflict Resolution Issues Date: Mon, 26 Jun 2000 14:12:50 +0200 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 Joel, So, the current state of a system ('attributes of instances') would be the result of the current pollicies, as well as of the previously deleted policies. If I assume the latest are not visible any longer, how would somebody look at the system and understand what is going on? Dan > -----Original Message----- > From: Joel M. Halpern [SMTP:joel@mcquillan.com] > Sent: Sun June 25 2000 0:24 > To: snmpconf > Subject: Re: snmpconf Conflict Resolution Issues > > It is my opinion that deleting a policy should not directly cause a change > > in any attributes of any instances. It may be reasonable to expect > (depending upon our evaluation model) that the set of policies in effect > should be re-evaluated, which my cause some existing policy to change the > values of some objects. Trying to perform a direct "unwinding" of a > policy > when it is deleted would, I think, be a very bad idea. > > Yours, > Joel M. Halpern > > At 10:18 AM 6/22/00 -0400, Jon Saperia wrote: > >3. What happens when a policy is deleted? What if anything do you revert > to? > > > >In the case of DIFFSERV, I do not see much of a problem since the traffic > >that would have been treated will in systems I know about, pass through > the > >system subject to the same 'rules' as the rest of the traffic. The > problem > >is for other types of policy. For example; a policy that causes the > >configuration of primary and secondary DNS servers. If the policy is > >removed, the systems could be left without knowing where to send DNS > >requests. I do not think we want to have the managed elements keep a > scratch > >pad either (though some may choose to do this for a number of reasons - > and > >we should not prohibit this). > > > >My suggestion is that we recommend in the BCP that policy managers that > >delete a policy, replace it with a default if appropriate or the > parameters > >that existed prior to the installation of this policy. This will be a > >difficult problem to solve. From owner-snmpconf@seymour39.SNMP.COM Mon Jun 26 09:15:11 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 JAA04321 for ; Mon, 26 Jun 2000 09:15:11 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA21949 for snmpconf-outgoing; Mon, 26 Jun 2000 08:54:51 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 26 Jun 2000 08:54:36 -0400 Subject: Re: snmpconf Interim meeting confirmation From: Jon Saperia To: Message-ID: In-Reply-To: <200006260729.JAA20160@lmera.lmera.ericsson.se> 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 on 06/26/2000 3:31 AM, David Partain at David.Partain@ericsson.com wrote: > Greetings, > > It would be very useful (critical, in fact) to know if it > is settled that there will be an interim meeting. I need to > purchase plane tickets and need to know that this is settled. > Nothing against Pittsburgh, but I won't stay 'til Sunday > if I don't have to. Something about this all interupting > my vacation. > > So: > > - is it settled that we'll have an "interim" meeting on Friday > afternoon and all day Saturday? > > - is it settled that it'll be in Pittsburgh? (I assume yes) > Yes, there is an interim meeting. The plan of record is as follows and has been approved by the ADs. 1. A general meeting during the IETF week for background overview etc. 2. A second meeting (requested for Friday morning of IETF week) for an additional working group session. 3. Interim Meeting begins Friday afternoon after the IETF finishes - this would be Friday August 4. 4. We will continue the meeting on Saturday August 5. All participants are requested to plan for a 4pm close time for the working group session. At the previous interim meeting many people had travel reservations that required that they leave prior to the scheduled close time of the meeting. We are asking this time that participants try to make travel plans that support the end time of the meeting, in this case 4PM on Saturday August 5. 5. The plan is to have the meeting in one of the hotels that are used for the IETF. David Harrington is doing the logistics for this meeting - I had the pleasure last time :-). He should be posting something soon. I have made my hotel and airline reservations already. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Jun 26 10:42: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 KAA07339 for ; Mon, 26 Jun 2000 10:41:59 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA25434 for snmpconf-outgoing; Mon, 26 Jun 2000 10:30:37 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 26 Jun 2000 10:30:22 -0400 Subject: snmpconf FW: request for feedback: Policy requirements drafts From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: <200006191943.NAA16598@xpeditio.cnd.hp.com> 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 Sorry for the duplicate posting. I think some eof the material in the drafts below is interesting for the SNMPCONF work even though it was not written with our efforts in mind. /jon ---------- > From: Hugh Mahon > Organization: HP Network & System Management Division > Reply-To: Hugh Mahon > Date: Mon, 19 Jun 2000 13:43:17 -0600 (MDT) > To: policy@raleigh.ibm.com > Subject: request for feedback: Policy requirements drafts > > Hi Folks, > > We are interested in getting feedback on the requirements draft > and a sense of what people in the WG think is missing, could be > enhanced, etc., in the drafts describing requirements and expected use > of a policy management system. > > The current revisions of the draft are available at: > > http://www.users.uswest.net/~hmahon/draft-ietf-policy-req-02-diffs.txt > http://www.users.uswest.net/~hmahon/draft-mahon-policy-use-00.txt > http://www.users.uswest.net/~hmahon/draft-mahon-policy-mgmt-00.txt > > The documents contain the contents of previous revisions of > the requirements draft plus other information (change bars are in the > drafts to show new or changed content from the -01 rev of the > requirements draft). The current structure of the documents is in > response to feedback from the WG that the draft should be shorter but > the information should be preserved. > > To leverage from the 'next steps' slide for the requirements > document: > > next steps > - can continue to add more information, but is there a specific > direction people would like this to go in? > - one suggestion for how to proceed is to describe what needs to be > done to manage QoS in the environment, then describe the > requirements to support those activities > - should I go into more detail on the existing usage cases? > - shorten all of the drafts (with suggestions of what is not > important to keep) > - other feedback, questions? > > Thanks, > > Hugh Mahon > John Schnizlein From owner-snmpconf@seymour39.SNMP.COM Mon Jun 26 10:53: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 KAA07608 for ; Mon, 26 Jun 2000 10:53:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA25767 for snmpconf-outgoing; Mon, 26 Jun 2000 10:39:25 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 26 Jun 2000 10:39:10 -0400 Subject: snmpconf FW: request for feedback: Policy requirements drafts From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: 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 Below are comments I sent to the Policy list on the usage scenarios. /jon ---------- > From: Jon Saperia > Date: Mon, 26 Jun 2000 10:29:03 -0400 > To: Hugh Mahon , , Jon > Saperia > Subject: Re: request for feedback: Policy requirements drafts > > on 06/19/2000 3:43 PM, Hugh Mahon at mhugh@xpeditio.cnd.hp.com wrote: > > Hugh some comments about: > > ~hmahon/draft-mahon-policy-use-00.txt > > First, I find it helpful for work items that are the result of or intended > products of an active WG to be published on the WG page. Helps with > references and keeping current. > > Page 4. > >> Policy Management is a way for the Network Administrator to >> pro-actively manage the network, not simply react to how >> users use the network. The intent is to ensure the value >> of a shared resource, which is what the network is, not to >> take anything away from the users. > > The second sentence could use a bit of rewording for clarity. I also have an > issue with what is not included here. Policy is also to cause a consistent > behavior or configuration. For example, I want to have all systems from XYZ > vendor that are model 2's running release 4.4. I want to make sure we > support they type of shared resource provisioning for 'quality of service' > type examples but we should also include examples such as the one I > describe. as well. > > Page 7 - 8. > >> Once the administrator has authored these rules they would >> be committed to a repository. How the Policy Management >> Application chooses to order operations is implementation >> dependent, but the Policy Rules must be grouped together to >> form a Policy Group. Once grouped the Policy can option- >> ally be run through tools to determine if there are con- >> flicts between Policy Rules within the Policy. >> > > It may not be obvious to unfamiliar readers what is meant by a policy group > here. I think the document would benefit from a table of terms for rule, > condition, etc. I am aware of the terminology work that has been done in > other documents, but think importing a few terms here would be helpful. > > Page 10. > >> Once the Policy Rules based configuration has been sent >> to the Policy Target(s) the Policy Consumer will deter- >> mine the success of the deployment and provide feedback >> to the Policy Management Application. In order to >> determine the success, for this example, the Policy Con- >> sumer will query the device and examine the information >> relating to the configuration of the Policy Target(s) to >> determine if the configuration now matches what the Pol- >> icy Consumer expects based on the Policy Data. > > This is one way of confirming correctness of the configuration operation > which is quite reasonable. Another way would be via exception reporting or > an ack. from the target. That is, an ack confirms correct reciept, i.e., > success. Error messages can be sent back with what when wrong. > > Page 11. > >> As described above, at the start or end of a time/date >> period expressed in a condition the Policy Consumer >> would re-evaluate the Policy Rules for the Policy Target >> and perform the necessary translations, check existing >> configuration, perform any necessary clean-up, deploy >> the corresponding configuration, and report status. >> (Alternatively the Policy Consumer could generate the >> appropriate information for any given time period speci- >> fied in the Policy Rules and simply download them at the >> appropriate times rather than filter at each time bound- >> ary.) > > Also reasonable. Some policy consumers can send to the policy target the > schedule for policy execution. Perhaps this is for a 'policy aware' device? > The point is some devices under policy control will have scheduling > capability locally and all the need is that the policy information contain > this when deployed. This facility does not prevent the other type of > distribution where the policy consumer reloads policy when needed. > > Page 16. > >> bilities. A well implemented Policy Consumer will detect >> any problems with a Policy before deploying it on a Target >> (if the problem wasn't detected in an automated way ear- >> lier). If a Policy Consumer does detect such a problem it >> will provide feedback to the Administrator through the Pol- >> icy Management Repository. > > I understand policy consumer to be management application. In this context I > agree that such software should check before deploying a policy. In some > cases only the managed element will know at the time the request is made if > the policy will work or not - this should be the exception. > > That said, the exception, that is to say the failed policy deployment should > in my view be stored somewere - the repository is fine. The the event > enunnciation is not via the repository it is via some enunciation software > such as a gui, email, pager, etc. > > Page 18. > >> Scenario 1 allows for minimal change to the Core Informa- >> tion Model. It would, however, cause Policies to be clut- >> tered with Policy Rules (or condition lists within Policy >> Rules) which only exist to handle contingencies. Such con- >> ditions which deal with state likely would not be evaluated >> on the Policy Targets (using existing devices as the >> model), rather they would be evaluated on the Policy Con- >> sumer. >> >> An example of such a state condition could be: >> >> condition type name: deviceDown >> attributes: device address: 192.168.14.12 >> considered down if no contact after: 30 >> seconds >> >> To enable such a condition, either the Policy Consumer >> would need to poll each of the devices named in each such >> condition, or would need to be notified by some third party >> monitoring the condition of each device named in each pol- >> icy condition. >> >> > > I have a bit of a problem with this model in that it is too restrictive. I > have no problem if people want to deploy policy in the fashion you describe > here for failures and architectures should support this - but believe there > is a better approach. Sure, the managed element should keep it's manager > posted as to its status. This can be achieved via asynchronous or polling > methods or a combination of both. In some cases, however; the managed > element (policy target) should have the policy to apply in the case of a > failure and is in the right place to do so rapidly. In SONET networks change > over as a result of failure can take place fairly rapidly (that is the goal > at least). These machines should have the policy to employ locally in the > case of the failure due to time constraints, a polling based approach when > rapid correction is desired would be problematic. My other concern about > the example is that it is on a device basis. While it is true that entire > devices can fail, it is more true that parts fail or the network > infrastructure that connects them has a failure. so the condition is not > deviceDown, but interface down. > > Page 19. > >> Scenario 2 would require a change to the Core Information >> Model. On the association between a Policy and Policy Tar- >> get, there would be conditional associations to other Poli- >> cies. In the association would be conditions similar to >> those described in Scenario 1, which describe conditions >> under which the Policies for unusual circumstances would be >> deployed. If the current indirect model for distribution >> is followed, all of the policies would be placed in the >> directory and the Policy Consumer would obtain all of the >> policies, then change which Policy is deployed to the Pol- >> icy Target on a status change as described in Scenario 1. >> If a more direct model for Policy distribution were used, >> then the Policy Management Application could be enabled to >> change Policy distribution based on state not related to >> traffic based conditions. >> > > This is a bit closer to what I had in mind, except that it assumes that the > policy management application is watching over everything and knows enough > what to do in the case of a failure condition and then loads the correct > policy to the devices it needs to. There is no problem in an architecture > allowing for this type of approach but believe it to be insufficient in many > circumstances. For this reason, a policy application may send to a managed > device the policy to use when things are ok, and the policy to use (perhaps > more than one) when there is a failure. > > Page 21. > >> 2.6.2. Snooping Signaling Messages to Glean Classification >> Information > > There is no problem in principle with a management application collecting > data from the network and using that for policy setting. My objection is > that the example is RSVP specific and should be in this type of document, I > think more broadly worded. For example, a management application could learn > a lot from other types of instrumentation in the network about who is using > the net, what type of traffic is being sent, etc. Both these examples have > some interesting security implications though. > > Page 22. > >> 2.6.3. Offering High Quality Guarantees > > My comment about this section is that is why policy is most usefully > expressed in terms of amount of traffic, capacity of a device and > utilization. A device might be configured to deliver a maximum of X voice > over IP sec. I like some of the examples but again find that they are too > restrictive. A policy manager can send information to devices under some > circumstances. In other cases the policy should contain what to do if a > resource is exceeded, or alternatively a second policy would be triggered in > the event of 'oversubscription'. This is not to say that the centralized > policy manager would not have a function in this area since it may monitor > for aggregate usage and cause policies to changes based on state or usage > information from many places in the network. > > Page 33. > >> 3. Security Considerations > > My problem is not with what is there, but what is missing. Either the list > should be complete or a pointer to other documents provided. I believe that > user authentication is important for example. > > /jon > From owner-snmpconf@seymour39.SNMP.COM Mon Jun 26 11:19: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 LAA08260 for ; Mon, 26 Jun 2000 11:19:51 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA27029 for snmpconf-outgoing; Mon, 26 Jun 2000 11:06:03 -0400 (EDT) Message-Id: <4.2.2.20000626110134.00bb78d0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 26 Jun 2000 11:03:38 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: RE: snmpconf Conflict Resolution Issues In-Reply-To: <15F58915DF84D311AC7D0090279AA614233910@ITC-EML2> 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 Your description of the state is accurate. I do not believe that on can reasonably expect to understand all of "how we got here". We can improve the situation if we want. Just as one can log all direct SNMP activity, one could log all policy effects. One could then consult such a log to find out that certain policies did take effect. The alternative of trying to unwind the effect of a policy when it is deleted requires guessing what the state "should" be. Such heuristics may be interesting, but I don't think they belong in this work at this time. Yours, Joel At 02:12 PM 6/26/00 +0200, you wrote: >Joel, > >So, the current state of a system ('attributes of instances') would be the >result of the current pollicies, as well as of the previously deleted >policies. If I assume the latest are not visible any longer, how would >somebody look at the system and understand what is going on? > >Dan > > > > > -----Original Message----- > > From: Joel M. Halpern [SMTP:joel@mcquillan.com] > > Sent: Sun June 25 2000 0:24 > > To: snmpconf > > Subject: Re: snmpconf Conflict Resolution Issues > > > > It is my opinion that deleting a policy should not directly cause a change > > > > in any attributes of any instances. It may be reasonable to expect > > (depending upon our evaluation model) that the set of policies in effect > > should be re-evaluated, which my cause some existing policy to change the > > values of some objects. Trying to perform a direct "unwinding" of a > > policy > > when it is deleted would, I think, be a very bad idea. > > > > Yours, > > Joel M. Halpern > > > > At 10:18 AM 6/22/00 -0400, Jon Saperia wrote: > > >3. What happens when a policy is deleted? What if anything do you revert > > to? > > > > > >In the case of DIFFSERV, I do not see much of a problem since the traffic > > >that would have been treated will in systems I know about, pass through > > the > > >system subject to the same 'rules' as the rest of the traffic. The > > problem > > >is for other types of policy. For example; a policy that causes the > > >configuration of primary and secondary DNS servers. If the policy is > > >removed, the systems could be left without knowing where to send DNS > > >requests. I do not think we want to have the managed elements keep a > > scratch > > >pad either (though some may choose to do this for a number of reasons - > > and > > >we should not prohibit this). > > > > > >My suggestion is that we recommend in the BCP that policy managers that > > >delete a policy, replace it with a default if appropriate or the > > parameters > > >that existed prior to the installation of this policy. This will be a > > >difficult problem to solve. From owner-snmpconf@seymour39.SNMP.COM Tue Jun 27 13:13:21 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 NAA18574 for ; Tue, 27 Jun 2000 13:13:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA06415 for snmpconf-outgoing; Tue, 27 Jun 2000 12:54:56 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 27 Jun 2000 12:54:45 -0400 Subject: snmpconf System Capabilities From: Jon Saperia To: snmpconf Message-ID: 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 As some of you know, how an agent reports its capabilities to the policy management system has been discussed a bit on the list and was an issue that was discussed at the Interim meeting in San Francisco. I have been exchanging ideas about this with a number of people - this was partly sparked by a post Andrew made the other week. The following are some additional ideas about how SNMP-based systems that support policy can make available to policy managers, details of the (dis)abilities of their mechanism and implementation specific MIB Modules. I note a couple of different approaches but flesh out only one that involves the modification of the policy table in our current policy module. I believe there is some promise in this approach but it would benefit from additional comments. Counter proposals for other approaches that I did not flesh out or new ideas are welcome. I would like to get something specific into the next draft Steve Waldbusser is working on in advance of publication for our next meeting. This discussion began on the DIFFSERV email list in the context the the MIB Module they are developing. In that exchange I said that I would write a proposal of how we could accomplish advertisement of capabilities in the SNMPCONF work. I was not sure this was relevant enough to send to the DIFFSERV list so I have just sent it to the SNMPCONF list. Andrew, since this is a response to questions you posed, if you feel this is useful on the DIFFSERV list, feel free to forward it. If not, we can continue to discuss it here since we have to resolve this issue for SNMPCONF anyway. I hope that we can use the same approach across the two working groups. Part of the problem as Andrew pointed out is that there are several granularities of capability that are required for an effective system. From my perspective, they are equivalent to the levels of abstraction that we have been dealing with: Domain - Do I offer quality of service or secure communication facilities? Mechanism - Mechanisms are technologies used within a particular domain. For example, in the differentiated services domain, RED or WRED (Weighted Random Early Detection) might be used as one of the mechanisms that devices employ to support differentiated services. It is helpful for a policy management application to learn what mechanisms are supported on a particular device. Not all possible mechanisms may be supported or enabled in all implementations. Implementation specific details - These fall into two dimensions. The first are restrictions on what the standards require. These restrictions should be 'advertised' via the mechanism specific level. The second dimension are extensions for mechanism that are not part of a standard. These facilities would be 'advertised' via the implementation specific MIB Module if present. Note that I exclude from the expression of capability, restrictions of the following type: - Does the device have the capacity to perform the work? This is important but should be reported via a mechanism that is for that purpose in our SNMP-based policy management system. - Anything related to conflict detection or resolution, including the time dimension. With this said, I think the problem has two parts. First: there is no standardized way of learning this information from SNMP-based instrumentation at this time. Agent capabilities is generally not available as a set of run time objects. The second part is that, unlike a lot of current network layer auto-discovery code that uses the presence or absence of a particular base OID to determine if something is supported, that level of granularity is not sufficient for our task - see above. In any event that approach will not work since some of the tables will not exist yet and thus there will be no row entries - this is a problem for network layer discovery systems as well but is not as problematic.. Additionally, there is a problem in that the capabilities might be limited within an object. Take for example an enumerated integer that is supposed to support 5 values, but in the particular agent implementation supports only 3. We have discussed a variety of techniques, none of them are completely satisfactory yet. They include: - Use of a default row in tables to learn the existence of the specific object. Good but suffers from limitation of the sub object support described above. For example, if the Differentiated Services Policy MIB Module were running on a particular system, it would always have a reserved 1st row that might even contain default values but not be associated with and instances. This also has a nice side effect of having the mechanism specific desired defaults and implementation specific defaults (e.g., for xyz vendor) available. - Use of bit strings for listing restrictions. Interesting but probably not likely to be well supported. - Having managers read the agent capabilities and compliance and conformance macros - after all that is what they are for. This is appealing but suffers from the fact that most vendors are not always forthcoming in creating accurate macros of this kind. The other defect in this approach in my view is that is assumes the vendor has told the truth. Of course the agent could always give a correct error message if a value were set to an object that did not exist or was invalid for that object. - The use of an extended capabilities table in the Policy MIB Module. This table is quite simple in the current draft with just two objects: PmCapabilitiesEntry ::= SEQUENCE { pmCapabilitiesIndex Integer32, pmCapabilitiesType OBJECT IDENTIFIER } I had always imagined that there would be a pmCapabilitiesSubType as well so that is just a minor omission from the current table. I would re-do the table as follows: -- capabilities table -- Note that with this table it is not necessary to list all OIDs that -- a mechanism specific MIB Module supports, just the base OID if -- the implementation is a fully compliant one. If the implementation -- is not, then additional rows will exist in the table that list -- the limitations or enhancements. pmCapabilitiesTable OBJECT-TYPE SYNTAX SEQUENCE OF PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The pmCapabilitiesTable contains a description of the capabilities of the system. It also enumerates restrictions." ::= { policyMgt 4 } pmCapabilitiesEntry OBJECT-TYPE SYNTAX PmCapabilitiesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The description of a capability or limitation of a capability of the system. An entry will exist for each domain and mechanism specific ability the system has. In the case of a domain specific capability with no mechanism specific parameters, the pmCapabilitiesSubType and all other columns may be null. Entries will exist that contain values for the pmCapabilitiesRestrictOID, pmCapabilitiesRestrictType, pmCapabilitiesRestrictValue and pmCapabilitiesRestrictString objects only when an implementation is reporting a mechanism specific restriction. Multiple entries are possible when more than one restriction for a type or subtype are needed." INDEX { pmCapabilitiesIndex, pmCapabilitiesType } ::= { pmCapabilitiesTable 1 } PmCapabilitiesEntry ::= SEQUENCE { pmCapabilitiesIndex Integer32, pmCapabilitiesType OBJECT IDENTIFIER, pmCapabilitiesSubType OBJECT IDENTIFIER, pmCapabilitiesRestrictOID OBJECT IDENTIFIER, pmCapabilitiesRestrictType INTEGER, pmCapabilitiesRestrictValue INTEGER, pmCapabilitiesRestrictString OCTET STRING } pmCapabilitiesIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry." ::= { pmCapabilitiesEntry 1 } pmCapabilitiesType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION DESCRIPTION "The type of the capability represented by this entry. The IANA will publish the list of identifiers that are valid values for this object." ::= { pmCapabilitiesEntry 2 } pmCapabilitiesSubType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The sub type of capability is a pointer to a mechanism specific set of capabilities supporting a base technology. In the case of DIFFSERV, the OID value here would be the base OID of the Differentiated Services Policy MIB Module." ::= { pmCapabilitiesEntry 3 } pmCapabilitiesModificationOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The OID of the object that is either not supported, supported with one or more limitations, or expanded by an implementation specific module. If this columnar object is other than null then there must be at least an entry in pmCapabilitiesModificationType. Note that this need not be a leaf node or scalar object. If an entire table is not supported, this value can be the base OID for the table." ::= { pmCapabilitiesEntry 4 } pmCapabilitiesModificationType OBJECT-TYPE SYNTAX INTEGER { unsupported(0), restricted(1), additional(2), addvalue(3), maxlimit(4), minlimit(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "An unsupported value indicates that the OID in pmCapabilitiesModificationOID is not supported on this system. A value of 1 indicates that the OID is supported but with restricted values These constraints are described in the pmCapabilitiesModificationValue and pmCapabilitiesModificationString objects. A value of 2 indicates a vendor specific extension to a standard. The OID of the new object is pmCapabilitiesModificationOID. For some implementations, additional functions may be provided. addvalue indicates that this row of the table describes an additional value that the object can take. The specific value is in the pmCapabilitiesModificationValue. The values of 4 and 5 indicate restrictions or the removal of restrictions for the object identified." ::= { pmCapabilitiesEntry 5 } pmCapabilitiesModificationValue OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "If the value of pmCapabilitiesModificationType is 0, this object will be null since 0 indicates no support for the object at all. A value of 1 in the pmCapabilitiesModificationType will be further modified by a single integer value in this object that corresponds to enumerated integer values that are not supported by the system for the object that is identified in this row. This value can also represent the limit values in the pmCapabilitiesModificationType object." ::= { pmCapabilitiesEntry 6 } pmCapabilitiesModificationString OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Any additional details or description or parameters needed.." ::= { pmCapabilitiesEntry 7 } This table is not perfect but does give quite a lot of flexibility and does not require very many objects. Implementations that are reasonably conformant will also have tables with a fairly small number of rows. Even when this is not the case, this will be read only very infrequently and is indexed such that it is possible to retrieve reasonable sub portions of the table. Not that I still think a 'default'/initial row for mechanism and implementation specific modules may have some value. on 06/13/2000 6:09 PM, Andrew Smith at andrew@extremenetworks.com wrote: > Jon, > > There are several levels of granularity on which this could work: > > 1. Lowest as in "I support the diffServMeterTable", "I do not support the > diffServAlgDropperTable". I think the mods above support this. > > 2. Slightly higher as in "I support head droppers but not tail droppers" Depends on the layout, but I think this would be handled. > > 3. Higher as in "I support head droppers that feed into strict-priority > schedulers but not into WRR schedulers" I doubt very much that this would be correctly dealt with in the objects I wrote. At some point, humans will have to be involved. I would be happy to say we can not deal with this type of condition and that the person writing the 'rule' would have to take this into consideration. Of course this is not an excuse for the agent not doing good error checking :-) > > There's also a "number of instances" dimension to it: "I support 3 strict > priority scheduled queues per interface", "I support 3 strict priority OR 2 > WRR scheduled queues per interface but not both at the same time". This in my view is a 'capacity' question. A valid one but dealt with elsewhere. We have yet to have a full discussion on this topic, though I look forward to it. > > There could also be an even more abstract notion of "I support AF but not > EF" but that's somewhat different (since we don't have an AF or EF MIB - > just one that hacks on the individual components that work together to > provide AF or EF). Since this is not a capability at this level. I am not sure how to deal with this. Of course we could create mechanism specific objects for things like this and they could be modified by this table. > > This could get quite fun ... but the more information like this that an > agent can export, the easier will be the job of the manager and the more > multi-vendor this whole config thing can become. Agreed. Of course we have to also make it implementable - some people may feel this table with the 7 objects is already to hard. Others may feel it does not go far enough. Opinions? /jon From owner-snmpconf@seymour39.SNMP.COM Tue Jun 27 16:04:56 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 QAA23352 for ; Tue, 27 Jun 2000 16:04:55 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA11919 for snmpconf-outgoing; Tue, 27 Jun 2000 15:49:30 -0400 (EDT) Message-ID: <395904F5.F0D15EA1@enterasys.com> Date: Tue, 27 Jun 2000 15:48:05 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Conflict Resolution Issues References: 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 Jon Saperia wrote: > > > I mean the determination between intentional and unintended conflict. In the > case of 'intended' the mechanism you desire in your comment below might be > found in policy group and priority. An intended conflict is one where policy > A sets a value of a particular MIB Object to X and policy B wants it to be > B. Intended in this case means that both policies were 'provisioned' this > way as might be the case of policies that deal with link failures etc. We > have yet to discuss priorities and groups on the list. Specific proposals > from people would be welcome. Anything beyond this should in my view be left > with the application. > >> Conflict resolution at the application will be difficult because it doesn't have all the local information, i.e. the instance-specific expansion and the current situational state of the device. Conflict resolution is hard, and not all devices will be able to devote resources to conflict resolution, while other devices can afford the resources. I believe it is reasonable to expect that conflict resolution should be done in both places. However, that may not always be possible. I feel that for interoperability reasons, we should define the expected behavior when a device does support additional conflict resoltuion, and when it does not. When it does, it would probably be good to have a MIB that can standardize that behavior, at least to a degree. It may be useful to have an object that indicates whether the device does additional conflict resolution (although I'm not sure it is necessary, if it is only informational and would have no effect on the behavior of an application). If there are multiple resolution approaches defined, it might be useful to indicate which are supported by a particular device/implementation. There are a number of aspects to conflict resolution - rule priority, role priority, scheduling overlap, relative size of the intersection of conflict (possibly useful when there are multiple policies in conflict), whether rules are inherited or specific to an element, resolution order (when there are multiple conflicts), operator override, whether one policy is currently active, which policy satisfies the greatest number of conditions, which policy modifies the greatest number of managed objects, which policy affects the greatest number of elements, what behavior in the case of a tie in resolution (stay as is/pick one randomly/report an error), whether the USER could be allowed to select in the case of a tie, etc. For device-level resolution, it might be useful to try to standardize resolution for each aspect using configurable mib tables, and then see how these can be normalized. For application resolution, it would be good if we can suggest some approaches to improve consistency across applications. -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-snmpconf@seymour39.SNMP.COM Wed Jun 28 13:32:54 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 NAA28575 for ; Wed, 28 Jun 2000 13:32:53 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA20697 for snmpconf-outgoing; Wed, 28 Jun 2000 13:10:26 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 28 Jun 2000 13:10:14 -0400 Subject: Re: snmpconf Conflict Resolution Issues - Consensu From: Jon Saperia To: Message-ID: In-Reply-To: <4.2.2.20000624182213.00baf440@omniplex.mcquillan.com> 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 on 06/24/2000 6:24 PM, Joel M. Halpern at joel@mcquillan.com wrote: > It is my opinion that deleting a policy should not directly cause a change > in any attributes of any instances. It may be reasonable to expect > (depending upon our evaluation model) that the set of policies in effect > should be re-evaluated, which my cause some existing policy to change the > values of some objects. Trying to perform a direct "unwinding" of a policy > when it is deleted would, I think, be a very bad idea. > > Yours, > Joel M. Halpern > Folks, I believe that we have consensus on this topic even though my original postings may not have been clear. The consensus is that we should not attempt to deal with this in the managed systems at all for all the previously stated reasons. I agree. If a manager wants to do something fancy when deleting a policy that is outside the scope of the current work. All agreed? /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 29 03:48:49 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24051 for ; Thu, 29 Jun 2000 03:48:48 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id DAA21282 for snmpconf-outgoing; Thu, 29 Jun 2000 03:30:04 -0400 (EDT) Message-Id: <200006290729.JAA28621@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Pointers from Policy MIB -> implementation-specific MIB From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7033.962263866.1@y5m638.lmera.ericsson.se> Date: Thu, 29 Jun 2000 09:31:06 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id DAA21276 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings, While speaking with Jon and Harrie, we talked about the need to have a way to "debug" policies. Basically, there needs to be something showing the relationship between a policy in the policy MIB and its instantiation "lower" down. We want this so that there is a way of correlating policies with things that are broken. If you don't who's implementing a policy or the parameters that cause the change you want (or the change you _didn't_ want), you cannot debug it. Different strategies are possible. Three are: - pointers from the "lower" MIBs (implementation-specific) into the policy MIB - shared indices between the policy MIB and the implementation-specific MIBs - pointers from the policy MIB into the implementation-specific MIBs This was discussed at the last interim meeting, and the best approach appears to be the last of them. It allows the most flexibility with respect to how many places to point to (which #2 doesn't), while avoiding the problems that are associated with #1. So, we propose that something along the lines of the objects below be added to the policyMgt MIB in draft-ietf-snmpconf-pm-??.txt. The arguments for this are: 1) If we don't put the relationship pointers in a central place we have to spread them all over (if we're going to have the information available). Thus, putting them in the POLICY-MANAGEMENT-MIB avoids defining them in each implementation-specific MIB. 2) From an implementation-specific MIB module it is not possible to know all relationships of applied policies. The other way around is that when a policy is applied, the management station should already select which implementation-specific or instance-specific objects are applicable. 3) Having the relationships in a central place makes them useful for debugging policies. For instance, if multiple pointers from everywhere pointing to a policy in the Policy MIB module you could have well overlooked 1 relationship. We're obviously not attached to any names. If someone has a better way of solving this problem, those ideas are greatly appreciated. pmPolicyMechanismTable OBJECT-TYPE SYNTAX SEQUENCE OF PmPolicyMechanismEntry STATUS current DESCRIPTION "This table is used to show the relationships from policies to mechanism specific policy definitions." ::= { policyMgt xx } -- uses a shared index with the pmPolicyTable pmPolicyMechanismEntry OBJECT-TYPE SYNTAX PmPolicyMechanismEntry STATUS current DESCRIPTION "An row of the pmPolicyMechanismTable." INDEX { pmPolicyIndex, pmPolicyMechanismIndex } ::= { pmPolicyMechanismTable 1 } PmPolicyMechanismEntry SEQUENCE ::= { pmPolicyMechanismIndex Unsigned32, pmPolicyMechanismPointer RowPointer } pmPolicyMechanismIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) STATUS current DESCRIPTION "A unique index for the mechanism pointers." ::= { pmPolicyMechanismEntry 1 } pmPolicyMechanismPointer OBJECT-TYPE SYNTAX RowPointer STATUS current DESCRIPTION "A row pointer that connects a policy instantiated at 'pmPolicyIndex' to mechanism specific." ::= { pmPolicyMechanismEntry 1 } Your comments are welcome. 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 Thu Jun 29 07:07: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 HAA25768 for ; Thu, 29 Jun 2000 07:07:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id GAA24385 for snmpconf-outgoing; Thu, 29 Jun 2000 06:49:36 -0400 (EDT) Message-ID: <395C7A2E.43501F40@nextbeacon.com> Date: Fri, 30 Jun 2000 03:45:02 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf General Functional Questions References: 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 I agree that the "touch-bit" needs to be instance specific, but placing it in the role table is pretty heavyweight because it will turn off *all* policies that control a particular element. Say I need to override a variable for firefighting purposes but I don't want to also turn off the policy that applies QOS to that interface (because that might cause another firefight). The "touch-bit" should turn off a particular policy from a particular instance. In the current draft, such a facility exists: PmTrackingElementToPolicyEntry ::= SEQUENCE { pmTrackingElementToPolicyElement RowPointer, pmTrackingElementToPolicyStatus INTEGER } INDEX { pmTrackingElementToPolicyElement, pmPolicyIndex } pmTrackingElementToPolicyStatus OBJECT-TYPE SYNTAX INTEGER { off(0), on(1), forceOff(2) } The forceOff state is the touch-bit. When set, it forcibly disables this policy from executing on this element. Also, I don't believe in having these bits set as side-effects of setting an SNMP variable. Reasons include: 1) An SNMP set for a variable that is under policy control doesn't communicate the following necessary sentiment: "While I know that this variable is under policy control, I intend to override that anyway". In other words, the SNMP engine can't tell whether the request intended to override policy or was an innocent mistake. It would be hard to say that we're enforcing policy when any request has carte-blanche to get an exemption. 2) Would require changing instrumentation for all MIBs 3) Doesn't specify which policy to override in those cases where a single variable is under control of multiple policies. Steve Jon Saperia wrote: > on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote: > > > Hi, > > > > I think the exempt bit needs to be instance-specific, to tell which > > instance has been overridden. If the "touch-bit" can be cleared via > > SNMP, it will be important to know WHICH instance should be cleared if > > there are multiple instances that have been touched. > > Exactly so. We are all in agreement on this point. That is why I have > proposed using the role table which is instance specific. > > > > It may also be important for tracking down a security breach to expose > > which instance was changed. > > > > Having the "touch-bit" at the role-abstraction level doesn't allow the > > necessary granularity. I think it might be nice to have a dirty-flag at > > the role level, to easily indicate that one or more instances of the > > role have been overridden. However, I am concerned that having the > > touch-bit at this level may be problematic. It may be difficult to go > > from the instance level to the role level easily, as has been discussed. > > This becomes harder in a mid-level manager situation, where the role > > evaluation may be done within a different engine, as discussed at the > > interim meeting. > > > > PmRoleESEntry ::= SEQUENCE { > pmRoleESElement RowPointer, > pmRoleESString SnmpAdminString, > pmRoleESStatus RowStatus > } > > Roles are assigned on an instance specific basis. That is the only way the > local mechanisms can know were to apply the policy. I do not see the role > evaluation taking place remotely. One a large machine with many interfaces > and/or S/PVCs numbering into the many hundreds of thousands, the evaluation > has to be done locally. This does not mean that a MLM can not participate > since the MLM application would send the policy filters to the targets for > evaluation. > > I propose that the pmRoleESStatus be the place for the dirty bit. If that is > not acceptable, another object in this table. > > /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 29 07:10: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 HAA25857 for ; Thu, 29 Jun 2000 07:10:59 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA24490 for snmpconf-outgoing; Thu, 29 Jun 2000 06:55:19 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 29 Jun 2000 06:55:09 -0400 Subject: Re: snmpconf Pointers from Policy MIB -> implementation-specific MIB From: Jon Saperia To: Message-ID: In-Reply-To: <200006290729.JAA28621@lmera.lmera.ericsson.se> 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 on 06/29/2000 3:31 AM, David Partain at David.Partain@ericsson.com wrote: > pmPolicyMechanismTable OBJECT-TYPE > SYNTAX SEQUENCE OF PmPolicyMechanismEntry > STATUS current > DESCRIPTION > "This table is used to show the relationships > from policies to mechanism specific policy definitions." > ::= { policyMgt xx } > Excellent points David. Whatever we call this table, it should reflect the fact that this is really a Mechanism and Implementation MIB Module pointer table. That is, some vendors will have a 'standard' mechanism specific MIB Module and a technology specific MIB Module that contains additions or modifications to those items found in the mechanism specific table. This table then would support multiple entries for a single policy which is exactly what we want. Steve W. Can we add this along with the other items I posted? /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 29 07:58: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 HAA27284 for ; Thu, 29 Jun 2000 07:58:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA25307 for snmpconf-outgoing; Thu, 29 Jun 2000 07:42:18 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 29 Jun 2000 07:42:29 -0400 Subject: Re: snmpconf General Functional Questions From: Jon Saperia To: Message-ID: In-Reply-To: <395C7A2E.43501F40@nextbeacon.com> 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 on 06/30/2000 6:45 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > > I agree that the "touch-bit" needs to be instance specific, but placing it in > the role table is pretty heavyweight because it will turn off *all* policies > that control a particular element. Say I need to override a variable for > firefighting purposes but I don't want to also turn off the policy that > applies > QOS to that interface (because that might cause another firefight). The > "touch-bit" should turn off a particular policy from a particular instance. Steve I had not intended that the policy be turned off globally. It was just and indication that a particular element controlled by a policy had been tweaked. That said, the proposal for the pmTrackingElementToPolicyElement may be better than using the role table. The change I would make is that we add an enumeration which is: modified(3) This indicates that the values for a specific element in a specific policy have been changed by a means other than the policy system. > > In the current draft, such a facility exists: > > PmTrackingElementToPolicyEntry ::= SEQUENCE { > pmTrackingElementToPolicyElement RowPointer, > pmTrackingElementToPolicyStatus INTEGER > } > INDEX { pmTrackingElementToPolicyElement, pmPolicyIndex } > > pmTrackingElementToPolicyStatus OBJECT-TYPE > SYNTAX INTEGER { > off(0), > on(1), > forceOff(2) > } > > The forceOff state is the touch-bit. When set, it forcibly disables this > policy from executing on this element. This is fine but different. This value would be considered to be under the control of the policy management system in my view. The modified value indicates that a CLI or other non-policy based method touched the values for this element that are associated with this policy. > > Also, I don't believe in having these bits set as side-effects of setting an > SNMP variable. Reasons include: > 1) An SNMP set for a variable that is under policy control doesn't communicate > the following necessary sentiment: "While I know that this variable is under > policy control, I intend to override that anyway". In other words, the SNMP > engine can't tell whether the request intended to override policy or was an > innocent mistake. It would be hard to say that we're enforcing policy when any > request has carte-blanche to get an exemption. The intent of the user, innocent or not does not matter here. What matters is that a value that was provisioned via the Policy module was changed by something other than the policy module. Certainly a well run system would not give carte-blanche to any user to make modifications. This is one of the reasons why user based security can be helpful in policy management. I might configure my systems under policy control so that only certain 'highly privileged' users can modify the instance level configuration parameters that are under policy control. They off course need this for fire-fighting etc. This model is really no different that when a config file is sent to a router today and is then later modified with a couple of CLI commands by a network engineer because of one problem or another. > 2) Would require changing instrumentation for all MIBs. I do not believe this is so since it is the policy system that will detect this change, not the instance specific instrumentation. There are several ways of doing this, one might be during the re-evaluation of the policy filter associated with each policy. This is not as bad as it might at first seem since all that is required is to know if a value for an instance is different than the default contained in the policy action object directly or in a mechanism or implementation specific module. Another implementation approach could be to separate this check from the instance evaluation since the instances are already known. This could be a computationally less costly approach. For future modules, I suggest more extensive use of notifications. That way when a notification is generated a more timely update can be done with less overhead. > 3) Doesn't specify which policy to override in those cases where a single > variable is under control of multiple policies. > In this case, one would assume multiple entries in your table, one for each policy that an element is a member of. In that case the status would be modified for each policy that the element is a member of. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Thu Jun 29 10:13:50 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 KAA08479 for ; Thu, 29 Jun 2000 10:13:50 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA28911 for snmpconf-outgoing; Thu, 29 Jun 2000 09:58:20 -0400 (EDT) Message-Id: <4.2.2.20000629092716.00a9fed0@omniplex.mcquillan.com> X-Sender: joel@omniplex.mcquillan.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 09:33:56 -0400 To: snmpconf@snmp.com From: "Joel M. Halpern" Subject: Re: snmpconf General Functional Questions In-Reply-To: <395C7A2E.43501F40@nextbeacon.com> References: 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 There are at least two problems that I see being aluded to here. Both are related to the phrase "if a variable is unde3r control of more than one policy". We do need to make sure we understand what we want to happen in that case. 1) If you set that variable with SNMP, assuming that the intention is to override the policy setting of that variable, then I believe that you are overriding ALL the policies which set that variable. Trying to achieve some intermediate state where some of the policies apply to that variable, but not all of them, would be better done by actually changing the set of roles, rather than trying to force-off. force-off is for the case when the manual intervention is moving the variable out of the policy space temporarily. 2) In practice the variable can not really be set by more than one policy. There is some sort of conflict which has essentially been resolved by "last touch wins". Unless we are forcing order of evaluation of policy (and what about order of re-evaluation?) such a conflict resolution mechanism is exceedingly risky. This goes on the conflict resolution thread. Related to this, I believe that the intention of most of the discussants is that if a human being directly modifies a variable whose current state was effected by policy, then that variable better be removed from policy control automatically. Otherwise, the user will get unexpected effects wherein his changes evaporate periodically (or even worse, some of them evaporate, but not all). Yours, Joel M. Halpern At 03:45 AM 6/30/00 -0700, you wrote: > I agree that the "touch-bit" needs to be instance specific, but placing > it in >the role table is pretty heavyweight because it will turn off *all* policies >that control a particular element. Say I need to override a variable for >firefighting purposes but I don't want to also turn off the policy that >applies >QOS to that interface (because that might cause another firefight). The >"touch-bit" should turn off a particular policy from a particular instance. > >In the current draft, such a facility exists: > >PmTrackingElementToPolicyEntry ::= SEQUENCE { > pmTrackingElementToPolicyElement RowPointer, > pmTrackingElementToPolicyStatus INTEGER >} > INDEX { pmTrackingElementToPolicyElement, pmPolicyIndex } > >pmTrackingElementToPolicyStatus OBJECT-TYPE > SYNTAX INTEGER { > off(0), > on(1), > forceOff(2) > } > >The forceOff state is the touch-bit. When set, it forcibly disables this >policy >from executing on this element. > >Also, I don't believe in having these bits set as side-effects of setting an >SNMP variable. Reasons include: >1) An SNMP set for a variable that is under policy control doesn't communicate >the following necessary sentiment: "While I know that this variable is under >policy control, I intend to override that anyway". In other words, the SNMP >engine can't tell whether the request intended to override policy or was an >innocent mistake. It would be hard to say that we're enforcing policy when any >request has carte-blanche to get an exemption. >2) Would require changing instrumentation for all MIBs >3) Doesn't specify which policy to override in those cases where a single >variable is under control of multiple policies. > >Steve > > > >Jon Saperia wrote: > > > on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote: > > > > > Hi, > > > > > > I think the exempt bit needs to be instance-specific, to tell which > > > instance has been overridden. If the "touch-bit" can be cleared via > > > SNMP, it will be important to know WHICH instance should be cleared if > > > there are multiple instances that have been touched. > > > > Exactly so. We are all in agreement on this point. That is why I have > > proposed using the role table which is instance specific. > > > > > > It may also be important for tracking down a security breach to expose > > > which instance was changed. > > > > > > Having the "touch-bit" at the role-abstraction level doesn't allow the > > > necessary granularity. I think it might be nice to have a dirty-flag at > > > the role level, to easily indicate that one or more instances of the > > > role have been overridden. However, I am concerned that having the > > > touch-bit at this level may be problematic. It may be difficult to go > > > from the instance level to the role level easily, as has been discussed. > > > This becomes harder in a mid-level manager situation, where the role > > > evaluation may be done within a different engine, as discussed at the > > > interim meeting. > > > > > > > PmRoleESEntry ::= SEQUENCE { > > pmRoleESElement RowPointer, > > pmRoleESString SnmpAdminString, > > pmRoleESStatus RowStatus > > } > > > > Roles are assigned on an instance specific basis. That is the only way the > > local mechanisms can know were to apply the policy. I do not see the role > > evaluation taking place remotely. One a large machine with many interfaces > > and/or S/PVCs numbering into the many hundreds of thousands, the evaluation > > has to be done locally. This does not mean that a MLM can not participate > > since the MLM application would send the policy filters to the targets for > > evaluation. > > > > I propose that the pmRoleESStatus be the place for the dirty bit. If > that is > > not acceptable, another object in this table. > > > > /jon From owner-snmpconf@seymour39.SNMP.COM Fri Jun 30 12:14:09 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20772 for ; Fri, 30 Jun 2000 12:14:09 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA18097 for snmpconf-outgoing; Fri, 30 Jun 2000 11:54:56 -0400 (EDT) Message-Id: <200006301554.RAA26007@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf New release of the DiffServ Policy MIB From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <21676.962380565.1@y5m638.lmera.ericsson.se> Date: Fri, 30 Jun 2000 17:56:05 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id LAA18091 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Hi, Harrie and I have just sent a new installment of The DiffServ Policy MIB to the Internet Drafts folks. draft-ietf-snmpconf-diffpolicy-02.txt will soon be published on a I-D repository near you. This document will be what we discuss in Pittsburgh. For those of an impatient nature, I have put out the following for your reading pleasure: The document itself: http://www.cs.utk.edu/~partain/draft-ietf-snmpconf-diffpolicy-02.txt The document with change bars (not very helpful since lots has changed, but whatever): http://www.cs.utk.edu/~partain/01-02-doc-cb.txt The diff between the previous version of the MIB and this version: http://www.cs.utk.edu/~partain/01-02-MIB-diff.txt Please send any comments to this mailing list. 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