From owner-snmpconf@seymour39.SNMP.COM Fri Sep 1 18:01:28 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 SAA21640 for ; Fri, 1 Sep 2000 18:01:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA06672 for snmpconf-outgoing; Fri, 1 Sep 2000 17:42:14 -0400 (EDT) Date: Fri, 1 Sep 2000 23:41:39 +0200 Message-Id: <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <39AE9600.4DCF1FD6@enterasys.com> (message from David Harrington on Thu, 31 Aug 2000 13:29:36 -0400) Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> David Harrington writes: David> 3) We need to plan the agenda for the next interim. [...] David> If anybody has any topics they want on the agenda, please speak David> up. I am not sure whether I will be able to attend the next interim (nor did I read the minutes from the last one yet - so the comments below may be out of line), but I am seriously concerned about some issues. I believe that the split between a filter script and an action script is not useful. In fact, this level of granularity will just turn out to be very impractical if you express real-world policies. I actually believe that the unit of concern should be a set of logically related policy rules. (This probably maps to the concept of a PolicyGroup in PCIM.) I expect that a device which will be able to parse and execute the "policy language" for filters and actions will also be able to parse and execute a "policy language" for sets of policy rules. The syntactic details you need to separate rules and actions from filters should be easy to deal with. In fact, not having to expose the filters and actions in separate MIB objects will save you code since the policy language compiler/interpreter can now choose the internal representation that fits best the execution environment. I also expect that network operators will prefer to write and handle sets of logically related policy rules in a single language and to store them in a single file which they push to the managed devices. I don't see much value in taking such a file on the manager side, to tokenize it a bit, turn it into chunks of MIB objects that are pushed to the agent by populating perhaps multiple tables and then ask the agent to reassemble the data and tokenize the rest into a format that can be executed. I certainly like the idea to use languages to implement policies. But we should be careful that we get the granularity right at the policy abstraction level and that we divide the processing load in a reasonable way. Doing a bit parsing here, a bit parsing there and requiring the agent to provide SNMP access at the granularity of single filters and actions is will lead to more complexity on both ends. Of course, once you accept the idea that policy rule sets are the right granularity for distribution at the policy level, you can just use RFC 2592 to distribute and invoke policy rule sets. All which is left to do is to reach agreement on a policy language and we are done with it. While reading the minutes form the Friday meeting, I got the feeling that RFC 2592 actually provides answers for quite a few of the issues discussed in Pittsburgh such as identifying language versions, language extensions, handling and reporting of syntactic errors, handling and reporting of execution errors, etc. I recommend that this WG leverages existing work and focuses the resources that are available on the new stuff that is in front of us and that the WG reconsiders the granularity needed to distribute policies to policy-enabled managed devices. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Sat Sep 2 09:21:08 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13318 for ; Sat, 2 Sep 2000 09:21:07 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA03771 for snmpconf-outgoing; Sat, 2 Sep 2000 09:04:21 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 02 Sep 2000 09:06:44 -0400 Subject: Re: snmpconf well, back to work From: Jon Saperia To: , Randy Bush , Bert Wijnen Message-ID: In-Reply-To: <39AE9600.4DCF1FD6@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 08/31/2000 1:29 PM, David Harrington at dbh@enterasys.com wrote: > The authors' bulleted lists worked especially well for identifying > issues to be resolved. We need to verify WG consensus on Pittsburgh > proposed solutions for the bulleted items. Could the authors publish the > lists again, and describe potential agreements reached in Pittsburgh, > and identify which items still have no potential agreement after > Pittsburgh? > > If anybody has any topics they want on the agenda, please speak up. > > Thanks, > dbh > -- Thanks very much. At least as a place holder, for an agenda topic Mike and I would like to go over issues with the BCP. I know Mike did get some feedback and I have more to write before we publish in advance of the interim. Thanks /jon P.S. - If I remember correctly we have the ADs OK on this, just checking. I know that Bert has been away for a while so Randy is probably backed up as well. From owner-snmpconf@seymour39.SNMP.COM Mon Sep 4 07:29: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 HAA02391 for ; Mon, 4 Sep 2000 07:29:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA16180 for snmpconf-outgoing; Mon, 4 Sep 2000 07:07:46 -0400 (EDT) Message-ID: <39B38234.401A5F81@ccrle.nec.de> Date: Mon, 04 Sep 2000 13:06:28 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> 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 Juergen, > I believe that the split between a filter script and an action script > is not useful. In fact, this level of granularity will just turn out > to be very impractical if you express real-world policies. I actually > believe that the unit of concern should be a set of logically related > policy rules. (This probably maps to the concept of a PolicyGroup in > PCIM.) I do not understand your concern. I think the split is very useful, because from it nature filters and actions are different things and have different properties. Why are they impractical? > While reading the minutes form the Friday meeting, I got the feeling > that RFC 2592 actually provides answers for quite a few of the issues > discussed in Pittsburgh such as identifying language versions, > language extensions, handling and reporting of syntactic errors, > handling and reporting of execution errors, etc. I recommend that this > WG leverages existing work and focuses the resources that are > available on the new stuff that is in front of us and that the WG > reconsiders the granularity needed to distribute policies to > policy-enabled managed devices. I aggree with Juergen, that many Problems discussed in Pittsburgh can be solved using RFC 2592. Are there reasons not to use RFC 2592? Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-snmpconf@seymour39.SNMP.COM Mon Sep 4 09:42: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 JAA03836 for ; Mon, 4 Sep 2000 09:42:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA18535 for snmpconf-outgoing; Mon, 4 Sep 2000 09:22:10 -0400 (EDT) Message-ID: <39B3A162.5E70AEA6@ccrle.nec.de> Date: Mon, 04 Sep 2000 15:19:30 +0200 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B38234.401A5F81@ccrle.nec.de> 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 Marcus Brunner wrote: > > Juergen, > > > I believe that the split between a filter script and an action script > > is not useful. In fact, this level of granularity will just turn out > > to be very impractical if you express real-world policies. I actually > > believe that the unit of concern should be a set of logically related > > policy rules. (This probably maps to the concept of a PolicyGroup in > > PCIM.) > > I do not understand your concern. I think the split is very useful, > because from it nature filters and actions are different things and have > different properties. Why are they impractical? It is impractical because of the fine granularity. The problem is not only the separation of filters and actions but also the implied separate handling of each policy. I do not see the need to handle and modify each single policy separately on the device level. Rather I see a significant potential for simplification of both the SNMP agent and the management applications, if policies are being managed in terms of policy groups. If you would extend the proposed policy language by separators between filters and actions, and by separators between different policies, you could describe a complete policy group by a single piece of code that can be handled as a one entity. Then, the size of the policy tables would depend on the number of groups rather than on the number of policies; activating a group would be possible by a single activation seqence; and so on. This might be really "practical". Juergen Quittek -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 30 254230-19 NEC Europe Ltd., C&C Research Laboratories Fax: +49 30 254230-99 Hardenbergplatz 2, 10623 Berlin, Germany http://www.ccrle.nec.de From owner-snmpconf@seymour39.SNMP.COM Tue Sep 5 08:07: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 IAA29407 for ; Tue, 5 Sep 2000 08:07:50 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA27018 for snmpconf-outgoing; Tue, 5 Sep 2000 07:49:08 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 05 Sep 2000 07:51:42 -0400 Subject: snmpconf FW: FYI ... An article on CIM, Policy Framework WG and modeling from Network Computing 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 Sorry, for the cross post, but the article that Andrea points to is of interest to the SNMPCONF WG. /jon ---------- > From: "Andrea Westerinen" > Date: Tue, 5 Sep 2000 01:07:54 -0700 > To: "Nim@Psg. Com" , "Policy@Raleigh. Ibm. Com" > > Subject: FYI ... An article on CIM, Policy Framework WG and modeling from > Network Computing > > Feature: Management Standards Come Together > ------------------------------------------------------------ > (September 4, 2000) > By Bruce Boardman > Will management standards deliver on their promise of true > interoperability? Standards groups are collaborating to provide an > overarching framework with buy-in from all the major industry > vendors. Can they pull it off? Here's our take: > http://www.nwc.com/1117/1117f3.html?ls=NCJS_NL160 > > > Andrea > From owner-snmpconf@seymour39.SNMP.COM Tue Sep 5 11:56: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 LAA06127 for ; Tue, 5 Sep 2000 11:56:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA04771 for snmpconf-outgoing; Tue, 5 Sep 2000 11:39:51 -0400 (EDT) Message-Id: <200009051539.LAA19216@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf Interim Meeting Notes Day One Date: Tue, 05 Sep 2000 11:39:45 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The following are the interim meeting notes for day one of the SNMPCONF working group interim meeting that took place in Pittsburgh PA on August 4 and 5, 2000. If you have comments or clarifications, please send them to moulton@snmp.com. Please submit any changes you have by end of the day Wednesday September 6. I will merge changes and submit the minutes to the IETF on Thursday September 7, and resubmit them to this list if there are significant changes. I have received no slides for the first day of the interim meeting, and only Thippana Hongal's slides for the second day. If you have slides to include, please submit them as soon as convenient. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com SNMPCONF Interim Working Group Meeting Summary Pittsburgh, PA, USA August 4th and 5th, 2000 This set of notes is for the part of the meeting that took place on August 4, 2000. The Configuration Management with SNMP (SNMPCONF) working group met during an interim session on Friday and Saturday, August 4 and 5, 2000. The purpose of this meeting was to continue making forward progress while parties were present for the 48th IETF. The note takers for this session were Shawn Routhier and Steve Moulton. The first topic for discussion was which language might be used to express policy to the SNMPCONF policy. A subset of C that might be used has been laid out in draft-ietf-snmpconf-pm-02.txt. This discussion was moderated by Steve Waldbusser, and is a continuation of the discussion started in the second meeting of the SNMPCONF Working Group during the 48th IETF. Item 4: Language Extensibility. The first question on the floor is whether or not we should state that we permit vendor-specific language subsetting. In particular: Issue 1: Do we allow vendor specific subsetting of the language There is general agreement that as a working group we can't stop producers from behaving in various fashions, but we can specify what is compliant with the specification and what isn't. There was some discussion about what level of extensibility we can and should provide. The options included trying to trying to limit extensibility, allowing it but frowning on it, attempting to provide for it directly, and allowing unknown extensions to be handled gracefully. There were the usual interoperability concerns and the concern that limiting growth of the language will limit its deployment. Specifically on the issue of subsetting the language, the statement was made that not allowing subsetting may drive us to reduce the number of functions included in the specification in order to get as wide deployment as possible of the required functionality set. The observation was also made that we can expand the requirements of the language in a second version. On putting the question, there was general agreement that we should not permit vendor specific subsetting of the language in the first version. Issue 2: Do we allow vendor specific subsetting of the accessor functions? The first concern had to do with systems that do not have the concept of time. The sense of the room from this morning's session is that we will not mandate time of day clocks. Is the current set of accessor functions sufficient? It does not allow many possible options such as getting an entire row. It is generally agreed that the current set is not sufficient and more will be required. But how should they be presented? As one example if we include accessor functions for SNMPv3 then what should happen if the agent doesn't support v3. In such a case we might want to have something similar to libraries such that different sets can be included. For the first revision we may want to keep the list short and simple and add new ones after we gain some experience with the scheme. Some of the experience can be gathered from other similar areas. But if the current list is not the final one then attempting to discuss this issue may be premature. Until we have a reasonable list we can't be specific. One probably will not have a good handle on which accessor functions are needed until one has built a set of applications. There are expression evaluators that have been in the industry for a few years, from which we can draw lessons. . Can we have a statement of direction that we should attempt to define the minimum mandatory set such that everybody can implement it? The suggestion was made that we have containers of functions - the equivalent of libraries and that the minimum compliance object would be those groups. So some of the libraries would be conditionally required but we would not end up with a constantly growing list. The libraries might be viewed as putting some hierarchy into the naming, instead of having one flat name space have a two level name space. Steve Waldbusser proposed a set of classes of things that might not be implemented on a given system: . Can't do (turnOffPower()) . Too Complex (code size/cpu speed limitations) . Convenience Functions: too many functions specified One proposal that rather than follow this approach we will specify a minimal set of functions so that no one will have a good excuse not to implement the entire set of functions in version one of this language. Another proposal is that we have two classes of accessor functions, one which must be implemented, and one that should, but that without which one may still claim compliance. Functions to do RMON-specific things are one such example quoted. One participant expressed a wish to have date and time functions split off into a separate group for compliance purposes. Another suggested that there be three classes of accessor functions: . mandatory . MIB-related (i.e. RMON support) . device-related (power on/off, date and time). Furthermore we need a way for the managed element to tell a manager what subsets of functions a device supports. When put to the group, there was general agreement that we need groups of accessor functions for compliance purposes. Furthermore there was general agreement that we were going to be very rigorous in adding functions to the various groups. Discussion then shifted to how one indicates whether a particular group is supported in an agent. One proposal was to specify using a bit string object, the other using a table of supported groups (an agent capabilities table). The first proposal would require less agent resources, the second may be easier to implement on run-time extensible agents. A concern was made that we are departing from the policy model, where we send a policy to all boxes and have the boxes decide for themselves how to implement that policy. This would require that the policy-issuing entity know capabilities of each device. One way to handle this would be to bind accessor groups to MIBs being accessed by a particular policy. A smaller team was chartered to discuss this outside of the group and report tomorrow. The group consisted of Jeff Case, Steve Waldbusser, David Harrington and Walter Weiss. [break] Jon Saperia asked the subgroup to study issues of collapsing capabilities table information also. What is the best way to advertise availability of accessor libraries? The next set of language and accessor issues: Issue 3: Do we allow vendor extension of the language Issue 4: Do we allow vendor extension of the accessor functions Issue 5: Do we recognize vendor extensions of the accessor functions Walter Weiss made the point that the premise of policy is that we are trying to work across devices to make management a simpler world. He suggests no to c and yes to d. Bert Wijnen made the opposing point that this working group was formed because of concern from the SNMP community about two management protocols. This group was tasked to do both policy-based management and configuration management. He was concerned that in the interest of simplicity and adherence to the policy model we may remove too much functionality for configuration via SNMP. Jon Saperia made the point that we need to difference between policy based configuration (across systems) and configuration of policy (diffserv). It is also true that we need to know a bunch of capabilities of the machine before we send policy to it. This is very valuable configuration management. In the charter we two have goals. I don't think they conflict with each other, so we need to do both. We haven't excluded one or the other at this point. After a considerable discussion the question was called on issue c, and there was fairly strong consensus that we did not want to allow vendor extension of the language. There was general agreement that we do want to allow vendor extension of the accessor functions (issue 4). There were three different proposals for determining the presence of vendor extensions. One was to have a accessorExists(accessorFunction) function, another to have a BITS construct for enumerating what functionality is present, and the third was to use the capabilities mechanism already familiar. In response to a concern about name space conflicts, a suggestion was made to use part of the company's DNS name as part of the function name to guarantee uniqueness (like is done in Java). The observation was also made that if we can do this within the SMI, we already know how to deal with it. Issue 5 is being deferred to the smaller group. Issue 6: How do we handle versioning issues, is being sent to the small group. Issue 7: Changes in OID issue is also being sent to the small group. Issue 8: How do we specify attributes of an element? Can there be multiple instances? As discussed this morning [ IETF48 SNMPCONF Working Group Meeting -ed], multiple instances can be specified as name.$1.$2.$3. Issue 9: deferred (not available in notetaker's notes) Issue 10: How big can an expression be? An arbitrary limit of 64K was mentioned; there is no real limit. This was discussed in the morning session. The point was made that we need to pay special attention into buffer overflow problems since this is a script issue. Good programming practice should be adequate. Issue 11: Temporary Variables: do we want them? How do we dispose of them? There was strong sentiment that temporary variables are needed. Questions were raised about the scope and lifetime of temporary variables. Possibilities such as the use of a global scratch pad and emulating MIB variables were raised. The use of temporary variables for lag variables and trending was discussed, as well as for generally saving state in a loop. It is necessary that any global variables created have some indexing to prevent access anomalies across different scripts. The requirement that each policy has to have a local temporary variable space was mentioned. The issue of short-circuiting loop execution arose. Once again the discussion arose whether we are taking the policy view (all devices) or configuration view (one or more devices). It was suggested that this topic be taken away and discussed further tomorrow. Jon Saperia reviewed the working assumptions again: 1) We cannot invent a new language 2) We want to use something that is as familiar as possible to as many people as possible. We settled on Java, Perl, and C as possibilities. What is currently in the document is a subset of the intersection of C and PERL. 3) We are not saying that different languages can be used in different evaluations. We are discussing the concept of a break statement in a loop construct, the storage of temporary variables, and the ability to preserve information across executions. We need to have a side discussion on this issue. [break] Issue 12: Debug-able execution environment. Issues include . Memory leak detection . ability to find and fix bugs . find looping and iterators The suggestion was made that we may need to have watchdog timers to break out of iterations, or perhaps to set a limit on the number of times to iterate. If using a timer scheme, one needs to be able to match timeout information to restart information. The ability to trace execution through a script is very important. One might use a log table to log output from the script for debugging purposes. Implementing a trace function as an accessor function was suggested. Issue 13: Do we permit comments? We need to explicitly say so. There was a general feeling in the room that comments should not disappear from scripts. Gets on the script should retrieve the same contents that sets put with respect to comments. A more general issue about string length arose at this point. There was concern about string length being limited by PDU size. The question was put as to whether we should modify the policy table and add a new table to allow for longer strings. There was strong agreement for this change. David Harrington mentioned that some script interpreter code was in use at Enterasys, and that he might be able to contribute this interpreter to the community at large. The possibility of using bc (the unix binary calculator) was also mentioned, as was PHP (from the Apache world). Script re-usability was also discussed at this point; specifically whether a script can refer to another script already in the device. Currently this is not a capability of the MIB. The following MIBlet was put on screen PmPolicyEntry ::= SEQUENCE { pmPolicyIndex Integer32, pmPolicyFilter OCTET STRING, pmPolicyAction OCTET STRING ... } The suggestion was made to replace the pmPolicyFilter with a script MIB entry. The opposing view was that we should not pull in the script MIB, but add multiple lines of text to the pmPolicyTable. The suggestion was made to change the pmPolicyFilter and the pmPolicyAction octet strings into integers. The clear sense of the room was to split out the pmPolicyTable now, and replace these objects with integer indices. At this point, a brief review of issues for tomorrow's meeting was made. From owner-snmpconf@seymour39.SNMP.COM Tue Sep 5 17:10: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 RAA13906 for ; Tue, 5 Sep 2000 17:10:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA15215 for snmpconf-outgoing; Tue, 5 Sep 2000 16:51:26 -0400 (EDT) Message-ID: <39B55D08.20FD256A@nextbeacon.com> Date: Tue, 05 Sep 2000 13:52:24 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > > I believe that the split between a filter script and an action script > is not useful. In fact, this level of granularity will just turn out > to be very impractical if you express real-world policies. I actually > believe that the unit of concern should be a set of logically related > policy rules. (This probably maps to the concept of a PolicyGroup in > PCIM.) I've been collecting and writing examples and haven't yet come up with any impracticalities, much less a class of policy scenarios that aren't handled by this architecture. The split between filter (aka condition) and action follows existing practice in other policy work (e.g. the policy WG). Some of the benefits of splitting them include: - Because all filter information is separate, the manager can inspect the filter and understand whether to download the policy to an agent (i.e. "this policy will never execute on this system so I don't need to download it") - Because filter information is separate, the agent can schedule filter evaluation separately from action evaluation. If I have 50,000 circuits, I might not want to evaluate the filter as often as I want to assert the action. Conversely, if the action is more costly than the filter, I might want the filter evaluated more frequently (to more quickly discover new elements to which to policy should apply) - The filter expression is known to be idempotent, information that both manager and agent can use for optimization. - It is easier to re-use filter and action expressions when they are separate. Imagine a policy authoring environment that lets you drag an icon representing "all ethernet access ports" and associate it with an icon representing "mark voice with CP 35". The split is a fundamental part of the architecture so I expect we can keep coming up with other existing benefits to add to the list. > I also expect > that network operators will prefer to write and handle sets of > logically related policy rules in a single language and to store them > in a single file which they push to the managed devices. This is true only if they were trying to build policy by hand on top of a scripting system. We are building them an infrastructure (our standard plus the applications that will stem from it) that will make it more convenient than doing it by hand. > I don't see > much value in taking such a file on the manager side, to tokenize it a > bit, turn it into chunks of MIB objects that are pushed to the agent > by populating perhaps multiple tables and then ask the agent to > reassemble the data and tokenize the rest into a format that can be > executed. I'm not sure if you understand the current document. There's no tokenization or reassembly of code. Each filter or action expression contains everything necessary to do its job. > Of course, once you accept the idea that policy rule sets are the > right granularity for distribution at the policy level, you can just > use RFC 2592 to distribute and invoke policy rule sets. All which is > left to do is to reach agreement on a policy language and we are done > with it. > > While reading the minutes form the Friday meeting, I got the feeling > that RFC 2592 actually provides answers for quite a few of the issues > discussed in Pittsburgh such as identifying language versions, > language extensions, handling and reporting of syntactic errors, > handling and reporting of execution errors, etc. I recommend that this > WG leverages existing work and focuses the resources that are > available on the new stuff that is in front of us and that the WG > reconsiders the granularity needed to distribute policies to > policy-enabled managed devices. Our execution environment is much different than that for the Script MIB. While the script MIB is for generic scripted applications, the PM MIB execution environment is purpose-built for processing policy expressions. We require facilities that aren't in the script mib such as: - Our filter expressions are called once for each element. - Our action expressions are called once for each element that passed the filter. - Our expressions expect to be passed the identity of the "current element" as a parameter. - Our environment periodically re-runs expressions The script MIB also allows things we need to disallow - Ad-hoc invocation of expressions - multiple languages - download of script by http - Trap sent on every error - ... (would require thorough analysis to complete this list) The Script MIB is a great generic scripting mechanism but it would be very awkward to use for our application because the differences are greater than the similarities. Steve From owner-snmpconf@seymour39.SNMP.COM Wed Sep 6 08:33:55 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 IAA10121 for ; Wed, 6 Sep 2000 08:33:55 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA14470 for snmpconf-outgoing; Wed, 6 Sep 2000 08:12:12 -0400 (EDT) Message-ID: <39B6344D.32B7177A@ccrle.nec.de> Date: Wed, 06 Sep 2000 14:10:53 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.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 Steve, > > Of course, once you accept the idea that policy rule sets are the > > right granularity for distribution at the policy level, you can just > > use RFC 2592 to distribute and invoke policy rule sets. All which is > > left to do is to reach agreement on a policy language and we are done > > with it. > > ... > > Our execution environment is much different than that for the > Script MIB. While the script MIB is for generic scripted > applications, the PM MIB execution environment is purpose-built > for processing policy expressions. If the Script MIB is built for generic scripts it runs also for policy "scripts". And I don`t see that they are really different. > > The script MIB also allows things we need to disallow > - Ad-hoc invocation of expressions > - multiple languages Allows to include the policy language you are developing. > - download of script by http Could be a nice idea to download policies via http, isn`t it? > - Trap sent on every error > - ... (would require thorough analysis to complete this list) > > The Script MIB is a great generic scripting mechanism but it > would be very awkward to use for our application because the > differences are greater than the similarities. I do not aggree with that statement. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 6 12:53:32 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17530 for ; Wed, 6 Sep 2000 12:53:31 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA23865 for snmpconf-outgoing; Wed, 6 Sep 2000 12:32:34 -0400 (EDT) Message-ID: <39B671EC.3BC48A60@covalent.net> Date: Wed, 06 Sep 2000 09:33:48 -0700 From: Harrie Hazewinkel Organization: Covalent technologies X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.com> <39B6344D.32B7177A@ccrle.nec.de> 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 all, This is just an update on the situation with respect to the DiffPolicy-MIB module. The third work item of this WG. At the last IETF it was discussed that major changes will be done to the DiffServ-MIB module. More precise, the indexing scheme will change. These will be defined in next release of the DiffServ-MIB draft. The effect on the DiffPolicy-MIB module will be that the MIB module will change according to the indexing scheme changes of the DiffServ MIB module. How it all exactly happens, I would like to wait until the DiffServ MIB module is published. They are close to publishing the new draft. Hope to have you all informed of the situation. Cheers, Harrie 0- Harrie Hazewinkel ---------------------------------------0 mailto:harrie@covalent.net phone:+1-415-536-5221 0-----------------------------------------------------------0 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 6 15:26: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 PAA21226 for ; Wed, 6 Sep 2000 15:26:53 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA29148 for snmpconf-outgoing; Wed, 6 Sep 2000 15:10:02 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 06 Sep 2000 15:12:34 -0400 Subject: Re: snmpconf well, back to work From: Jon Saperia To: Message-ID: In-Reply-To: <39B671EC.3BC48A60@covalent.net> 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 09/06/2000 12:33 PM, Harrie Hazewinkel at harrie@covalent.net wrote: > The effect on the DiffPolicy-MIB module will be that the > MIB module will change according to the indexing scheme > changes of the DiffServ MIB module. How it all exactly > happens, I would like to wait until the DiffServ MIB > module is published. They are close to publishing the > new draft. Thanks very much for the update. I am confused. I thought the last version recently published would have the changes. I take it that there is another on the way fairly soon. Correct? /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 6 16:19:19 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 QAA22362 for ; Wed, 6 Sep 2000 16:19:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA01372 for snmpconf-outgoing; Wed, 6 Sep 2000 16:03:14 -0400 (EDT) Message-Id: <200009062003.QAA01366@seymour39.SNMP.COM> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 06 Sep 2000 15:38:29 -0400 To: snmpconf@snmp.com X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: snmpconf well, back to work In-Reply-To: References: <39B671EC.3BC48A60@covalent.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Please reply inline. -- Kwok -- At 03:12 PM 9/6/00 -0400, Jon Saperia wrote: >on 09/06/2000 12:33 PM, Harrie Hazewinkel at harrie@covalent.net wrote: > >> The effect on the DiffPolicy-MIB module will be that the >> MIB module will change according to the indexing scheme >> changes of the DiffServ MIB module. How it all exactly >> happens, I would like to wait until the DiffServ MIB >> module is published. They are close to publishing the >> new draft. > >Thanks very much for the update. I am confused. I thought the last version >recently published would have the changes. I take it that there is another >on the way fairly soon. > >Correct? Jon, I think the last version you are mentioning is DiffServ MIB-04. Which Joel asked for a new table in the Pittsburgh DiffServ WG session. DiffServ MIB-05 contains that table, called DataPathTable. This will be published on the Diff Serv list shortly. > >/jon > From owner-snmpconf@seymour39.SNMP.COM Wed Sep 6 18:18:43 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 SAA24108 for ; Wed, 6 Sep 2000 18:18:42 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA05748 for snmpconf-outgoing; Wed, 6 Sep 2000 18:01:10 -0400 (EDT) Message-ID: <39B6BE04.9CD38BCE@enterasys.com> Date: Wed, 06 Sep 2000 17:58:28 -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 New co-chair 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, Because of time constraints, I have decided to step down as SNMPCONF WG co-chair. I plan to continue to work within the WG, but do not have the time available to do the co-chair position justice. Dave Partain has volunteered to take over this position. The AD has approved this change. Dave's available time and his knowledge of the work done so far should enable him to contribute as co-chair more than I have been able to do. Welcome, David. See you all on the list, dbh -- --- David Harrington Network Management Standards Architect 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 Sep 7 05:22:14 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14160 for ; Thu, 7 Sep 2000 05:22:13 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA28340 for snmpconf-outgoing; Thu, 7 Sep 2000 05:03:52 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 07 Sep 2000 05:06:31 -0400 Subject: snmpconf Interim Meeting Dates 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 those of you who were at the IETF or have read the minutes know, we discussed having an interim meeting in October. A number of dates were discussed at the interim in Pittsburgh including October 12 - 13 and October 19 - 20. For a number of reasons some of those dates are problematic. SNMP Research has generously offered to host the next interim in Knoxville, TN. I would like to propose one of two alternative dates: October 16 and 17 (A Monday and Tuesday) October 26 and 27 (A Thursday and Friday) Please express your preferences if you plan on attending so that we can let the ADs know and work on the logistics. Thanks very much. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 05:27: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 FAA14199 for ; Thu, 7 Sep 2000 05:27:35 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id FAA28484 for snmpconf-outgoing; Thu, 7 Sep 2000 05:10:57 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 07 Sep 2000 05:13:36 -0400 Subject: Re: snmpconf New co-chair From: Jon Saperia To: Message-ID: In-Reply-To: <39B6BE04.9CD38BCE@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 09/06/2000 5:58 PM, David Harrington at dbh@enterasys.com wrote: > Hi, > > Because of time constraints, I have decided to step down as SNMPCONF WG > co-chair. I plan to continue to work within the WG, but do not have the > time available to do the co-chair position justice. > > Dave Partain has volunteered to take over this position. The AD has > approved this change. > On behalf of myself and the working group, I would like to thank David Harrington for his efforts on our behalf to date. As many of you know, there are countless time-consuming tasks to perform as a co-chair. He really helped us get the ball rolling. Thanks again for your contributions to date and for contributions yet to come. I look forward to working with David Partain as co-chair. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 09:51:14 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16201 for ; Thu, 7 Sep 2000 09:51:14 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA04085 for snmpconf-outgoing; Thu, 7 Sep 2000 09:33:27 -0400 (EDT) Message-ID: <39B7989D.374FE977@enterasys.com> Date: Thu, 07 Sep 2000 09:31:10 -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 Interim Meeting Dates 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, Either set of dates is fine by me. dbh Jon Saperia wrote: > > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can let > the ADs know and work on the logistics. > > Thanks very much. > > /jon -- --- David Harrington Network Management Standards Architect 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 Sep 7 11:02: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 LAA17872 for ; Thu, 7 Sep 2000 11:02:50 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA07173 for snmpconf-outgoing; Thu, 7 Sep 2000 10:44:18 -0400 (EDT) Message-Id: <200009071444.KAA07165@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: RE: snmpconf Interim Meeting Dates Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 07 Sep 2000 10:44:15 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit [message forwarded; bounced due to address change] ------- Forwarded Message From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Interim Meeting Dates Date: Thu, 7 Sep 2000 17:18:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Both dates are OK for me, with a slightest personal preference for October 26 and 27. Regards, Dan > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Thu September 07 2000 11:07 > To: snmpconf > Subject: snmpconf Interim Meeting Dates > > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and > October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in > Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can > let > the ADs know and work on the logistics. > > Thanks very much. > > /jon > ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 11:13: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 LAA18183 for ; Thu, 7 Sep 2000 11:13:37 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA07702 for snmpconf-outgoing; Thu, 7 Sep 2000 10:56:08 -0400 (EDT) Message-Id: <200009071456.KAA07697@seymour39.SNMP.COM> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 07 Sep 2000 10:48:53 -0400 To: snmpconf@snmp.com X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: snmpconf Interim Meeting Dates Cc: snmpconf In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com My preference will be: October 26 and 27 (A Thursday and Friday) Thanks! -- Kwok -- At 05:06 AM 9/7/00 -0400, Jon Saperia wrote: >As those of you who were at the IETF or have read the minutes know, we >discussed having an interim meeting in October. A number of dates were >discussed at the interim in Pittsburgh including October 12 - 13 and October >19 - 20. For a number of reasons some of those dates are problematic. > >SNMP Research has generously offered to host the next interim in Knoxville, >TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > >Please express your preferences if you plan on attending so that we can let >the ADs know and work on the logistics. > >Thanks very much. > >/jon > From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 13:36:53 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 NAA21847 for ; Thu, 7 Sep 2000 13:36:53 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA13354 for snmpconf-outgoing; Thu, 7 Sep 2000 13:22:11 -0400 (EDT) Message-Id: <200009071722.NAA13347@seymour39.SNMP.COM> X-Mailer: exmh version 2.0.1 12/23/97 to: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Dates Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 07 Sep 2000 13:22:07 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit [message forwarded; bounced due to address change] ------- Forwarded Message Message-ID: <39B7AF42.A22B1C3F@riverstonenet.com> Date: Thu, 07 Sep 2000 10:07:46 -0500 From: Thippanna Hongal Organization: Riverstone Network Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Dates References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My preference is 26 and 27 th October, thanks hongal > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can let > the ADs know and work on the logistics. > > Thanks very much. > > /jon -- thanks hongal ------- End of Forwarded Message From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 13:52:22 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22113 for ; Thu, 7 Sep 2000 13:52:21 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA13694 for snmpconf-outgoing; Thu, 7 Sep 2000 13:35:42 -0400 (EDT) From: dfrancis@cisco.com Message-Id: <200009071735.KAA03518@itech-view5.cisco.com> Subject: Re: snmpconf Interim Meeting Dates To: snmpconf@snmp.com Date: Thu, 7 Sep 2000 10:35:06 -0700 (PDT) Cc: dfrancis@cisco.com (Dale Francisco) In-Reply-To: from "Jon Saperia" at Sep 07, 2000 05:06:31 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, For me Oct 16-17 is much preferable. Might not be able to make Oct 26-27. Thanks, Dale --- /// Dale Francisco IOS Network Management Protocols \\\ Cisco Systems dfrancis@cisco.com /// 170 W Tasman Dr SJCM/2 voice: (408) 527-9787 \\\ San Jose CA 95134-1714 USA fax: (408) 527-2477 > > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can let > the ADs know and work on the logistics. > > Thanks very much. > > /jon > > From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 16:01:48 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25663 for ; Thu, 7 Sep 2000 16:01:48 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id OAA17398 for snmpconf-outgoing; Thu, 7 Sep 2000 14:53:08 -0400 (EDT) Message-ID: <39B7E457.567FEC89@nextbeacon.com> Date: Thu, 07 Sep 2000 11:54:15 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Dates 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 October 16 and 17 is much better - will save me a cross-country flight as I will already be "in the neighborhood". I can also make the 26th and 27th. Steve Jon Saperia wrote: > > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can let > the ADs know and work on the logistics. > > Thanks very much. > > /jon From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 16:04:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25835 for ; Thu, 7 Sep 2000 16:04:07 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA13904 for snmpconf-outgoing; Thu, 7 Sep 2000 13:42:54 -0400 (EDT) Date: Thu, 7 Sep 2000 13:42:13 -0400 (EDT) From: Chris Elliott To: snmpconf@snmp.com cc: Dale Francisco Subject: Re: snmpconf Interim Meeting Dates In-Reply-To: <200009071735.KAA03518@itech-view5.cisco.com> 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 Ditto. Oct 16-17 is preferable. Chris. On Thu, 7 Sep 2000 dfrancis@cisco.com wrote: > Jon, > > For me Oct 16-17 is much preferable. Might > not be able to make Oct 26-27. > > Thanks, > Dale > > --- > /// Dale Francisco IOS Network Management Protocols > \\\ Cisco Systems dfrancis@cisco.com > /// 170 W Tasman Dr SJCM/2 voice: (408) 527-9787 > \\\ San Jose CA 95134-1714 USA fax: (408) 527-2477 > > > > > As those of you who were at the IETF or have read the minutes know, we > > discussed having an interim meeting in October. A number of dates were > > discussed at the interim in Pittsburgh including October 12 - 13 and October > > 19 - 20. For a number of reasons some of those dates are problematic. > > > > SNMP Research has generously offered to host the next interim in Knoxville, > > TN. I would like to propose one of two alternative dates: > > > > October 16 and 17 (A Monday and Tuesday) > > October 26 and 27 (A Thursday and Friday) > > > > Please express your preferences if you plan on attending so that we can let > > the ADs know and work on the logistics. > > > > Thanks very much. > > > > /jon > > > > > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 18:55:48 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28774 for ; Thu, 7 Sep 2000 18:55:47 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id SAA27181 for snmpconf-outgoing; Thu, 7 Sep 2000 18:37:59 -0400 (EDT) Message-Id: <200009072237.SAA29818@aix43.snmp.com> to: snmpconf@snmp.com Subject: snmpconf Interim Meeting Notes Day Two Date: Thu, 07 Sep 2000 18:37:50 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The following are the interim meeting notes for day two of the SNMPCONF working group interim meeting that took place in Pittsburgh PA on August 4 and 5, 2000. If you have comments or clarifications, please send them to moulton@snmp.com. Please submit any changes you have by mid-day Friday September 8. I will merge changes and submit the minutes to the IETF on Friday, September 8, and resubmit them to this list if there are significant changes. My apologies for the short notice on this; I am going out of town on Saturday. I have received no slides for the first day of the interim meeting, and only Thippana Hongal's slides for the second day. If you have slides to include, please submit them as soon as convenient. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com Come see us at Networld+Interop in Atlanta, booth #6169 SNMPCONF Interim Working Group Meeting Summary Pittsburgh, PA, USA August 4th and 5th, 2000 The Configuration Management with SNMP (SNMPCONF) working group met during an interim session on Friday and Saturday, August 4 and 5, 2000. The purpose of this meeting was to continue making forward progress while parties were present for the 48th IETF. The note takers for this session were Shawn Routhier and Steve Moulton. SNMPCONF 8/5/00 9 AM Jon Saperia was the first moderator for the day. He started the the meeting stating that he would like to pick a few issues that are solvable so that we have some progress by the end of the day. Joel Halpern has agreed to lead a discussion on what we mean by policy. (he is now Policy Framework WG Co-Chair). Lists of items that we may tackle today (not in any order): Review of Policy Override (90 mins) Capabilities table in BCP (scratch) Schedule and Time (45 minutes) testing and debug (deferred) what about diagnostic information - what might be required for larger scale scripts fate sharing and groups - do groups have special meaning in eval possible use of groups with precedence, groups could be used to collect all members of one class (all QoS) or in order to pick a member of a class (best security option from the list) (90 mins) diffserv policy module (5 mins) planning next steps (30 mins) discussion of policy examples (45 mins) David Partain asked from the floor if there any chance of getting closure on the language issue. He would like to take what is there and run with it, or if we are going to spin our wheels on it a little bit more. This affects many other issues. It would be nice to have some resolution. The comment was made that some of the difficulty of yesterday is we were trying too hard to reach closure on everything in the absence of examples. Jon Saperia stated that there does not seem to be a consensus to add language to today's topics. There was a discussion that resulted in the table above. Andy Bierman requested that we discuss putting mechanisms in the MIB to help debug when configuring arbitrarily large systems. He does not want to schedule time at this point though. Topic 1: Discussion of Policy Examples. Lead by Joel Halpern. Joel: At this point I am trying to collect suggestions as to what policy is. What kinds of problems are we trying to solve? Many dimensions were brought up, including . Creating a persistent change (sticks across reboot) versus a temporary change. . Cause a change on all entities running a particular application . Selection based on vendor, model, software/firmware versions, installed capabilities. . Selection based on resource availability, disk usage, cpu usage, forwarding capability. . Selection based on utilization . Selection based on role. A specific case was mentioned, where one has a configuration that one wants to apply to N different systems, but each is slightly different. Sometimes the selection substitutions are easy and sometimes they are hards. An example: IP address/netmask substitution is easier than distributing a configuration that is thresholding on a temporary storage area on a variety of different systems. This is quite different on a NT vs. unix, or a Cisco vs. Nortel. We need to hide that from an operator who might not be completely aware of the implications. Subsequent discussion brought up many issues. Many vendors currently have proprietary solutions for doing these types of things, where we are trying to evolve an interoperable multi-vendor environment. It is normal to provision for what you care about, and services/customers that don't receive any preference get the leftovers. The opposite approach is to limit by service (say let video have as a maximum 30% of the bandwidth), but many will want to do this. It was mentioned that this approach may have multiple ways of being provided and that stating the policy goal in this way may lead to an under-constrained solution. Other possible requirements were brought up: . The ability to specify roles to the system about how to react over time to configuration or state changes. . For security reasons, the ability to disable all ports that are not explicitly enabled. . Avoid multiple scripts for minor device variations. . Enable coherence of configuration across devices. Systems such as diffserv or QoS are distributed by nature and for them to work you need to have global coherence - while each device may be slightly different or use a slightly different style it should be pointing in the correct direction. . Well constrained programming environment in devices for configurable behavior. . Be able to change state of running activities or processes. . Minimize number distinct OS versions: either fix or report. Not every box runs the same set of features, and there is version skew/quality skew/feature skew based on device. One can't really have only one version, even in things like routers. One may have reasons for running different versions, such as some features working better in one version or other. The script may need to take notice of these differences. You may also want to run an older version due to internal reasons so script may need to down rev new entities. Scripts should be able to notice the mismatch and report it somewhere - possibly causing a down load itself or possibly leaving that for some other code or a human. . Find and repair misfits. . Be able to drop all traffic of a given nature (say Microsoft Workgroup) on interfaces facing the internet. . Apply "standard" route filtering at all "appropriate" places (possibly trap on exceptions, rather than filter them). . Set VPN information based on a user "login". . Create "access ports" with just public internet access (no intranet). . Change connectivity of a port or resource for a time based on payment, and be able to cancel such connectivity either at end of time period or end of usage ("I'm done, now"). Suppose you were in a hotel and have ethernet access fee based. You may want to restrict access to the site where you pay the fee. You want to provision a particular to be available until noon the next day. You can have a cancel availability. One needs to configure to the mission, and then abstract to SNMP operations. . Hiding complexity. . Abstract access to type-specific and complex instance information. . Specify roles to the system how to react over time to configuration or state changes -- decompose the configuration. A warning about the diffserv arena: There is seldom a crossing between "user wants service level" and "service level x means this and that". . Disabled a BGP operation over a scheduled period. . Enable coherence of configuration across devices. They cannot be consistent, but must be coherent. . Use subnet as the parameter, for both values and conditions. May be several approaches. No one objected that anything was out of scope. We need to encourage people to add more. This list is not ordered in any order or priority. Nor is the list a working list for this working group. [break] Topic 2: Schedule and Time. Presentation by Thippanna Hongal (hongal@yagosys.com) The slide presentation touched on several topics, such as RFC2445 (Internet Calendaring and Scheduling Core Object Specification), local time objects and explicit dates. Several possible methods for dealing with time issues (accessor functions, duration, predefined scalar variables, explicit start and end date, and using RFC2591 (schedule MIB) with duration extensions) were discussed. The slides are available. The presentation was well received, with the following comments made: . One needs to have a software flipflop. If something is not done, then do it (so that you have idempotency). . This can be made a little richer by adding semantics to the accessor functions so that duration is automatically handled. . Change the single letter to H for Thursday, or use digits for days. (the example in question used MTWTF). . The accessor function needs to be richer to allow for some sort of between operation (between 9 and 5 rather than a trigger happening at 9 and 5). . When using the schedule MIB, you would need to create a MIB entry that would point back to the entry that would be started. Actually you would need two entries in the schedule MIB one for starting (setting the admin status to enable) and one for stopping (setting the admin status to disable). May be able to add an augments clause to the schedule MIB to pack the information into one entry. . One needs to make sure that the forward and backward pointers stay in sync. To do this, there should be a one-to-one pairing. Have two schedule entries pointing to one ifAdminStatus would be difficult to maintain. . If we use the schedule MIB, we need to bear in mind that it has up to one minute latency after one presses the go button. . One could group things into a policy filter result. You could make it so that the expressions are evaluated synchronously based on a max latency timer. You can make it so that when the result column is retrieved it causes an evaluation. . One would like a policy that says if an action follows in a certain time frame, page someone, otherwise turn on a blue light in the machine room. . If you have both a trigger column and a pointer to time stuff, things will still work if a schedule tool on a network management station or elsewhere can set the object on a system without a concept of time. The general idea is that you have a trigger button that when twiddled causes an edge-like action. You also have a time base set of arguments that cause it to happen based on time, and you have a coupling that allows the time based stuff to diddle the trigger. (synchronous and asynchronous). Another way to do that would be to have that trigger something in the event MIB from DISMAN to do the discrimination. In summary, we are talking about augmenting the schedule MIB so that we have the start and stop times rather than having multiple entries. This is a proposed change. [lunch break] Topic 3: Report of the Accessor Function Design Team. . Functions are designed in groups . All functions of a group must be implemented to have the group advertised. . We are silent about the point that you may implement less than the whole group and not advertise the group. i.e., we do not prohibit partial implementation but we do explicitly prohibit advertising a partial implementation. . Groups are exposed via MIB objects in the capabilities table, except the mandatory core group, which is explicitly implicit (which may need exposure in the capabilities table anyway, for versioning). . Access functions are always defined in information modules . Groups are identified by Object ID . Accessor functions are identified by name and are not exposed individually . vendors are allowed at define their own groups in their own name spaces . We have an accessor function capMatch(group) . We do not support a functionExists(accessor function) . Versioning is done at the group, not the accessor level (capabilities subtype) . We may have more issues with versioning. Following the presentation, there was a discussion about naming, name spaces, and versioning, summarized below. . Libraries (groups) should be backwards compatible (can only add functions, cannot remove functions). The "you cannot change count or type of arguments to a function" rule was mentioned. . Names are assumed to be unique within the standards name-space; names within a vendor name space should have a prefix attached based on some sort of vendor-specific information (enterprise number-type information) and the vendor will be responsible for ensuring the uniqueness of the function names. The prepending cannot be done via dots, as this has a meaning within C-like languages, which is a constraint we have due to our restriction to extant languages. . Function groups can be identified by OID and invoked by name. . The semantics of capMatch should be such that capMatch(1.0) means that 1.0 functions are available, and capMatch(2.0) means that 1.0 and 2.0 functions are available. However, since the name space and signature of the functions are unique, it can be argued that you don't need versioning. . We have to make sure standard groups never standardize two groups with the same name, and across two standard groups don't have two identical names. [End of design team report and hash] Topic 4: Diffserv Policy MIB Report, by David Partain. First thing we discovered is that there was some logic that was not exactly right in the -02 draft. In discussion with Joel Halpern, just like in the diffserv MIB, we want to build up a linked list of elements that are acted on. To know where the linked list ends, we have to do a linked list traversal. To fix this, we put in an "associative index". So diffservPolicy #1 means the whole list of things. We added a linked list of all of the lists. How to you instantiate this stuff? Joel H came up with a start table where you provide the instance information that is needed (ifIndex, direction) for tat policy and tell it which policy to start. We added a table indexed by (ifIndex, direction). You push a button (set an integer index to, say, 3), and this instantiates a policy. In the diffserv working group, Joel suggested the same things, as a result of which change were made to their MIB. This way we no longer to take each revision of their draft and clean it up. Whether or not Joel and others can push this through the diffserv working group is an open question. Harrie found a couple of things that were bugs. As a part of this, we realized that if the instance and policy information go into a separate table in the diffserv MIB, then it is likely that the diffserv policy MIB may no longer be needed. This provides an interesting lesson on how to model this stuff template-wise. We now understand diffserv a lot better. Jon Saperia raised several points: . Have you written this up? We should have a policy section in the BCP document. . Also, could you tell the working group if we are omitting this MIB. . This working group has been asked by the IPSEC group for some help in writing up the MIB and etc to config IPSEC. Brief Presentation on instance/object fanout, by Jeff Case. Jeff put up a drawing showing various ways of traveling the MIBs to get to instance information. There were three basic routes: 1 NMS -> diffserv MIB 2 NMS -> Policy MIB -> diffserv MIB 3 NMS -> Policy MIB -> QOS Policy MIB -> diffserv MIB The Policy MIB gives you fanout on the number of instances. The QoS MIB gives you fanout on the number of objects. Going through both, you get m*n fanout. Two points of interest: . the first fanout (Policy MIB) is more interesting as you may get a much larger fanout (for example 1000s to several). . if the accessor functions are allowed to go off board (to another managed element) then some of the policy instrumentation can be located elsewhere. All of our work so far has assumed that QoS, Policy MIB and diffserv MIB are all on the same managed system. If our accessor functions can do a snmp get, then Policy MIB or QoS MIB can be colocated at the agent or the manager or a mid-level manager. Topic 5: Policy Override Discussion, led by Steve Waldbusser. Steve Waldbusser: In the general area of policy conflicts. I am uncomfortable with the term "conflicts" It implies things that happen behind our backs. When policies have relationships, sometimes the policy writer wants to specify enough information to have the agent know what to do when two or more policies might apply. You might have related sets of policies that need arbitration: if capMatch(802) configure 802 if capMatch(diffServ) configure DiffServ You may not want both happening at the same time if there is a conflict. Some approaches one might use are: . Pick one set based on capabilities or other state . Use defined configuration for non-matching elements . Use a default configuration You also need to have a defined state when a policy goes out of effect (rather than leave policy in limbo). You have completely different policies different domains, goals, and human authors, yet they diddle the same object. Which one wins? Everything falls into one of these two groups: . Related sets of policies that need arbitration . Unrelated sets of policies We might use two objects to arbitrate related policies . pmPolicyGroup . pmPolicyGroupPriority and one object to a arbitrate instance conflict . pmPolicyConflictPriority Walter Weiss had two issues with this approach: . If we have two alternatives, which one do I select . If we have two alternatives, which do I do first Jeff Case broke it down into the following cases: . Policy 1 modifies object/instance A, policy 2 modifies object/instance B no problem. . Policy 1 modifies object/instance a and b, policy 2 modifies a and b, and there is a perfect overlap. You only do the one with highest precedence. . Policy 1 modifies object/instance a and b, policy 2 modifies a and b, and you want a way to say "by the way, I want you to do both a and b or neither a nor b. You needs groups for this case. Joel Halpern disagreed with this approach, as the policy is an atomic thing. You cannot do half a policy. Two approaches to this were discussed. One might use two policies with difference precedences, or you might use a group in a logical switch statement. Joel Halpern liked the logical composition, as using precedence is more likely to lead to programmer error. He went on to say that there is no good way to catch overlapping policies, they'll just have to diagnose it on the box. We need to say we thought about it. He thinks a precedence value is about as good as we can get. There may be a corollary in the execution environment, if we have several sets from a policy action, you need to check the precedence to make sure the sets are ordered correctly. Jon Saperia made that point that policies that simultaneously control various MIB objects are difficult to implement. You put two things in a group because their actions could conflict. If these two things match on the same instance then the box burns up. The observation was made that you cannot make sure that policy writers do groups correctly. From policy group, it is important that you be able to detect all potential policy conflicts. The problem is when you are not coordinating your policy writers. Walter Weiss: Do we have the scripts or policies invoke other scripts or policies? It seems to me that for many of the conflict issues this may be the ideal level of sophistication. We are playing games on criteria. More often than not, what is more important on circumstances rather than conflict. Joel Halpern: In most cases, policy conflicts are caused by underspecified conditions. "It can't happen! Well, unfortunately it did." It is messy when unrelated sets of policies conflict. The discussion over the next few minutes focused in policy interactions and the need for human supervision to deal with interaction problems. Concerns were expressed about how to handle a partial policy implementation due to partial failures and whether or not we should be able to do policy unwinding (like SNMP sets are handled now). The problem of having initial configuration policies, subsequent incremental policies, and interaction resolution between the two was mentioned. The point that there are cases where we don't want the agent to choose randomly was made. A policy set of actions can be done starting at the beginning and end at the end. This is unlike how we do PDU processing. A more SNMP-set-like set of operations (must all succeed or they fail) will not work, as most policies aren't going to work on a larger machine (since some sets will most always fail). We are going to have to live with this. Sometimes we want a partial policy execution to succeed, sometimes we want it to fail (roll back). For example, we may have a policy that says provide power to the oxygen generator if possible. The other is "when on emergency generator shut down as much as you can". I don't think that since we cannot shut down the oxygen generator we can't shut down any outlets. I believe you will have times that say "do as much as you can", and sometimes you say "do all or none". You want to have both kinds of semantics expressible. We have a mechanism for doing both but we don't understand the computational complexity yet. When you want partial results, put them in separate groups, otherwise put them in same group. You could have an accessor function that says "do all or none", or separated into separate unrelated actions. Meeting wrapup. How do do people feel about having the interim at the end of the IETF? Great to minimize travel, but we are toastier than toast. We made a great deal of progress between last interim and this interim. Proposed dates for next interim Oct 12/13 and Oct 19/20. Knoxville has been generally agreed up as the location. We'll take the dates issue to the list. The Policy MIB document has a lot of stuff that has been effected. The policy module is probably go to a tiny set of objects. Harrie says he wants to wait to see what diffserv is going to do. DIffserv is probably going to decide in the next two weeks. We've made some changes that require that we change the BCP document. My goal is to republish before the end of September. Thanks to SNMP Research and Ericsson for sponsoring this interim meeting. --- Administrivia Since there are no blue sheets for an interim meeting, an attendance list must be submitted. Many thanks to Shawn Routhier, both for his excellent notes, and for the attendance list. Attendance list for meeting David Partain David.Partain@ericsson.com Steve Moulton moulton@snmp.com Jon Saperia saperia@jdscons.com Matt White mwhite@torrentnet.com Harrie Hazewinkel harrie@covalent.net Walter Weiss wweiss@ellacoy.com Thippanna Hongal hongal@riverstonenet.com David T. Perkins dperkins@dsperkins.com Omar Cherkaoui cherkaoui.omar@ugam.ca Kwok Ho Chan khchan@nortelnetworks.com Zhifeng Xiao zhifeng@cs.mcgill.ca Joel Halpern joel@longsys.com Rob Frye rfrye@longsys.com Mike MacFaden mrm@riverstonenet.com Bert Wijnen bwijnene@lucent.com Shawn A. Routhier sar@epilogue.com Andy Bierman abierman@cisco.com Chris Elliott chelliot@cisco.com Dan Romascanu dromasca@avaya.com Dale Francisco dfrancis@cisco.com Barr Hibbs rbhibbs@ultradns.com Jeff Case case@snmp.com Assaf Zeira assafz@p-cube.com Steve Waldbusser waldbusser@nextbeacon.com David Harrington dbh@enterasys.com From owner-snmpconf@seymour39.SNMP.COM Thu Sep 7 22:10:15 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02339 for ; Thu, 7 Sep 2000 22:10:15 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id VAA01221 for snmpconf-outgoing; Thu, 7 Sep 2000 21:55:40 -0400 (EDT) Message-Id: <4.3.1.20000908015542.00b89db0@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 08 Sep 2000 01:56:50 -0700 To: snmpconf@snmp.com From: Mike MacFaden Subject: Re: snmpconf Interim Meeting Dates 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 At 05:06 AM 9/7/00 -0400, Jon Saperia wrote: > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) >Please express your preferences if you plan on attending so that we can let >the ADs know and work on the logistics. Either dates work for me. Mike MacFaden www.riverstonenet.com From owner-snmpconf@seymour39.SNMP.COM Fri Sep 8 09:04:42 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21836 for ; Fri, 8 Sep 2000 09:04:42 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA23272 for snmpconf-outgoing; Fri, 8 Sep 2000 08:45:50 -0400 (EDT) Message-Id: <200009081245.OAA15615@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Introduction and a request 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: <24163.968417410.1@y5m638.lmera.ericsson.se> Date: Fri, 08 Sep 2000 14:50:10 +0200 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id IAA23266 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id IAA23272 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA21836 Greetings, Since I'm sure that there are a fair number of people on this mailing list who don't know me, I wanted to briefly introduce myself as the new co-chair. As you can see from my signature, I work for Ericsson and specifically in the area of policy-based management. I previously worked for SNMP Research for a number of years, so I suppose I might be considered an "old SNMP dog". I enter into this with some fear and trepidation, given that this is my first task of this sort within the IETF, but I'm sure you'll all be kind and gentle in making sure I do things correctly :-). I look forward to working with the group to push this work forward. My thanks to David Harrington for doing the job thus far and for helping to get us a good way down the path. I hope I can follow his good precedent. My initial task is to try to synthesize the issues that have been/are on the table and are either resolved or remain to be resolved. My model will be something along the lines of what's been done in DISMAN and SNMPv3 in collecting and discussing issues, since I believe that has been organizationally effective. This needs to happen quickly, but I don't have a good feel for how fast this will go yet. Finally, we as a group need to reach a decision about the dates for the interim meeting very quickly. As such, it's important that, if you have a preference and have not voiced your opinion (privately to Jon or me or publicly to the list), please do so by the end of business on Monday. Again, the two possible dates are: Monday and Tuesday, October 16 and 17 Thursday and Friday, October 26 and 27 In either case, it will be in Knoxville, Tennessee. 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 Sat Sep 9 17:33:11 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23308 for ; Sat, 9 Sep 2000 17:33:11 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA08514 for snmpconf-outgoing; Sat, 9 Sep 2000 17:15:11 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB09166AA9@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf Interim Meeting Dates Date: Sat, 9 Sep 2000 23:14:30 +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 October 26/27 will not work for me. Other october dates are fine. Don't let my availability be too much of an issue. It is more important that the real workers can be there. Bert > ---------- > From: Jon Saperia[SMTP:saperia@mediaone.net] > Reply To: snmpconf@snmp.com > Sent: Thursday, September 07, 2000 11:06 AM > To: snmpconf > Subject: snmpconf Interim Meeting Dates > > As those of you who were at the IETF or have read the minutes know, we > discussed having an interim meeting in October. A number of dates were > discussed at the interim in Pittsburgh including October 12 - 13 and > October > 19 - 20. For a number of reasons some of those dates are problematic. > > SNMP Research has generously offered to host the next interim in > Knoxville, > TN. I would like to propose one of two alternative dates: > > October 16 and 17 (A Monday and Tuesday) > October 26 and 27 (A Thursday and Friday) > > Please express your preferences if you plan on attending so that we can > let > the ADs know and work on the logistics. > > Thanks very much. > > /jon > > From owner-snmpconf@seymour39.SNMP.COM Mon Sep 11 12:57:24 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06409 for ; Mon, 11 Sep 2000 12:57:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA17392 for snmpconf-outgoing; Mon, 11 Sep 2000 12:36:31 -0400 (EDT) Date: Mon, 11 Sep 2000 18:35:55 +0200 Message-Id: <200009111635.SAA29855@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <39B55D08.20FD256A@nextbeacon.com> (message from Steve Waldbusser on Tue, 05 Sep 2000 13:52:24 -0700) Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: Steve> I've been collecting and writing examples and haven't yet come Steve> up with any impracticalities, much less a class of policy Steve> scenarios that aren't handled by this architecture. Steve> The split between filter (aka condition) and action follows Steve> existing practice in other policy work (e.g. the policy WG). I am not arguing against the conceptual distinction between a policy condition (or policy filter) and a policy action. This is fine as long as we all believe in the rule-based approach, which I take as a given at this point in time. [One can question the rule based approach itself, but this really falls out of the scope I think. ;-] I am questioning whether it is useful to represent this distinction in the MIB. This WG is using a lanuage based approach to describe policy filters and policy actions. It is possible to (a) represent each atomic statement of this language as single MIB objects (b) represent filters (conditions) and actions as single MIB objects (c) represent a rule (composed of a filter and actions) as single MIB objects (d) represent sets of rules (a policy group) as single MIB objects I believe that sets of related policy rules (a policy group) form a high-level control construct and that it is useful to transfer and invoke them as single logical entities. In this model, the execution environment is required to take such a high-level control construct and to transform it into an internal representation that can be executed effectively. I also believe that policy rule changes do not happen in real-time. So any attempts to introduce a "peek and poke" capability to modify policy rule sets on the fly seem wasted to me. Steve> Some of the benefits of splitting them include: Steve> - Because all filter information is separate, the manager can Steve> inspect the filter and understand whether to download the Steve> policy to an agent (i.e. "this policy will never execute on Steve> this system so I don't need to download it") But the same thing can be done by letting the manager generate a policy rule script which is specific to the capabilities of the agent. I don't think there is any significant advantage here for this optimization from the granularity of the MIB objects. Steve> - Because filter information is separate, the agent can Steve> schedule filter evaluation separately from action evaluation. Steve> If I have 50,000 circuits, I might not want to evaluate the Steve> filter as often as I want to assert the action. Conversely, if Steve> the action is more costly than the filter, I might want the Steve> filter evaluated more frequently (to more quickly discover new Steve> elements to which to policy should apply) An execution environment can easily extract the filters from a policy script and do what you describe above. The agent has to do some parsing anyway and being capable to extract filters won't add much overhead. In fact, since the agent does not forced to export the internal representation as (writable) MIB objects, you will actually be able to reduce significantly the complexity of the agent. Steve> - The filter expression is known to be idempotent, information Steve> that both manager and agent can use for optimization. I don't think this has any implications on the granularity with which you communicate policy rules between the policy manager and an agent. Steve> - It is easier to re-use filter and action expressions when Steve> they are separate. Imagine a policy authoring environment that Steve> lets you drag an icon representing "all ethernet access ports" Steve> and associate it with an icon representing "mark voice with CP Steve> 35". I do not see why this is so much simpler. In the current approach, the manager needs to search for a suitable filter. If it finds one, you add another action to it. If there is no suitable filter, you create one and add a action to it. The same will happen if your policy script language combines filters and actions. The difference is only that the current approach may do the addition by editing the MIB in place while the proposed approach will push a new policy group to the agent. I believe that this is actually a plus since I do not believe that a decent policy tool will modify any systems while a human edits policy rules. In fact, I believe that all the drag & drop policy editing is finished before you hit the install button in your policy tool (at which point in time the policy tool does some conflict detection and optimization and pushes the policies into the devices, potentially adapted to the device capabilities). Steve> The split is a fundamental part of the architecture so I expect Steve> we can keep coming up with other existing benefits to add to Steve> the list. As I said before, I do not argue against the policy filter / policy action concept here. (BTW, what precisely is the difference between a policy filter and a policy condition? Why does this WG not use the commonly used term policy condition?) I am arguing that the choosen granularity with which you communicate policy rules between a policy manager and a policy-aware agent is wrong. >> I also expect that network operators will prefer to write and >> handle sets of logically related policy rules in a single language >> and to store them in a single file which they push to the managed >> devices. Steve> This is true only if they were trying to build policy by hand Steve> on top of a scripting system. We are building them an Steve> infrastructure (our standard plus the applications that will Steve> stem from it) that will make it more convenient than doing it Steve> by hand. You may have a nice GUI policy tool. But even then, having this tool generate a nice readable format in a human readable policy scripting language will be valuable - and if it is for debugging purposes only. Steve> Our execution environment is much different than that for the Steve> Script MIB. While the script MIB is for generic scripted Steve> applications, the PM MIB execution environment is purpose-built Steve> for processing policy expressions. We require facilities that Steve> aren't in the script mib such as: Steve> - Our filter expressions are called once for each element. - Steve> Our action expressions are called once for each element that Steve> passed the filter. - Our expressions expect to be passed the Steve> identity of the "current element" as a parameter. - Our Steve> environment periodically re-runs expressions The script MIB does (on purpose) not define any particular execution environment. This WG can of course define a policy scripting language execution environment which takes a policy script and executes it with all the features you have listed above. The fact that the script MIB is generic makes it applicable to this (and other) problem domain. Steve> The script MIB also allows things we need to disallow - Ad-hoc Steve> invocation of expressions - multiple languages - download of Steve> script by http - Trap sent on every error - ... (would require Steve> thorough analysis to complete this list) Ad-hoc invocation of policy groups does not seem like a bad thing to me. Multiple languages is no issue since this WG can standardize a policy scripting language for interoperability. Download from URLs (not only HTTP) will be very convenient, especially when policies become larger. Getting notifications on errors is useful. And you can turn them off by some standard SNMPv3 configuration if you really do not care if your policy system goes crazy. Steve> The Script MIB is a great generic scripting mechanism but it Steve> would be very awkward to use for our application because the Steve> differences are greater than the similarities. Which I do not believe. Once again, the key difference is at which granularity you communicate policy rules between the policy management tool and the policy execution environment. I have listed four alternatives at the beginning of this email. I believe that only (d) makes sense for any system of serious size and complexity. (c) may still work for networks which only require a few policy rules - that is basically new networks that still have a consistent design. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Mon Sep 11 17:32:08 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09264 for ; Mon, 11 Sep 2000 17:32:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA22397 for snmpconf-outgoing; Mon, 11 Sep 2000 17:11:51 -0400 (EDT) Message-ID: <10C8636AE359D4119118009027AE99873A390B@FMSMSX34> From: "Durham, David" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf well, back to work Date: Mon, 11 Sep 2000 14:10: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 also agree with Juergen that the MIB-level distinction between conditions and actions is wrong. If the language comprises the syntax, than there should be no distinction at all within the MIB itself. I have stated before that representation of the rule as the atomic level of access is most logical. I also agree that the scripting MIB can and should be leveraged for this work. No sense in reinventing its useful concepts again. Once the language concept was introduced for SNMPCONF, it follows that the generality of the language syntax becomes a feature. What you consider an atomic action today may very well become itself a conditional action sequence tomorrow. So it is better to look at actions as independent procedures/operations, procedure invocation being determined from a set of one or more if-then statements. So as a flow: StartProcedure{ConditionStatements->ConditionalProcedures} ConditionalProcedures{ConditionStatements->ConditionalProcedures} To me, an action is simply an independent (shared) procedure call that may then have a scripted set of conditions/procedure calls as well as MIB variable manipulations. All that is left is determining where to start, and here a MIB definition would be valuable. A MIB can define the start procedure, timed/periodic procedures, and asynchronous event-triggered procedures... Concepts that have real semantic value. Cheers, -Dave > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > > >>>>> Steve Waldbusser writes: > > Steve> I've been collecting and writing examples and haven't yet come > Steve> up with any impracticalities, much less a class of policy > Steve> scenarios that aren't handled by this architecture. > > Steve> The split between filter (aka condition) and action follows > Steve> existing practice in other policy work (e.g. the policy WG). > > I am not arguing against the conceptual distinction between a policy > condition (or policy filter) and a policy action. This is fine as long > as we all believe in the rule-based approach, which I take as a given > at this point in time. > > [One can question the rule based approach itself, but this really > falls out of the scope I think. ;-] > > I am questioning whether it is useful to represent this distinction in > the MIB. This WG is using a lanuage based approach to describe policy > filters and policy actions. It is possible to > > (a) represent each atomic statement of this language as single MIB > objects > > (b) represent filters (conditions) and actions as single MIB objects > > (c) represent a rule (composed of a filter and actions) as single > MIB objects > > (d) represent sets of rules (a policy group) as single MIB objects > > I believe that sets of related policy rules (a policy group) form a > high-level control construct and that it is useful to transfer and > invoke them as single logical entities. In this model, the execution > environment is required to take such a high-level control construct > and to transform it into an internal representation that can be > executed effectively. I also believe that policy rule changes do not > happen in real-time. So any attempts to introduce a "peek and poke" > capability to modify policy rule sets on the fly seem wasted to me. > > Steve> Some of the benefits of splitting them include: > > Steve> - Because all filter information is separate, the manager can > Steve> inspect the filter and understand whether to download the > Steve> policy to an agent (i.e. "this policy will never execute on > Steve> this system so I don't need to download it") > > But the same thing can be done by letting the manager generate a > policy rule script which is specific to the capabilities of the > agent. I don't think there is any significant advantage here for this > optimization from the granularity of the MIB objects. > > Steve> - Because filter information is separate, the agent can > Steve> schedule filter evaluation separately from action evaluation. > Steve> If I have 50,000 circuits, I might not want to evaluate the > Steve> filter as often as I want to assert the action. Conversely, if > Steve> the action is more costly than the filter, I might want the > Steve> filter evaluated more frequently (to more quickly discover new > Steve> elements to which to policy should apply) > > An execution environment can easily extract the filters from a policy > script and do what you describe above. The agent has to do some > parsing anyway and being capable to extract filters won't add much > overhead. In fact, since the agent does not forced to export the > internal representation as (writable) MIB objects, you will actually > be able to reduce significantly the complexity of the agent. > > Steve> - The filter expression is known to be idempotent, information > Steve> that both manager and agent can use for optimization. > > I don't think this has any implications on the granularity with which > you communicate policy rules between the policy manager and an agent. > > Steve> - It is easier to re-use filter and action expressions when > Steve> they are separate. Imagine a policy authoring environment that > Steve> lets you drag an icon representing "all ethernet access ports" > Steve> and associate it with an icon representing "mark voice with CP > Steve> 35". > > I do not see why this is so much simpler. In the current approach, the > manager needs to search for a suitable filter. If it finds one, you > add another action to it. If there is no suitable filter, you create > one and add a action to it. The same will happen if your policy script > language combines filters and actions. The difference is only that the > current approach may do the addition by editing the MIB in place while > the proposed approach will push a new policy group to the agent. > > I believe that this is actually a plus since I do not believe that a > decent policy tool will modify any systems while a human edits policy > rules. In fact, I believe that all the drag & drop policy editing is > finished before you hit the install button in your policy tool (at > which point in time the policy tool does some conflict detection and > optimization and pushes the policies into the devices, potentially > adapted to the device capabilities). > > Steve> The split is a fundamental part of the architecture so I expect > Steve> we can keep coming up with other existing benefits to add to > Steve> the list. > > As I said before, I do not argue against the policy filter / policy > action concept here. (BTW, what precisely is the difference between a > policy filter and a policy condition? Why does this WG not use the > commonly used term policy condition?) I am arguing that the choosen > granularity with which you communicate policy rules between a policy > manager and a policy-aware agent is wrong. > > >> I also expect that network operators will prefer to write and > >> handle sets of logically related policy rules in a single language > >> and to store them in a single file which they push to the managed > >> devices. > > Steve> This is true only if they were trying to build policy by hand > Steve> on top of a scripting system. We are building them an > Steve> infrastructure (our standard plus the applications that will > Steve> stem from it) that will make it more convenient than doing it > Steve> by hand. > > You may have a nice GUI policy tool. But even then, having this tool > generate a nice readable format in a human readable policy scripting > language will be valuable - and if it is for debugging purposes only. > > Steve> Our execution environment is much different than that for the > Steve> Script MIB. While the script MIB is for generic scripted > Steve> applications, the PM MIB execution environment is purpose-built > Steve> for processing policy expressions. We require facilities that > Steve> aren't in the script mib such as: > > Steve> - Our filter expressions are called once for each element. - > Steve> Our action expressions are called once for each element that > Steve> passed the filter. - Our expressions expect to be passed the > Steve> identity of the "current element" as a parameter. - Our > Steve> environment periodically re-runs expressions > > The script MIB does (on purpose) not define any particular execution > environment. This WG can of course define a policy scripting language > execution environment which takes a policy script and executes it with > all the features you have listed above. The fact that the script MIB > is generic makes it applicable to this (and other) problem domain. > > Steve> The script MIB also allows things we need to disallow - Ad-hoc > Steve> invocation of expressions - multiple languages - download of > Steve> script by http - Trap sent on every error - ... (would require > Steve> thorough analysis to complete this list) > > Ad-hoc invocation of policy groups does not seem like a bad thing to > me. Multiple languages is no issue since this WG can standardize a > policy scripting language for interoperability. Download from URLs > (not only HTTP) will be very convenient, especially when policies > become larger. Getting notifications on errors is useful. And you can > turn them off by some standard SNMPv3 configuration if you really do > not care if your policy system goes crazy. > > Steve> The Script MIB is a great generic scripting mechanism but it > Steve> would be very awkward to use for our application because the > Steve> differences are greater than the similarities. > > Which I do not believe. > > Once again, the key difference is at which granularity you communicate > policy rules between the policy management tool and the policy > execution environment. I have listed four alternatives at the > beginning of this email. I believe that only (d) makes sense for any > system of serious size and complexity. (c) may still work for networks > which only require a few policy rules - that is basically new networks > that still have a consistent design. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > Braunschweig, Germany > Fax: +49 531 391 5936 > > > From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 08:13:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01199 for ; Tue, 12 Sep 2000 08:13:33 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA09541 for snmpconf-outgoing; Tue, 12 Sep 2000 07:56:29 -0400 (EDT) Message-ID: <39BE096C.937EF68B@nextbeacon.com> Date: Tue, 12 Sep 2000 03:46:04 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.com> <200009111635.SAA29855@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > > I am not arguing against the conceptual distinction between a policy > condition (or policy filter) and a policy action. > I am questioning whether it is useful to represent this distinction in > the MIB. This WG is using a lanuage based approach to describe policy > filters and policy actions. It is possible to > > (a) represent each atomic statement of this language as single MIB > objects > > (b) represent filters (conditions) and actions as single MIB objects > > (c) represent a rule (composed of a filter and actions) as single > MIB objects > > (d) represent sets of rules (a policy group) as single MIB objects We agree that policy filters and actions are conceptually different. Further, I have noted that filters have different syntax and semantics than actions (e.g. filter syntax does not include SET operators but action syntax does; filter code is executed on all elements while action code is executed on matching elements; filter execution frequency is controlled by filterMaxLatency, while action execution frequency is controlled by actionMaxLatency; etc.). The rest is simply Modeling 101: We define different concepts as different objects. Then we structure them to show the appropriate relationships between the concepts/objects. We shouldn't encode filter and action into the same object for the same reason that we shouldn't encode policyStatus as a decimal number at the end of the policyAction string. We outlawed OPAQUE syntax years ago because of similar bad modeling practices it was abused for. To reiterate, the first step in Modeling 101 is to identify the component objects. The second is to model the relationships between them. One relationship we've had concensus on (here and in other groups) is the association of a filter and an action which we accomplish by having them as columns in the same table. You raise another potential relationship: multiple policies being associated together into a policy group. What is the best way to represent such a relationship? It depends on the nature of the association and the type of "service" that you want to offer by the association. Unfortunately, the nature of policy groups is not completely understood today so it is hard to tell today what the best model will be, but I hardly believe that simply stuffing them all together is sufficient. We've already been discussing a counter example: Imagine two policies: 1. if (diffServCapable) then (configureDiffServ) 2. if (802Capable) then (configure802) One service that has been suggested for policy groups is to express that policy 1 and policy 2 are related such that at most one of them will execute. In other words, we need to arbitrate what will happen when diffServ and 802 are both present (only 1 should be configured). In order to fully model this relationship, you need to specify which one wins in case of a tie (e.g. priority/precedence). Simply putting them in the same object doesn't express priority. This is best modeled by a priority value attached to each policy. In other words we would need: policyFilter policyAction policyGroup policyPrecedence (priority within group) The point is that stuffing them into one MIB object doesn't meet the requirements (it doesn't encode priority) and was bad modelling practice because it didn't anticipate the full requirements for policy groups. > Steve> - Because filter information is separate, the agent can > Steve> schedule filter evaluation separately from action evaluation. > Steve> If I have 50,000 circuits, I might not want to evaluate the > Steve> filter as often as I want to assert the action. Conversely, if > Steve> the action is more costly than the filter, I might want the > Steve> filter evaluated more frequently (to more quickly discover new > Steve> elements to which to policy should apply) > > An execution environment can easily extract the filters from a policy > script and do what you describe above. The agent has to do some > parsing anyway and being capable to extract filters won't add much > overhead. In fact, since the agent does not forced to export the > internal representation as (writable) MIB objects, you will actually > be able to reduce significantly the complexity of the agent. We agree that filters and actions are separate. We're simply debating what's the best delimiter between filter and action. I'd rather use the existing facilities of the SNMP protocol engine to delimit objects instead of writing code that parses an octet string looking for internal delimiters. Using existing facilities results in 2 MIB objects rather than 1, but results in less code overall because each MIB object is simpler. > I do not see why this is so much simpler. In the current approach, the > manager needs to search for a suitable filter. If it finds one, you > add another action to it. If there is no suitable filter, you create > one and add a action to it. The same will happen if your policy script > language combines filters and actions. The difference is only that the > current approach may do the addition by editing the MIB in place while > the proposed approach will push a new policy group to the agent. > > I believe that this is actually a plus since I do not believe that a > decent policy tool will modify any systems while a human edits policy > rules. In fact, I believe that all the drag & drop policy editing is > finished before you hit the install button in your policy tool (at > which point in time the policy tool does some conflict detection and > optimization and pushes the policies into the devices, potentially > adapted to the device capabilities). Filters and actions are separate for modeling reasons, the separation was not added to allow interactive editing. Personally, I don't know if changing a running policy is a good idea. > >> I also expect that network operators will prefer to write and > >> handle sets of logically related policy rules in a single language > >> and to store them in a single file which they push to the managed > >> devices. > > Steve> This is true only if they were trying to build policy by hand > Steve> on top of a scripting system. We are building them an > Steve> infrastructure (our standard plus the applications that will > Steve> stem from it) that will make it more convenient than doing it > Steve> by hand. > > You may have a nice GUI policy tool. But even then, having this tool > generate a nice readable format in a human readable policy scripting > language will be valuable - and if it is for debugging purposes only. I agree completely - that's why I've been a promoter of the language-based approach. Network operators use scripting (e.g. Perl) as a tool of choice in managing their network. > Steve> Our execution environment is much different than that for the > Steve> Script MIB. While the script MIB is for generic scripted > Steve> applications, the PM MIB execution environment is purpose-built > Steve> for processing policy expressions. We require facilities that > Steve> aren't in the script mib such as: > > Steve> - Our filter expressions are called once for each element. - > Steve> Our action expressions are called once for each element that > Steve> passed the filter. - Our expressions expect to be passed the > Steve> identity of the "current element" as a parameter. - Our > Steve> environment periodically re-runs expressions > > The script MIB does (on purpose) not define any particular execution > environment. This WG can of course define a policy scripting language > execution environment which takes a policy script and executes it with > all the features you have listed above. The fact that the script MIB > is generic makes it applicable to this (and other) problem domain. Maybe the script MIB isn't as generic as I maintained. In the script MIB, scripts are started (only) by writing a value to smLaunchStart. In the policy management MIB we need scripts to re-execute automatically based on timer events. Further, the Script MIB dictates that scripts are passed the contents of the smLaunchArgument object. In the PM MIB, we need scripts to be passed the index of "this element". I can't imagine a reading of the script MIB that would allow such a change of semantics. I also can't imagine that such a position would be healthy to the future of the script MIB. You say that the script MIB doesn't define an execution environment - that may be true for language and libraries, but it definitely not true for scheduling and parameter passing and other areas where it is very explicit and DIFFERENT than the Policy Management MIB requirements. Meta issue: In order to make this work we would have to say that the semantics of a registered MIB object are not forever defined by the description clause, but can change in unanticipated ways based on what other MIB object is "pointing" to them. This seems to shake the foundation of our SMI framework. > Steve> The Script MIB is a great generic scripting mechanism but it > Steve> would be very awkward to use for our application because the > Steve> differences are greater than the similarities. > > Which I do not believe. > > Once again, the key difference is at which granularity you communicate > policy rules between the policy management tool and the policy > execution environment. I have listed four alternatives at the > beginning of this email. I believe that only (d) makes sense for any > system of serious size and complexity. (c) may still work for networks > which only require a few policy rules - that is basically new networks > that still have a consistent design. We agree that policy groups will be required for complex policies on complex networks. However, you're confusing the encoding of policies with the modeling of policy relationships. Encoding two things into one object has never been the desirable way of modeling a relationship between them. Steve From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 11:35:26 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06853 for ; Tue, 12 Sep 2000 11:35:24 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA14328 for snmpconf-outgoing; Tue, 12 Sep 2000 11:21:10 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 12 Sep 2000 11:23:57 -0400 Subject: snmpconf Date for Interim Meeting From: Jon Saperia To: snmpconf , Bert Wijnen , Randy Bush 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 David Partain and I would like to thank all those who expressed preferences for the different proposed Interim meeting dates. Based on those preferences and hotel/meeting site availability the final dates have been set for October 26 and 27 (a Thursday and Friday). The good news is this gives us more time to prepare. The bad news is that this leaves little time before the ID cut off date in preparation for the next regularly scheduled IETF. I will send a note out separately with a more formal announcement and details as they become available. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 12:02:32 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07810 for ; Tue, 12 Sep 2000 12:02:30 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA14891 for snmpconf-outgoing; Tue, 12 Sep 2000 11:45:50 -0400 (EDT) Date: Tue, 12 Sep 2000 17:45:10 +0200 Message-Id: <200009121545.RAA26326@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: DISMAN Mailing List In-reply-to: <200009072237.SAA29818@aix43.snmp.com> (message from Steve Moulton on Thu, 07 Sep 2000 18:37:50 -0400) Subject: Re: snmpconf Interim Meeting Notes Day Two References: <200009072237.SAA29818@aix43.snmp.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Moulton writes: Steve> In summary, we are talking about augmenting the schedule MIB Steve> so that we have the start and stop times rather than having Steve> multiple entries. This is a proposed change. The revision of RFC 2591 is currently waiting for some final touches from me. If you have any concrete proposals to enhance the schedule MIB for configuration management purposes, so please speak up quickly. From reading the snmpconf minutes, I do not understand what your proposed change actually looks like. So please come up with some more details quickly and please get the DISMAN WG involved by CC'ing them or moving discussion of the proposed scheduling MIB change to the DISMAN list itself. Thanks, /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 12:40:32 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08793 for ; Tue, 12 Sep 2000 12:40:31 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA15604 for snmpconf-outgoing; Tue, 12 Sep 2000 12:22:54 -0400 (EDT) Date: Tue, 12 Sep 2000 18:22:15 +0200 Message-Id: <200009121622.SAA26987@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <39BE096C.937EF68B@nextbeacon.com> (message from Steve Waldbusser on Tue, 12 Sep 2000 03:46:04 -0700) Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.com> <200009111635.SAA29855@henkell.ibr.cs.tu-bs.de> <39BE096C.937EF68B@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Steve Waldbusser writes: Steve> The rest is simply Modeling 101: Steve> We define different concepts as different objects. Then we Steve> structure them to show the appropriate relationships between Steve> the concepts/objects. We shouldn't encode filter and action Steve> into the same object for the same reason that we shouldn't Steve> encode policyStatus as a decimal number at the end of the Steve> policyAction string. We outlawed OPAQUE syntax years ago Steve> because of similar bad modeling practices it was abused for. This is where we obviously have some disagreement. I think we are talking in the policy management context about high-level control programs that we want to distribute, invoke and execute. We are not talking about fine grained little objects for network element monitoring. The modeling practices for network element monitoring simply do not fit the requirements for high-level network control programming. Whenever I write a piece of (control) software, I leave it to the execution environment to tokenize the input into an internal format that is efficient to execute. I do not expect to be able to tweak this internal format. In fact, I am happy with any optimizations the executing engine is able to make. Policy control rules are for me just another high-level control language and I think that this WG needs to discuss which level of granularity makes sense for distributing scripts written in this language to policy-aware network elements. I am seriously concerned that very fine-grained granularity adds considerable complexity without any clear benefits. Steve> The point is that stuffing them into one MIB object doesn't Steve> meet the requirements (it doesn't encode priority) and was bad Steve> modelling practice because it didn't anticipate the full Steve> requirements for policy groups. I do not agree. I can easily associate a priority to the policy rule in the language itself, e.g. on (condition) do action1; action2; with priority n; It all boils down to get the policy scripting language definition right. We want it to be flexible and efficient and it should run in relatively resource constraint environments. I believe that this WG should spend all its resources to get the language right rather than reinventing wheels that do already exist (both as specifications and actual implementations). Steve> We agree that filters and actions are separate. We're simply Steve> debating what's the best delimiter between filter and Steve> action. I'd rather use the existing facilities of the SNMP Steve> protocol engine to delimit objects instead of writing code that Steve> parses an octet string looking for internal delimiters. Using Steve> existing facilities results in 2 MIB objects rather than 1, but Steve> results in less code overall because each MIB object is Steve> simpler. Which I believe is not true if you talk about high-level control programs. I still prefer to write my code in C, C++, Java, and to let the execution environment turn it into something that executes efficiently. The parsing is a one-time activity when you install a policy script and won't make a big difference compared to the overhead of actually evaluating the filter conditions regularly. Even the MIB objects currently proposed require some amount of parsing on the agent side. (To be consequent in your reasoning, you would have to turn an expression into a tree representation and download this as a set of MIB objects. ;-) Steve> Maybe the script MIB isn't as generic as I maintained. In the Steve> script MIB, scripts are started (only) by writing a value to Steve> smLaunchStart. In the policy management MIB we need scripts to Steve> re-execute automatically based on timer events. You can use the scheduling MIB to start scripts automatically based on timer events. But even then, I would argue that fine-grained evaluation of timed conditions is subject of the language runtime system to be really efficient. The scheduling MIB should be used to schedule the activation and deactivation of complete policy scripts (aka policy groups in PCIM). Steve> Further, the Script MIB dictates that scripts are passed the Steve> contents of the smLaunchArgument object. In the PM MIB, we need Steve> scripts to be passed the index of "this element". I can't Steve> imagine a reading of the script MIB that would allow such a Steve> change of semantics. I also can't imagine that such a position Steve> would be healthy to the future of the script MIB. I believe that this is not a problem since I propose to use the script MIB only to distribute and activate/deactivate policy scripts that contain several policy rules. I believe the timed evaluation of conditions and the passing of condition context information to the actions is the task of the language and its runtime system. Steve> You say that the script MIB doesn't define an execution Steve> environment - that may be true for language and libraries, but Steve> it definitely not true for scheduling and parameter passing and Steve> other areas where it is very explicit and DIFFERENT than the Steve> Policy Management MIB requirements. In the granularity I propose, the script MIB scheduling and parameter passing mechanisms should work just fine. Steve> Meta issue: In order to make this work we would have to say Steve> that the semantics of a registered MIB object are not forever Steve> defined by the description clause, but can change in Steve> unanticipated ways based on what other MIB object is "pointing" Steve> to them. This seems to shake the foundation of our SMI Steve> framework. I do not understand. Which registered MIB object are you talking about? Steve> We agree that policy groups will be required for complex Steve> policies on complex networks. However, you're confusing the Steve> encoding of policies with the modeling of policy Steve> relationships. Encoding two things into one object has never Steve> been the desirable way of modeling a relationship between them. I believe that any programming language with conditional statements is a viable counter argument to this statement. And I am not even considering real rule based languages which I used back in those days when expert systems were changing the world as policy systems do today. ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 12:58:31 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09352 for ; Tue, 12 Sep 2000 12:58:31 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16185 for snmpconf-outgoing; Tue, 12 Sep 2000 12:42:04 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 12 Sep 2000 12:44:51 -0400 Subject: Re: snmpconf well, back to work From: Jon Saperia To: Message-ID: In-Reply-To: <200009121622.SAA26987@henkell.ibr.cs.tu-bs.de> 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 09/12/2000 12:22 PM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: >>>>>> Steve Waldbusser writes: > > Steve> The rest is simply Modeling 101: > > Steve> We define different concepts as different objects. Then we > Steve> structure them to show the appropriate relationships between > Steve> the concepts/objects. We shouldn't encode filter and action > Steve> into the same object for the same reason that we shouldn't > Steve> encode policyStatus as a decimal number at the end of the > Steve> policyAction string. We outlawed OPAQUE syntax years ago > Steve> because of similar bad modeling practices it was abused for. > > This is where we obviously have some disagreement. I think we are > talking in the policy management context about high-level control > programs that we want to distribute, invoke and execute. We are not > talking about fine grained little objects for network element > monitoring. The modeling practices for network element monitoring > simply do not fit the requirements for high-level network control > programming. From my perspective, as an editor, not co-chair, I think there are important differences in the semantics of the specific objects in the policy document. I think this is what Steve was pointing out. The status of a policy is not the status of what shows in the script mib which talks about execution status. The status of a policy is semantically much more complex and is not appropriately conveyed in the script mib objects. The status of a policy could be overridden for example. /jon From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 13:03:23 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09484 for ; Tue, 12 Sep 2000 13:03:23 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16329 for snmpconf-outgoing; Tue, 12 Sep 2000 12:47:56 -0400 (EDT) Date: Tue, 12 Sep 2000 09:45:42 -0700 (PDT) From: Randy Presuhn Message-Id: <200009121645.JAA27863@dorothy.bmc.com> To: snmpconf@snmp.com Subject: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id MAA16329 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09484 Hi - > Date: Tue, 12 Sep 2000 17:45:10 +0200 > Message-Id: <200009121545.RAA26326@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: snmpconf@snmp.com > CC: DISMAN Mailing List > In-reply-to: <200009072237.SAA29818@aix43.snmp.com> (message from Steve > Moulton on Thu, 07 Sep 2000 18:37:50 -0400) > Subject: Re: snmpconf Interim Meeting Notes Day Two > References: <200009072237.SAA29818@aix43.snmp.com> ... > From reading the snmpconf minutes, I do not understand what your > proposed change actually looks like. So please come up with some more > details quickly and please get the DISMAN WG involved by CC'ing them > or moving discussion of the proposed scheduling MIB change to the > DISMAN list itself. ... If there are to be proposed changes to the schedule MIB, please make those proposals NOW. The WG last call on this document was to have ended months ago, and it's just been a matter of editor availability that's kept this from being handed to the AD for presentation to the IESG. If changes are necessary, please spell them out now. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 13:29:52 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10107 for ; Tue, 12 Sep 2000 13:29:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA16706 for snmpconf-outgoing; Tue, 12 Sep 2000 13:14:10 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 12 Sep 2000 13:16:54 -0400 Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009121645.JAA27863@dorothy.bmc.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 09/12/2000 12:45 PM, Randy Presuhn at rpresuhn@dorothy.peer.com wrote: > If there are to be proposed changes to the schedule MIB, please > make those proposals NOW. The WG last call on this document was > to have ended months ago, and it's just been a matter of editor > availability that's kept this from being handed to the AD for > presentation to the IESG. If changes are necessary, please > spell them out now. Randy and Juergen, Hongal had been pursuing this issue and we talked a bit about it at the IETF meeting. I do not think there is consensus yet. From the posted minutes, there were the following relevant points: > . When using the schedule MIB, you would need to create a MIB entry > that would point back to the entry that would be started. > Actually you would need two entries in the schedule MIB one for starting > (setting the admin status to enable) and one for stopping > (setting the admin status to disable). We may be able > to add an augments clause to the schedule MIB to pack the > information into one entry. > > . One needs to make sure that the forward and backward pointers > stay in sync. To do this, there should be a one-to-one pairing. > Have two schedule entries pointing to one ifAdminStatus would be > difficult to maintain. > > . If we use the schedule MIB, we need to bear in mind that it has > up to one minute latency after one presses the go button. > > In summary, we are talking about augmenting the schedule MIB so > that we have the start and stop times rather than having multiple > entries. This is a proposed change. You will note from David Partain's note that he is organizing our list of issues and actions. I can ask that we get to this ASAP by can not promise a specific resolution in a specific time. That said, we have the following choices. If time pressure makes it right to move forward with the Schedule MIB then, we will have to work out some other solution. If it is possible to wait until we conclude our interim meeting and post to the mail list, then we might get good input to your effort. Folks, Randy and Juergen have a point about the disman work. When we bring these topics up on this [snmpconf] list we should be sure to cross post them to the disman group. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Tue Sep 12 15:43:37 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13051 for ; Tue, 12 Sep 2000 15:43:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA19652 for snmpconf-outgoing; Tue, 12 Sep 2000 15:23:32 -0400 (EDT) Message-ID: <39BE8481.6320FC2C@cisco.com> Date: Tue, 12 Sep 2000 12:31:13 -0700 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work References: <39AE9600.4DCF1FD6@enterasys.com> <200009012141.XAA13614@henkell.ibr.cs.tu-bs.de> <39B55D08.20FD256A@nextbeacon.com> <200009111635.SAA29855@henkell.ibr.cs.tu-bs.de> <39BE096C.937EF68B@nextbeacon.com> <200009121622.SAA26987@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > > >>>>> Steve Waldbusser writes: > I agree with Juergen's concerns about the SNMPCONF execution environment and MIB design. But I'm not sure I understand the execution flow, so I'll review how I think it works: 1) The agent and NMS populate the pmElementTypeRegTable, which specifies the static MIB sub-tree (pmElementTypeRegOIDPrefix object) that the agent will iterate through, for each element type. 2a) If the pmPolicyCalender object is not used, then a pmPolicyFilter is invoked in an implementation-specific manner. There is no obvious linkage between an individual pmPolicyEntry and the pmElementTypeRegTable, but it appears that: - a given pmPolicyFilter may only pertain to a single element type - the agent must maintain a dynamic mapping between all elements and all policies, which may be non-trivial. - both the pmPolicyFilter and pmPolicyAction scripts must assume that the appropriate pmElementTypeRegOIDPrefix will be used for iteration, because they have no verification. Only the instance portion of the complete OID is passed in the 'dollar vars'. 2b) I have no idea how the iteration model works for calendar based policies, i.e., which value of pmElementTypeRegOIDPrefix the agent will use when the Scheduling MIB invokes the associated (pmPolicyFilter or pmPolicyAction?) script. 3) After determining that some elements have 'changed', or perhaps just running continuously, within a polling interval specified by the lower bound of all pmPolicyFilterMaxLatency objects, the agent selects a pmPolicyFilter script and a pmElementTypeRegOIDPrefix. 4) For each instance in the specified sub-tree (in the same context as the PM MIB I presume) the pmPolicyFilter is executed. The filter logic examines the instance info (in the dollar vars), calls accessor functions, makes arithmetic and logical calculations, and determines if the implied MIB object is 'selected' by this policy. There is no stateful data at all - just the implied MIB root and the dollar vars that comprise the 'current' MIB object. It's not clear (maybe implementation-specific) if the agent should internally save the selected instances until the end of 'policy invocation', or if it should call the associated pmPolicyAction as each selected instance is identified. I'll assume the former, although there are will be some policy scripts which cannot be written without this unspecified choice impacting the outcome. 5) For each value in the selected instance list (in no assigned order?), the agent invokes the pmPolicyAction script. Again, there is no state and no info passed from the policy filter to the policy action. Given this understanding of the execution environment, I agree with Juergen that the separation of conditions and actions is less than useful. I'll use his example: on (condition) do action1; action2; with priority n; The MIB does not provide any possibility of script sharing, so the (condition) and (action1;action2) logic is statically and tightly coupled. Separating this logic into 2 scripts will cause high coupling and low cohesion, which is the opposite of proper programming practices. This is also confusing. Most of the execution order and policy selection details are unspecified, and yet, policy filters must run separately from policy actions. It would be better to explicitly define the iteration behavior such that a selected instance is acted upon at once (inline), rather than deferred for later processing. This is the 'natural' behavior implied by the well understood logic example above. A single script is much more readable and manageable. Andy > Steve> The rest is simply Modeling 101: > > Steve> We define different concepts as different objects. Then we > Steve> structure them to show the appropriate relationships between > Steve> the concepts/objects. We shouldn't encode filter and action > Steve> into the same object for the same reason that we shouldn't > Steve> encode policyStatus as a decimal number at the end of the > Steve> policyAction string. We outlawed OPAQUE syntax years ago > Steve> because of similar bad modeling practices it was abused for. > > This is where we obviously have some disagreement. I think we are > talking in the policy management context about high-level control > programs that we want to distribute, invoke and execute. We are not > talking about fine grained little objects for network element > monitoring. The modeling practices for network element monitoring > simply do not fit the requirements for high-level network control > programming. > > Whenever I write a piece of (control) software, I leave it to the > execution environment to tokenize the input into an internal format > that is efficient to execute. I do not expect to be able to tweak this > internal format. In fact, I am happy with any optimizations the > executing engine is able to make. Policy control rules are for me just > another high-level control language and I think that this WG needs to > discuss which level of granularity makes sense for distributing > scripts written in this language to policy-aware network elements. I > am seriously concerned that very fine-grained granularity adds > considerable complexity without any clear benefits. > > Steve> The point is that stuffing them into one MIB object doesn't > Steve> meet the requirements (it doesn't encode priority) and was bad > Steve> modelling practice because it didn't anticipate the full > Steve> requirements for policy groups. > > I do not agree. I can easily associate a priority to the policy rule > in the language itself, e.g. > > on (condition) do > action1; > action2; > with priority n; > > It all boils down to get the policy scripting language definition > right. We want it to be flexible and efficient and it should run in > relatively resource constraint environments. I believe that this WG > should spend all its resources to get the language right rather than > reinventing wheels that do already exist (both as specifications and > actual implementations). > > Steve> We agree that filters and actions are separate. We're simply > Steve> debating what's the best delimiter between filter and > Steve> action. I'd rather use the existing facilities of the SNMP > Steve> protocol engine to delimit objects instead of writing code that > Steve> parses an octet string looking for internal delimiters. Using > Steve> existing facilities results in 2 MIB objects rather than 1, but > Steve> results in less code overall because each MIB object is > Steve> simpler. > > Which I believe is not true if you talk about high-level control > programs. I still prefer to write my code in C, C++, Java, your favourite language here> and to let the execution environment > turn it into something that executes efficiently. The parsing is a > one-time activity when you install a policy script and won't make a > big difference compared to the overhead of actually evaluating the > filter conditions regularly. Even the MIB objects currently proposed > require some amount of parsing on the agent side. (To be consequent in > your reasoning, you would have to turn an expression into a tree > representation and download this as a set of MIB objects. ;-) > > Steve> Maybe the script MIB isn't as generic as I maintained. In the > Steve> script MIB, scripts are started (only) by writing a value to > Steve> smLaunchStart. In the policy management MIB we need scripts to > Steve> re-execute automatically based on timer events. > > You can use the scheduling MIB to start scripts automatically based on > timer events. But even then, I would argue that fine-grained > evaluation of timed conditions is subject of the language runtime > system to be really efficient. The scheduling MIB should be used to > schedule the activation and deactivation of complete policy scripts > (aka policy groups in PCIM). > > Steve> Further, the Script MIB dictates that scripts are passed the > Steve> contents of the smLaunchArgument object. In the PM MIB, we need > Steve> scripts to be passed the index of "this element". I can't > Steve> imagine a reading of the script MIB that would allow such a > Steve> change of semantics. I also can't imagine that such a position > Steve> would be healthy to the future of the script MIB. > > I believe that this is not a problem since I propose to use the script > MIB only to distribute and activate/deactivate policy scripts that > contain several policy rules. I believe the timed evaluation of > conditions and the passing of condition context information to the > actions is the task of the language and its runtime system. > > Steve> You say that the script MIB doesn't define an execution > Steve> environment - that may be true for language and libraries, but > Steve> it definitely not true for scheduling and parameter passing and > Steve> other areas where it is very explicit and DIFFERENT than the > Steve> Policy Management MIB requirements. > > In the granularity I propose, the script MIB scheduling and parameter > passing mechanisms should work just fine. > > Steve> Meta issue: In order to make this work we would have to say > Steve> that the semantics of a registered MIB object are not forever > Steve> defined by the description clause, but can change in > Steve> unanticipated ways based on what other MIB object is "pointing" > Steve> to them. This seems to shake the foundation of our SMI > Steve> framework. > > I do not understand. Which registered MIB object are you talking > about? > > Steve> We agree that policy groups will be required for complex > Steve> policies on complex networks. However, you're confusing the > Steve> encoding of policies with the modeling of policy > Steve> relationships. Encoding two things into one object has never > Steve> been the desirable way of modeling a relationship between them. > > I believe that any programming language with conditional statements is > a viable counter argument to this statement. And I am not even > considering real rule based languages which I used back in those days > when expert systems were changing the world as policy systems do > today. ;-) > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 03:43:31 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02695 for ; Wed, 13 Sep 2000 03:43:31 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA07387 for snmpconf-outgoing; Wed, 13 Sep 2000 03:27:17 -0400 (EDT) Date: Wed, 13 Sep 2000 09:26:41 +0200 Message-Id: <200009130726.JAA14739@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: (message from Jon Saperia on Tue, 12 Sep 2000 12:44:51 -0400) Subject: Re: snmpconf well, back to work References: Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Jon Saperia writes: Jon> From my perspective, as an editor, not co-chair, I think there Jon> are important differences in the semantics of the specific Jon> objects in the policy document. I think this is what Steve was Jon> pointing out. Jon> The status of a policy is not the status of what shows in the Jon> script mib which talks about execution status. The status of a Jon> policy is semantically much more complex and is not appropriately Jon> conveyed in the script mib objects. The status of a policy could Jon> be overridden for example. Not sure I understand what you are talking about here. Are you talking about policy groups, policy rules, policy conditions and actions when you use the term policy? And what does it mean to overwrite the status? You are probably refering to pmTrackingPolicyToElementStatus and pmTrackingElementToPolicyStatus (since these are the only status objects I could find that are not RowStatus). In this case, you talk about the binding of policy conditions to the set of elements (or targets). I believe this can be handled appropriately in a pure language based approach as well. And even if this WG needs to introduce new tables to provide additional interfaces, I still believe that working from existing MIBs which have been specified and implemented is worth to be seriously considered. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 04:15:51 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02980 for ; Wed, 13 Sep 2000 04:15:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id EAA07590 for snmpconf-outgoing; Wed, 13 Sep 2000 04:00:32 -0400 (EDT) Date: Wed, 13 Sep 2000 09:59:53 +0200 Message-Id: <200009130759.JAA15426@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: (message from Jon Saperia on Tue, 12 Sep 2000 13:16:54 -0400) Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) References: Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Jon Saperia writes: Jon> Folks, Randy and Juergen have a point about the disman work. When Jon> we bring these topics up on this [snmpconf] list we should be Jon> sure to cross post them to the disman group. I am not really a big fan of extensive cross postings (since I happen to be on both lists anyway). I think a few cross posts to tell people on which list a certain issue is handled is more appropriate. It might be helpful if the chairs of the WGs can actually negotiate how the WGs can best cooperate. For example, if the snmpconf folks can formulate a clear requirement what they need from the schedule MIB, then the disman folks may be able to provide a solution without extensive cross postings in both WG mailing lists. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 08:14:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05736 for ; Wed, 13 Sep 2000 08:14:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id HAA09130 for snmpconf-outgoing; Wed, 13 Sep 2000 07:56:56 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 07:59:46 -0400 Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009130759.JAA15426@henkell.ibr.cs.tu-bs.de> 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 09/13/2000 3:59 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > It might be helpful if the chairs of the WGs can actually negotiate > how the WGs can best cooperate. For example, if the snmpconf folks can > formulate a clear requirement what they need from the schedule MIB, > then the disman folks may be able to provide a solution without > extensive cross postings in both WG mailing lists. > > /js Juergen, I think this is an excellent idea and good way to collect the input for this one. David Partain and I talked about this and would like to propose that the SNMNPCONF WG give you a short set of requirements bullets and a set of ideas about how we could use the schedule MIB with some changes. I will send out a separate note starting this off. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 08:19:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05810 for ; Wed, 13 Sep 2000 08:19:17 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA09237 for snmpconf-outgoing; Wed, 13 Sep 2000 08:04:05 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 08:06:56 -0400 Subject: Re: snmpconf well, back to work From: Jon Saperia To: Message-ID: In-Reply-To: <200009130726.JAA14739@henkell.ibr.cs.tu-bs.de> 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 09/13/2000 3:26 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > Not sure I understand what you are talking about here. Are you talking > about policy groups, policy rules, policy conditions and actions when > you use the term policy? And what does it mean to overwrite the > status? What I mean is the state of the policy. For example you will have seen postings leading up to the last IETF where a policy can be overridden by the CLI for example or a policy can be superseded by another. Thus the answer to your question above is policy as an entry in the Policy Table and policy in the tables you reference below. To the best of what I know, the SNMPCONF work has not yet explicitly used the term 'condition'. > > You are probably refering to pmTrackingPolicyToElementStatus and > pmTrackingElementToPolicyStatus (since these are the only status > objects I could find that are not RowStatus). In this case, you talk > about the binding of policy conditions to the set of elements (or > targets). I believe this can be handled appropriately in a pure > language based approach as well. And even if this WG needs to Your term, policy condition here is not clear to me. Additionally we do width to have the state information visible via MIB Objects as described above. > introduce new tables to provide additional interfaces, I still believe Not sure which WG you mean here? > that working from existing MIBs which have been specified and > implemented is worth to be seriously considered. I agree when there is a good fit like I think there is in the Schedule MIB Module. I do not think the script mib as anywhere near as good a fit. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 08:27:43 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06005 for ; Wed, 13 Sep 2000 08:27:43 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA09330 for snmpconf-outgoing; Wed, 13 Sep 2000 08:10:58 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 08:13:49 -0400 Subject: snmpconf Schedule Requirements 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 is a new topic to follow up on the response I made to Juergen about the Schedule MIB Module. The purpose of this thread is to collect requirements for policy scheduling. I would like to keep this thread focused on: What do we need for controlling policy in SNMP managed elements? I see the output as one of the following: 1. A list of requirements, and a. use the schedule mib module with specific modifications b. do not use the schedule mib module because of a list of not met or poorly met requirements. If this is the case, then alternatives should be suggested (e.g., somehow using ical). c. use the schedule mib module as is. Hongal did a very good job at the interim meeting discussing some of his work. We probably could start with that. I would like to ask that we keep this thread focused in this issue and put in other threads the issues that will come up in this discussion about what happens when policies change etc. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 09:46:13 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08088 for ; Wed, 13 Sep 2000 09:46:13 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA10674 for snmpconf-outgoing; Wed, 13 Sep 2000 09:29:58 -0400 (EDT) From: Jeff Case Date: Wed, 13 Sep 2000 09:29:53 -0400 (EDT) Message-Id: <200009131329.JAA08698@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >You are probably refering to pmTrackingPolicyToElementStatus and >pmTrackingElementToPolicyStatus (since these are the only status >objects I could find that are not RowStatus). In this case, you talk >about the binding of policy conditions to the set of elements (or >targets). I believe this can be handled appropriately in a pure >language based approach as well. And even if this WG needs to >introduce new tables to provide additional interfaces, I still believe >that working from existing MIBs which have been specified and >implemented is worth to be seriously considered. i agree with your last statement the incorporation of work from other mib documents has been considered, is being considered, and will continue to be considered the disman work that you are pushing for has specifically been considered so far, a convincing case for the incorporation of that work has not happened leveraging that work does not appear to have a good pain/gain tradeoff but it is still being discussed actively regards, jdc From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 09:46:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08099 for ; Wed, 13 Sep 2000 09:46:25 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA10712 for snmpconf-outgoing; Wed, 13 Sep 2000 09:30:48 -0400 (EDT) From: Jeff Case Date: Wed, 13 Sep 2000 09:30:46 -0400 (EDT) Message-Id: <200009131330.JAA08717@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf well, back to work Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com i wonder if it is time to start using different subject lines for various threads if not, perhaps we could pick a new subject line to use for everything for a while :-) regards, jdc From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 11:29:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10330 for ; Wed, 13 Sep 2000 11:29:46 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA13533 for snmpconf-outgoing; Wed, 13 Sep 2000 11:13:47 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 11:16:34 -0400 Subject: snmpconf New Subject Lines for Topics 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 on 09/13/2000 9:30 AM, Jeff Case at case@snmp.com wrote: > if not, perhaps we could pick a new subject line to use for everything for > a while Good point. Three things: 1. David Partain is in the process of breaking up the notes from the meeting and the 'issues' list we have been working on into discussion topics. That may help this a bit. 2. I started a thread this morning on a new set of issues related to the Schedule MIB Module. 3. Others feel free to add new topics as they make sense - We should probably look to see what David publishes first as a starting point. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 16:14:56 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17075 for ; Wed, 13 Sep 2000 16:14:55 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA23990 for snmpconf-outgoing; Wed, 13 Sep 2000 15:54:55 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 15:57:38 -0400 Subject: snmpconf SNMPCONF Interim Meeting Announcement From: Jon Saperia To: snmpconf , Bert Wijnen , Randy Bush , 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 The SNMPCONF working group will hold and interim meeting on Thursday and Friday October 26 and 27, 2000. MEETING TIMES: The meeting will be from 9:00am to 5:30pm on Thursday October 26 and from 9:00am to 4:00pm on Friday October 27. Please be sure to keep these times in mind when making travel arrangements so that we can make progress during all of the posted meeting time. LOCATION: The meeting hosted by SNMP Research, Inc. will take place in Knoxville, TN. AIRPORT: The local airport is McGhee Tyson Airport (TYS) in Knoxville, Tennessee. For those seeking additional information please visit: http://www.tys.org/ HOTEL: A special rate has been arranged at the Downtown Hilton, 501 W. Church Ave., Knoxville, TN 37902, 1-865-523- 2300. The Hilton is within walking distance (1 mile) of the meeting site. For reservations, call the hotel directly toll free at 1-877-644-5866. Make sure you state that you are with the "SNMP Conference" to get the $76 conference rate for a single or double room. The hotel does not provide free shuttle service from the airport, but there are taxis and shuttle services available at the airport to the downtown area. It is 14.1 miles from the airport to the Hilton if you rent a car. Parking is available at the hotel and meeting site. Terri Brogdon is working with Jeff Case on the logistics for the October 26-27 meeting scheduled in Knoxville, TN. The meetings will be held at the University of Tennessee campus. Room location is still to be determined. If you have any questions regarding travel to Knoxville, please contact Terri directly at tbrogdon@snmp.com or by phone 1-865-573-1434. PRELIMINARY AGENDA: Brief review of current status and schedule Review of current issues list, items that are closed and open Work on items on issues list that are not yet resolved Review of revised BCP Document Review of DiffServ Policy MIB (depending on updates in the DiffServ WG) Other topics as proposed on the list. Next steps and preparation for the next IETF. Thanks to Terri and Jeff for getting this organized. /Jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 13 17:51:52 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18147 for ; Wed, 13 Sep 2000 17:51:52 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id RAA27819 for snmpconf-outgoing; Wed, 13 Sep 2000 17:39:03 -0400 (EDT) Message-ID: <39BFF3A1.A125ED7@mediaone.net> Date: Wed, 13 Sep 2000 17:37: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: snmpconf Interim Meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, The IETF meeting in San Diego ends only six days before the Hanukkah/Xmas weekend. That may be a fairly heavily booked weekend for flights and hotels. If we are planning to have an SnmpConf Interim meeting following the IETF meeting, it would be very good to discuss that right away, so people can make early plane reservations (even though we don't know what hotel yet). dbh -- --- David Harrington Network Management Standards Architect 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 Sep 14 05:32:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07706 for ; Thu, 14 Sep 2000 05:32:26 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA13052 for snmpconf-outgoing; Thu, 14 Sep 2000 05:15:28 -0400 (EDT) Message-Id: <200009140914.LAA06927@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 X-Priority: normal In-reply-to: Your message of Wed, 13 Sep 2000 17:37:38 -0400. <39BFF3A1.A125ED7@mediaone.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19505.968923213.1@y5m638.lmera.ericsson.se> Date: Thu, 14 Sep 2000 11:20:13 +0200 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id FAA13048 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id FAA13052 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA07706 Hi all, David Harrington wrote: > The IETF meeting in San Diego ends only six days before the > Hanukkah/Xmas weekend. That may be a fairly heavily booked weekend for > flights and hotels. If we are planning to have an SnmpConf Interim > meeting following the IETF meeting, it would be very good to discuss > that right away, so people can make early plane reservations (even > though we don't know what hotel yet). I don't know what the rest of the group thinks, but Jon and I are hoping that this upcoming meeting in Knoxville will be the last interim meeting. As such, we haven't really talked about the possibility of having a meeting directly after the IETF. Do you think that we need to consider this as a group? Even if it were necessary, I think there's going to be a great deal of resistance to staying away even longer right before the holidays. Cheers, -- 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 Sep 14 11:36:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17299 for ; Thu, 14 Sep 2000 11:36:12 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA19147 for snmpconf-outgoing; Thu, 14 Sep 2000 11:10:37 -0400 (EDT) From: Jeff Case Date: Thu, 14 Sep 2000 11:10:33 -0400 (EDT) Message-Id: <200009141510.LAA13584@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf Interim Meeting Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >Even if it were necessary, I think there's going to be a great >deal of resistance to staying away even longer right before the >holidays. i would be very surprised if anyone was able to convince me to stay after the san diego meeting rather, if we think we need more time in san diego, let's start requesting multiple time slots now, for meetings during the week regards, jdc From owner-snmpconf@seymour39.SNMP.COM Thu Sep 14 14:53:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20556 for ; Thu, 14 Sep 2000 14:53:46 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id OAA23890 for snmpconf-outgoing; Thu, 14 Sep 2000 14:31:06 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 14 Sep 2000 14:33:44 -0400 Subject: Re: snmpconf Interim Meeting From: Jon Saperia To: Message-ID: In-Reply-To: <200009141510.LAA13584@seymour4.snmp.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 09/14/2000 11:10 AM, Jeff Case at case@snmp.com wrote: > rather, if we think we need more time in san diego, let's start requesting > multiple time slots now, for meetings during the week That probably is an excellent plan not matter what. When David Partain and I are asked to make requests for schedule time we will ask the ADs for two good time slots. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Sep 14 17:19:04 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24732 for ; Thu, 14 Sep 2000 17:19:04 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA28090 for snmpconf-outgoing; Thu, 14 Sep 2000 17:00:29 -0400 (EDT) Message-ID: <39C12367.10B285FF@riverstonenet.com> Date: Thu, 14 Sep 2000 14:13:43 -0500 From: Thippanna Hongal Organization: Riverstone Network Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf , "disman@dorothy.peer.com" Subject: snmpconf Schedule Requirements 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 all Here is the list of requirement I did compile to associate time with the policies. thanks hongal Riverstone Networks Inc,. Santa Clara CA, U.S.A ---------------------------------------------------------- SNMP Policy Configuration Schedule Requirements. I. Schedule policy execution based on specific start times and running to completion. (believe current Schedule MIB does this for us ) II. Schedule policy to be active for a duration and then end based on filter or action conditions or duration expiration. It is the duration expiration that is problematic for the Schedule MIB Module. Here follows what we need, so that we can achieve it using and AUGMENTing schedule MIB.. 1. The AUGMENTation required for schedule mib of rfc 2591, to support start and end time of day. Requirement a: A field which will say the start time and end time. The time can use HHMMSS:HHMMSS with the first part of time representing the start time and the last part representing the end time. Syntax: 1. The syntax can be HHMMSS:HHMMSS 2. we can use the 'TIME' convention defined in rfc2445.txt 3. TDB The current schedHour and schedMinute fields are masks and will permit multiple hours and times and leads to confusion to use for this purpose. Field 'schedTimeOfDay' with syntax for string format : HHMMSS:HHMMSS Requirement b: A field which will specify the overall Date and Time during which the policy is valid. Its basically a range of calendar Date and Time The further details on syntax: TDB Syntax: 1. This filed can take a syntax of 'yyyymmddThhmmss/yyyymmddThhmmss' 2. we can use the 'DATE-TIME' convention defined in rfc2445.txt 3. TDB Field 'schedValidDate' Requirement c: A field which will distinguish the time specified is local time or UTC time. The field can take enumerated numbers like, localTime(1), utcTime(2). Essentially I propose a field 'schedTimeType' Requirement d: Since we have two events, one is the start and another is end clearly specified in the schedTimeOfDay, we have to specify what is the 'schedValue' to be set during 'start' and during 'end' times. schedStartValue INTEGER schedEndValue INTEGER More Details:TDB Requirement e: 'schedType' : We need a new schedule type : schedType = policy(4) This type of schedule specifies that the schedule is of 'level trigger' type, meaning it has both start time and end time, and their respective value to set. The objects schedValue, schedHour and schedMinute are not used when the schedType == 'policy'. Instead the new objects schedTimeOfDay, schedValidDate, schedTimeType, schedStartValue, schedEndValue are used. Requirement f: schedType = policyDuration(5) This new type is required to schedule policies based on duration. The schedInterval is the existing field in the schedule mib which represents the duration in seconds, Objects that are not used calendar objects: (schedHour,schedMinute,schedMonth,schedWeekDay,schedDay) schedValue Object that are new and used schedStartValue schedEndValue schedInterval This is one time operation, which starts when the policy is enabled and continues to be in the enabled state until the end of the duration specified. 2. To put everything together the AUGMENTed table has to have schedTimeOfDay schedValidDate schedTimeType schedStartValue schedEndValue with additional schedType{policy(4),policy-periodic(5)}, and more descriptions on how it works. 3. With this proposal we can do a complex scheduling where we can specify the overall date and time with exact TimeOfDay at which policy has to start and end. With masks schedMonth,schedWeekDay,schedDay for sched MIB which allows multiple entries in it. We can do a schedule for example : ' 7days and 4 weeks' Having said this, we have all the advanced features the scheduler MIB has. 4. This model is similar to Policy Framework Group model of policyTimePeriodConditionAuxClass, except for the policyDuration type or schedule. END From owner-snmpconf@seymour39.SNMP.COM Fri Sep 15 03:23:07 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15817 for ; Fri, 15 Sep 2000 03:23:06 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id DAA14956 for snmpconf-outgoing; Fri, 15 Sep 2000 03:06:09 -0400 (EDT) X-From-Line: strauss@ibr.cs.tu-bs.de Thu Sep 14 17:39 MET 2000 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f Original-Sender: strauss@ibr.cs.tu-bs.de From: Frank Strauss To: snmpconf@snmp.com Subject: Comments on draft-ietf-snmpconf-pm-02 Date: 14 Sep 2000 17:39:07 +0200 Message-ID: User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Length: 4217 Lines: 98 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I've just read the Policy-Based Management MIB draft. Here are some comments and questions on it. Some are just minor corrections, but some are major design issues. Several *Index object types have integer range restrictions (0..65535). Why at all? Why 64k? Why is pmPolicyFilter restricted to a maximum size of 65535 octets? If there's a good reason for this size, why is pmPolicyAction not restricted? Why is pmPolicyFilterMaxLatency of type Integer32 (signed) but restricted to 0..2147483647? Why not just Unsigned32? What is the purpose of pmPolicyActionMaxLatency? At first sight, it seems like an action is called exactly when a filter is evaluated being true. Thus the action latency simply depends on pmPolicyFilterMaxLatency and the result of the filter evaluation. The pmPolicyPrecedence DESCRIPTION confuses me completely. ;-) Furthermore, it says `These values must be unique on the local policy system...' which is difficult to ensure, I think. It is not possible to lookup pmPolicyTable rows by pmPolicyGroup, since pmPolicyGroup is no INDEX element. However this might be useful. The pmPolicyMatches DESCRIPTION says `The number of policies ...' while it means the number of elements. However, I do not see much value in this object type. When a manager reads this variable, it does not know at which stage in policy evaluation this value is current. The pmElementTypeRegOIDPrefix has a DESCRIPTION that explains the separation of the prefix and the instance identifying part, which consists of N sub-identifiers. This is what I guess is correct. However, the text describes that "$1" can be used in place of any (single?!) decimal sub-identifier, e.g. in section 6.2.1. I think "$1" is not a good name, since there cannot be a "$2". How about "*"? It's explicitly stated that `no state is remembered from the previous invocation' in filters and actions. So: how can counters be evaluated by a filter in a meaningful way? The DESCRIPTION of pmElementTypeRegName says it's a `description'. I guess it should be a `name'. The MIB module contains various comments. This is no good idea, since this information is not accessible. Important information should be places in DESCRIPTIONs. Unimportent information should be removed. The pmCapabilitiesTable represents a new way to express agent capabilities, but with a limited scope. I think it is not a good idea. pmCapabilitiesType is of type OID. The DESCRIPTION says that IANA will publish a list of valid values. Presuming this is a good idea at all, it should be an enumeration type. The comment in front of the pmCapabilitiesTable and the DESCRIPTION of the pmCapabilitiesSubType talk about `base OIDs' of MIB modules. What is this? The MODULE-IDENTITY node? E.g. what is the `base OID' of IF-MIB? The DESCRIPTION of pmCapabilitiesEntry talks about some pmCapabilitiesRestrict* objects, while their names are pmCapabilitiesModification*. Some terminology is used not very consequently and not explained clearly. Sections 5.2 and 5.3 introduce the term `script', while this mean `filter' and `action'. The term `address' is introduced in 5.1 but not used at other places, e.g. where "$1" is explained in 6.2.1 or in the pmElementTypeRegOIDPrefix DESCRIPTION. The grammar in section 6.1 containes weired quotes for the unary_operator and char rules. Section 6.2.1 contains the conditional sentence `...when the policy MIB module resides on the same system as the manages elements.' This conflicts with section 4 which says `These policies are executed on managed devices, where the objects live [...] and where operations on these objects will be performed. getstring() (section 6.2.2) returns a string without a length (probably NULL terminated). This means that no arbitrary octet strings (containing zero bytes) can be handled. Section 6.2.5 is named strcmp() but describes strncmp(). Accessor function names look quite arbitrary to me. Some use only lowercase letters, others are mixed. Some use `_', others don't. strcmp() is named after a well-known libc function, lc_strcmp() is not (strcasecmp()). What happens if "$1" appears in an action, but not in the filter? Examples of useful filter/action pairs should be added. From owner-snmpconf@seymour39.SNMP.COM Fri Sep 15 09:05:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19109 for ; Fri, 15 Sep 2000 09:05:26 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA18786 for snmpconf-outgoing; Fri, 15 Sep 2000 08:45:40 -0400 (EDT) Date: Fri, 15 Sep 2000 14:45:03 +0200 Message-Id: <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: <39C12367.10B285FF@riverstonenet.com> (message from Thippanna Hongal on Thu, 14 Sep 2000 14:13:43 -0500) Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Thippanna Hongal writes: Thippanna> Here is the list of requirement I did compile to associate Thippanna> time with the policies. Thanks for posting this summary. Let me try to rephrase your requirements to see whether I did understand you correctly: The requirement is to support two additional scheduling types. Both new scheduling types schedule time intervals, which means they create a set operation at the beginning of a time interval and at the end of the time interval. It is sufficient if the sets triggered by the scheduler modifies the same integer variable. However, it is necessary to be able to set two different values at the start and the end of the time interval. The first new scheduling type (A) specifies the time interval based on calendar time. The second new scheduling type (B) specifies the start point based on calendar time and the duration of the time interval. (Well, you actually wrote in your email that the second starts immediately when something (the schedTable entry?) is enabled and runs for the duration specified, but the proposed solution you described is not really consistent with this. Anyway, I will call this variation (B').) Is that summary of the requirements correct so far? Now lets look what we have right now in RFC 2591. I believe you can realize all schedules described above as follows with RFC 2591: (A) You create two oneshot schedules in the schedTable, one for the start time and one for the end time. (B) Similar to (A), you create two oneshot schedules in the schedTable, one for the start time and one for the end time. You simply let the manager calculate the end time by adding the time interval to the start time. (B') You generate a single oneshot schedule for the end time and once the manager has calculated the end time based on the current time. (An alternative would be a very slight modification to add a new scheduling type which is basically a periodic schedule which disables itself after the first scheduled event.) Now, from looking at the proposed solution, it looks like you are for some reason uncomfortable with what I have described above. Is it possible to clearly describe why the solutions outlined above do not work or are way too ugly in the snmpconf context? Can you provide examples to demonstrate your points? [There are many issues I have with the proposed solutions. But before discussing this in detail, I would first like to better understand what the problem really is. Maybe there are other solutions that fit better into the design of the current scheduler.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Sep 15 13:10:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22695 for ; Fri, 15 Sep 2000 13:10:56 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA24780 for snmpconf-outgoing; Fri, 15 Sep 2000 12:48:25 -0400 (EDT) Message-ID: <39C2540C.FB1E280@riverstonenet.com> Date: Fri, 15 Sep 2000 09:53:32 -0700 From: Thippanna Hongal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: disman@dorothy.peer.com Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> 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 Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal writes: > > Thippanna> Here is the list of requirement I did compile to associate > Thippanna> time with the policies. > > Thanks for posting this summary. Let me try to rephrase your > requirements to see whether I did understand you correctly: > > The requirement is to support two additional scheduling types. Both > new scheduling types schedule time intervals, which means they create > a set operation at the beginning of a time interval and at the end of > the time interval. The scheduler will operate in the startDateAndTime , and endDateAndTime. It triggers events at StartTime and at EndTime as specified in the schedTimeOfDay and uses masks schedMonth,schedDay, schedDayOfWeek enabling multiple schedules in the selected range of Dates. The picture shown will give better picture what I have in mind. 1. as understood startDateAndTime endDateAndTime |--------------------------------------------------------| T T. 2.as required startDateAndTime endDateAndTime |---|--|---d1---|--|---d2---|--|---d3---|--|---d4---|--|---| T T' T T' T T' T T' T T' T- Trigger indicating the Start of policy T' - Trigger indicating the End of Policy dn- Day n, n = 0..31 > It is sufficient if the sets triggered by the > scheduler modifies the same integer variable. However, it is necessary > to be able to set two different values at the start and the end of the > time interval. > > The first new scheduling type (A) specifies the time interval based on > calendar time. The second new scheduling type (B) specifies the start > point based on calendar time and the duration of the time interval. > > (Well, you actually wrote in your email that the second starts > immediately when something (the schedTable entry?) is enabled and runs > for the duration specified, but the proposed solution you described is > not really consistent with this. Anyway, I will call this variation > (B').) I mean the periodic scheduler time tick start as soon as the schedTable entry is enabled. I have no plans to associate this with Calendar Entry to start with. I am exactly looking for: B' > (An alternative would be a very slight modification to add > a new scheduling type which is basically a periodic schedule > which disables itself after the first scheduled event.) I will again look into the proposed solution, if I need to fix it. > > > Is that summary of the requirements correct so far? > > Now lets look what we have right now in RFC 2591. I believe you can > realize all schedules described above as follows with RFC 2591: > > (A) You create two oneshot schedules in the schedTable, one for > the start time and one for the end time. > > (B) Similar to (A), you create two oneshot schedules in the > schedTable, one for the start time and one for the end time. You > simply let the manager calculate the end time by adding the time > interval to the start time. > > (B') You generate a single oneshot schedule for the end time and once > the manager has calculated the end time based on the current > time. (An alternative would be a very slight modification to add > a new scheduling type which is basically a periodic schedule > which disables itself after the first scheduled event.) > > Now, from looking at the proposed solution, it looks like you are for > some reason uncomfortable with what I have described above. Is it > possible to clearly describe why the solutions outlined above do not > work or are way too ugly in the snmpconf context? Can you provide > examples to demonstrate your points? > > [There are many issues I have with the proposed solutions. But before > discussing this in detail, I would first like to better understand > what the problem really is. Maybe there are other solutions that fit > better into the design of the current scheduler.] > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Mon Sep 18 10:56:14 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10057 for ; Mon, 18 Sep 2000 10:56:13 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA02694 for snmpconf-outgoing; Mon, 18 Sep 2000 10:29:25 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 18 Sep 2000 10:32:24 -0400 Subject: FW: snmpconf SNMPCONF Interim Meeting Announcement From: Jon Saperia To: snmpconf , Terri Brogdon 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 Folks, Thought you would be interested in this. I just spoke with Terri and she is going to call the hotel to see if the main reservations center can get updated so that those on the announce list only who may not see this message can get the reservation even if not 8am-5pm EST Mon-Fri. In the interim try 8am-5pm EST Mon-Fri. /jon ---------- > From: Terri Brogdon > Date: Mon, 18 Sep 2000 09:57:06 -0400 (EDT) > To: Dan Romascanu > Cc: "'saperia@mediaone.net'" > Subject: RE: snmpconf SNMPCONF Interim Meeting Announcement > > Dear Dan, > > I'm sorry, please try the number again, but between 8am-5pm EST Mon-Fri. > The in-house reservation office is closed on weekends and the phone rolls > over to the Hilton Reservations Center. The number and information is > correct. I did call to make sure and they do have the room rate > information when you call back. > > Please let me know if you need anything further. > > Regards, > > Terri Brogdon > > > > On Sun, 17 Sep 2000, Dan Romascanu wrote: > >> Terri, Jon, >> >> I just called the number that you indicate in your e-mail - which is BTW the >> Hilton Resevations Center and not the 'hotel directly'. The problem is that >> they have no information about an 'SNMP Conference' and they could not make >> a reservation at the rate indicated in the mail. >> >> Was I too fast to try to book a room, or is there some other >> mis-understanding? Can you please clarify and inform the list? >> >> Thanks and Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: Jon Saperia [SMTP:saperia@mediaone.net] >>> Sent: Wed September 13 2000 21:58 >>> To: snmpconf; Bert Wijnen; Randy Bush; iesg-secretary@ietf.org >>> Subject: snmpconf SNMPCONF Interim Meeting Announcement >>> >>> The SNMPCONF working group will hold and interim meeting on Thursday and >>> Friday October 26 and 27, 2000. >>> >>> MEETING TIMES: >>> >>> The meeting will be from 9:00am to 5:30pm on Thursday October 26 and >>> from 9:00am to 4:00pm on Friday October 27. Please be sure to keep these >>> times in mind when making travel arrangements so that we can make progress >>> during all of the posted meeting time. >>> >>> LOCATION: >>> >>> The meeting hosted by SNMP Research, Inc. will take place in Knoxville, >>> TN. >>> >>> AIRPORT: >>> >>> The local airport is McGhee Tyson Airport (TYS) in Knoxville, >>> Tennessee. >>> For those seeking additional information please visit: >>> >>> http://www.tys.org/ >>> >>> HOTEL: >>> >>> A special rate has been arranged at the Downtown Hilton, >>> 501 W. Church Ave., Knoxville, TN 37902, 1-865-523- >>> 2300. The Hilton is within walking distance (1 mile) of the >>> meeting site. For reservations, call the hotel directly toll >>> free at 1-877-644-5866. Make sure you state that you are >>> with the "SNMP Conference" to get the $76 conference >>> rate for a single or double room. The hotel does not >>> provide free shuttle service from the airport, but there are >>> taxis and shuttle services available at the airport to the >>> downtown area. It is 14.1 miles from the airport to the >>> Hilton if you rent a car. Parking is available at the hotel >>> and meeting site. >>> >>> Terri Brogdon is working with Jeff Case on the logistics for >>> the October 26-27 meeting scheduled in Knoxville, TN. >>> The meetings will be held at the University of Tennessee >>> campus. Room location is still to be determined. >>> >>> If you have any questions regarding travel to Knoxville, >>> please contact Terri directly at tbrogdon@snmp.com or by >>> phone 1-865-573-1434. >>> >>> PRELIMINARY AGENDA: >>> >>> Brief review of current status and schedule >>> Review of current issues list, items that are closed and open >>> Work on items on issues list that are not yet resolved >>> Review of revised BCP Document >>> Review of DiffServ Policy MIB (depending on updates in the >>> DiffServ WG) >>> Other topics as proposed on the list. >>> Next steps and preparation for the next IETF. >>> >>> Thanks to Terri and Jeff for getting this organized. >>> >>> /Jon >> > > +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* > Come see us at > Networld+Interop in Atlanta, GA, 9/26-28/00 > Booth #6169 > > Terri Brogdon SNMP Research International Phone 1 865 579 3311 > tbrogdon@snmp.com 3001 Kimberlin Heights Road Fax 1 865 579 6565 > Knoxville, Tennessee 37920 http://www.snmp.com > +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* > From owner-snmpconf@seymour39.SNMP.COM Mon Sep 18 11:34:26 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11554 for ; Mon, 18 Sep 2000 11:34:25 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id LAA04115 for snmpconf-outgoing; Mon, 18 Sep 2000 11:18:25 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 18 Sep 2000 11:21:22 -0400 Subject: snmpconf Tally for the interim meeting 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 A couple of people asked for an RSVP address for the interim meeting. I am interested to know if possible who has plans to attend. If you want to just post to the snmpconf list, ok. If you prefer you can send me a message instead. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Mon Sep 18 12:26:57 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13633 for ; Mon, 18 Sep 2000 12:26:56 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA05486 for snmpconf-outgoing; Mon, 18 Sep 2000 12:06:57 -0400 (EDT) Message-ID: <39C63CE6.B6D9213B@mediaone.net> Date: Mon, 18 Sep 2000 12:03:50 -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 Tally for the interim meeting 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 plan to attend. dbh Jon Saperia wrote: > > A couple of people asked for an RSVP address for the interim meeting. I am > interested to know if possible who has plans to attend. > > If you want to just post to the snmpconf list, ok. If you prefer you can > send me a message instead. > > Thanks > /jon -- --- David Harrington Network Management Standards Architect 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 Sep 18 13:11:15 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15045 for ; Mon, 18 Sep 2000 13:11:15 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA06590 for snmpconf-outgoing; Mon, 18 Sep 2000 12:51:52 -0400 (EDT) Message-Id: <200009181651.MAA06574@seymour39.SNMP.COM> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 18 Sep 2000 12:44:58 -0400 To: snmpconf@snmp.com X-Sybari-Space: 00000000 00000000 00000000 From: "Kwok-Ho Chan" Subject: Re: snmpconf Tally for the interim meeting Cc: "Kwok-Ho Chan" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon: I am planning to attend. -- Kwok Ho Chan, Nortel Networks -- At 11:21 AM 9/18/00 -0400, you wrote: >A couple of people asked for an RSVP address for the interim meeting. I am >interested to know if possible who has plans to attend. > >If you want to just post to the snmpconf list, ok. If you prefer you can >send me a message instead. > >Thanks >/jon > From owner-snmpconf@seymour39.SNMP.COM Mon Sep 18 13:23:59 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15429 for ; Mon, 18 Sep 2000 13:23:59 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA06943 for snmpconf-outgoing; Mon, 18 Sep 2000 13:02:40 -0400 (EDT) Message-ID: <39C631CC.E6CC8D21@riverstonenet.com> Date: Mon, 18 Sep 2000 10:16:28 -0500 From: Thippanna Hongal Organization: Riverstone Network Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Tally for the interim meeting 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 plan to attend > A couple of people asked for an RSVP address for the interim meeting. I am > interested to know if possible who has plans to attend. > > If you want to just post to the snmpconf list, ok. If you prefer you can > send me a message instead. > > Thanks > /jon -- thanks hongal From owner-snmpconf@seymour39.SNMP.COM Mon Sep 18 14:03:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16263 for ; Mon, 18 Sep 2000 14:03:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA00385 for snmpconf-outgoing; Mon, 18 Sep 2000 13:44:04 -0400 (EDT) From: Jeff Case Date: Mon, 18 Sep 2000 13:43:48 -0400 (EDT) Message-Id: <200009181743.NAA25617@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf Tally for the interim meeting Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >If you want to just post to the snmpconf list, ok. If you prefer you can >send me a message instead. i'll probably be there best, jdc From owner-snmpconf@seymour39.SNMP.COM Tue Sep 19 02:34:02 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09852 for ; Tue, 19 Sep 2000 02:34:02 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA02206 for snmpconf-outgoing; Tue, 19 Sep 2000 02:15:57 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 19 Sep 2000 02:18:50 -0400 Subject: snmpconf Hotel Reseravations 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 a follow up from earlier. It is now possible to make reservations during times other than the 8am-5pm EST Mon-Fri times. Please do be sure to use the phone number in the original message. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 20 04:53:37 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16697 for ; Wed, 20 Sep 2000 04:53:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id EAA21420 for snmpconf-outgoing; Wed, 20 Sep 2000 04:34:43 -0400 (EDT) Message-ID: <39C873EC.3F0639DF@nextbeacon.com> Date: Wed, 20 Sep 2000 01:23:08 -0700 From: Steve Waldbusser X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: Comments on draft-ietf-snmpconf-pm-02 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 Frank, Thanks for the questions and feedback. My comments are inline. Frank Strauss wrote: > > Several *Index object types have integer range restrictions > (0..65535). Why at all? Why 64k? 2 reasons: 1) SMICng requires range restrictions on index objects. If I didn't put them there people would complain that it didn't compile cleanly. Sometimes it's better to just submit :-) 2) It's useful to declare that 0 is a valid value. Otherwise this would be an FAQ. Unfortunately, when you put in a range, sometimes you have to make an arbitrary decision on one end of the range. That's what the 65535 represents (a number larger than reasonably possible). One of the chief benefits of policy-based management is that it reduces the number of management decisions that need to be made (or in plain english, there won't be that many policies) , so a limit of 64K seems reasonable. > Why is pmPolicyFilter restricted to a maximum size of 65535 octets? > If there's a good reason for this size, why is pmPolicyAction not > restricted? Because the SMI restricts octet strings to 64K. It was my intent to be consistent with both objects but I missed policyAction. > Why is pmPolicyFilterMaxLatency of type Integer32 (signed) but restricted > to 0..2147483647? Why not just Unsigned32? Good idea. > What is the purpose of pmPolicyActionMaxLatency? At first sight, it > seems like an action is called exactly when a filter is evaluated being > true. Thus the action latency simply depends on pmPolicyFilterMaxLatency > and the result of the filter evaluation. This architecture allows the agent to implement them coupled (more obvious and simpler to implement) or decoupled (provides more scalability for larger systems). Where coupled means "if (filter) then (action)" Where decoupled means: Once every filterMaxLatency period Evaluate filter and keep a list of matching elements Once every actionMaxLatency period Evaluate action for every element currently in matching list Here's the argument for the decoupled mode: Usually we think of the actions being more complex and costly to run than the filters because they execute set requests, but sometimes the filter is more expensive than the action. For example: "Select the several trunk ports on a high-density access concentrator and configure the line protocol" In this case, I might be able to re-assert the correct line protocol every 30 seconds since it only touches several ports but I'd be unwilling to search through all ports more than once every 30 minutes. So, treat FilterMaxLatency as the maximum amount of time you are willing to wait for an element to be "discovered" as a target of a policy (or to be discarded if it no longer matches). Treat ActionMaxLatency as the maximum amount of time you are willing to leave an element without re-asserting the desired state. When implementing coupled mode, you simply run the if/then statement no less frequently than dictated by MIN(filterMaxLatency, actionMaxLatency). > The pmPolicyPrecedence DESCRIPTION confuses me completely. ;-) Furthermore, > it says `These values must be unique on the local policy system...' which > is difficult to ensure, I think. > > It is not possible to lookup pmPolicyTable rows by pmPolicyGroup, > since pmPolicyGroup is no INDEX element. However this might be useful. At the last interim meeting we agreed that each of the several proposals for grouping and priority (these objects were one) were flawed and that we were taking them off the table until we could get it right. > The pmPolicyMatches DESCRIPTION says `The number of policies ...' while > it means the number of elements. However, I do not see much value in > this object type. When a manager reads this variable, it does not know > at which stage in policy evaluation this value is current. Yes, it should say "The number of elements ...". Once filterMaxLatency time has passed, you know this value will be current. Regarding how valuable this is, this object is intended to: A) Be a first level Quality Control indicator for the policy author (did it match roughly the number of elements expected?) B) be helpful to a technician (how much effect will disabling this policy have?) > The pmElementTypeRegOIDPrefix has a DESCRIPTION that explains the > separation of the prefix and the instance identifying part, which > consists of N sub-identifiers. This is what I guess is > correct. However, the text describes that "$1" can be used in place of > any (single?!) decimal sub-identifier, e.g. in section 6.2.1. > > I think "$1" is not a good name, since there cannot be a "$2". How > about "*"? This is work in progress. One way is to have each subid be a separate parameter $X. The other way is for them to be one parameter and supply tools for breaking them apart. I have to try some real-world examples, but I think that $1, $2, $3, ... will be vastly preferable. > It's explicitly stated that `no state is remembered from the previous > invocation' in filters and actions. So: how can counters be evaluated > by a filter in a meaningful way? I'll answer "how" below, but first I'd like to discuss why we don't want to remember state - the reasons are complicated and vitally important. In this discussion, let's say that we have 3 policies (1-3) and 5 elements (A-E). A particular execution context would be a pairing of one of each (policy 2 on element D is 2D). In the most obvious case, we would evaluate 1A, 1B, ..., 1E, 2A, ..., 2E, 3A, ..., 3F, one at a time and in order. However this might no always be the case. First of all, we want the scheduler to be free to execute these contexts in any order. This freedom provides simplicity and greater scalability because it can execute multiple policies in parallel or suspend a blocked execution while others continue. Therefore context 2C can't assume the previous invocation was context 2B. (This is the rationale for not using static variables). About the only thing we COULD rationally do is have context 2C keep state from the last execution of context 2C. Each combination of policy and element is a separate thread of execution, so we could use threads, but we don't want to have to support P*E threads (we must allow P*E to be a very large number, say P=100 and E=10,000). So threads are out. We could automatically remember the last state of all automatic (local) variables, but this could be a huge burden, especially considering that many scripts will have multiple local variables but few will need to remember any from invocation to invocation. However, there may be times that we need to remember state from one context to another. Here are 3 ways: (sorry for the shorthand) A) Scratchpad MIB: Sparse table with one read-create column scratchPadPolicyIndex Integer32, scratchPadElement RowPointer, scratchpadVariable Integer32, -- allows multiple vars per context scratchpadValue OCTET STRING -- read-create, -- the only accessible column INDEX { scratchpadPolicyIndex, scratchpadElementIndex, scratchpadVariable } scratchpadValue.policyIndex.elementIndex.variableIndex if for ifIndex #17, we retrieved inoctets = 49 and outoctets = 35 for policy #3, we could store: scratchpadValue.3.`ifIndex.17`.1 = 49 scratchpadValue.3.`ifIndex.17`.2 = 35 B) Scratchpad accessor function void setscratchpad(int varIndex, char *value) char *getscratchpad(int varIndex, char *value) This function implicitly knows the policyIndex and element and will store them internally associated with this context. varIndex lets you save multiple variables per context C) Counter specific accessor function int deltaValue(int counterValue) This accessor function remembers the countervalue last passed to it by this context and performs a delta with the last value, returning the delta. Finally, let's keep some rigor in our requirements analysis (i.e. a little skeptecism). I can't imagine a filter or action script making a meaningful policy-based decision based on the 'instantaneous' delta value derived from 2 counter values (whether they were collected 2 minutes apart or 2 hours apart). It seems that at least some smoothing is required. What type of policies would depend on traffic or error rates? What types of rates would they need? smoothed? peak? Where is the best place to get those rates? (another MIB perhaps?) > The DESCRIPTION of pmElementTypeRegName says it's a `description'. > I guess it should be a `name'. I think you're right. > The MIB module contains various comments. This is no good idea, since > this information is not accessible. Important information should be > places in DESCRIPTIONs. Unimportent information should be removed. Well, the way it is now it is best for someone reading the MIB (and admittedly leaves some high-level stuff out for someone reading MIB objects through a MIB browser). Personally I think the latter is a dying breed. We can: 1. Leave it how it is. 2. Move it into the table description 3. Duplicate it into both comment and table description I don't care that much - let's see what the consensus is. > The pmCapabilitiesTable represents a new way to express agent > capabilities, but with a limited scope. I think it is not a good idea. Agent capabilities describes the capabilities of the instrumentation (i.e. SNMP Agent), is static, and is not accessible by SNMP retrievals. The capabilities describe the capabilities of the managed system, they are dynamic, and they are accessible by SNMP retrievals (as well as by the capMatch accessor function). In particular, you need this functionality if you want your policy to know if diffserv is currently supported by the card plugged into slot #3. Jon wrote the current iteration of the capabilities table so I'll let him field your questions about it. Regarding the rest of your valuable feedback below, I'll fix those items in the next draft. > Some terminology is used not very consequently and not explained > clearly. Sections 5.2 and 5.3 introduce the term `script', while this > mean `filter' and `action'. The term `address' is introduced in 5.1 > but not used at other places, e.g. where "$1" is explained in 6.2.1 > or in the pmElementTypeRegOIDPrefix DESCRIPTION. > > The grammar in section 6.1 containes weired quotes for the > unary_operator and char rules. > > Section 6.2.1 contains the conditional sentence `...when the policy > MIB module resides on the same system as the manages elements.' This > conflicts with section 4 which says `These policies are executed on > managed devices, where the objects live [...] and where operations on > these objects will be performed. > > getstring() (section 6.2.2) returns a string without a length > (probably NULL terminated). This means that no arbitrary octet strings > (containing zero bytes) can be handled. > > Section 6.2.5 is named strcmp() but describes strncmp(). > > Accessor function names look quite arbitrary to me. Some use only > lowercase letters, others are mixed. Some use `_', others don't. > strcmp() is named after a well-known libc function, lc_strcmp() > is not (strcasecmp()). > > What happens if "$1" appears in an action, but not in the filter? > > Examples of useful filter/action pairs should be added. Thanks, Steve From owner-snmpconf@seymour39.SNMP.COM Wed Sep 20 05:13:16 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16809 for ; Wed, 20 Sep 2000 05:13:15 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id EAA21898 for snmpconf-outgoing; Wed, 20 Sep 2000 04:56:33 -0400 (EDT) Date: Wed, 20 Sep 2000 10:55:57 +0200 Message-Id: <200009200855.KAA04177@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com In-reply-to: <39C873EC.3F0639DF@nextbeacon.com> (message from Steve Waldbusser on Wed, 20 Sep 2000 01:23:08 -0700) Subject: Re: Comments on draft-ietf-snmpconf-pm-02 References: <39C873EC.3F0639DF@nextbeacon.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Steve> Frank Strauss wrote: >> Several *Index object types have integer range restrictions >> (0..65535). Why at all? Why 64k? >>>>> Steve Waldbusser writes: Steve> 2 reasons: Steve> 1) SMICng requires range restrictions on index objects. If I Steve> didn't put them there people would complain that it didn't Steve> compile cleanly. Sometimes it's better to just submit :-) The problem why SMICng complains is that you use Integer32 and negative values are certainly illegal in an INDEX. So the range restriction is indeed required (as long as you use Integer32). Steve> 2) It's useful to declare that 0 is a valid value. Otherwise Steve> this would be an FAQ. I think it is not useful to allow 0 as a valid value. Disallowing 0 has the advantage that you can have "pointers" to the index which may use 0 to point to a guaranteed non-existing row. This concept has been used successfully in various other MIBs. (In fact, introducing TCs once you need to have references is an even better approach, see the evolution of the IF-MIB.) Steve> Unfortunately, when you put in a range, sometimes you have to Steve> make an arbitrary decision on one end of the range. No. If you have no architectural reasons to limit the range, then you can always revert to the upper limit imposed by the data type you are using. So in this case, since you use Interger32, 2147483647 would be the right choice. So putting things together, these indexes should actually be defined as Integer32 (1..2147483647) or even Unsigned32 (1..4294967295), which is basically what the SPPI now uses to identify all the instances in PIBs. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Wed Sep 20 05:59:55 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17008 for ; Wed, 20 Sep 2000 05:59:54 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id FAA22742 for snmpconf-outgoing; Wed, 20 Sep 2000 05:44:08 -0400 (EDT) X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: snmpconf@snmp.com Subject: Re: Comments on draft-ietf-snmpconf-pm-02 References: <39C873EC.3F0639DF@nextbeacon.com> Date: 20 Sep 2000 11:43:31 +0200 In-Reply-To: Steve Waldbusser's message of "Wed, 20 Sep 2000 01:23:08 -0700" Message-ID: Lines: 173 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >> Several *Index object types have integer range restrictions >> (0..65535). Why at all? Why 64k? Steve> 2 reasons: Steve> 1) SMICng requires range restrictions on index objects. If I didn't Steve> put them there people would complain that it didn't compile Steve> cleanly. Sometimes it's better to just submit :-) Steve> 2) It's useful to declare that 0 is a valid value. Otherwise this Steve> would be an FAQ. I'd suggest using Unsigned32 without restrictions. The reason why you need range restrictions for Integer32 is that an index sub-identifier must not be negative. SMICng is doing right. Steve> Unfortunately, when you put in a range, sometimes you have to Steve> make an arbitrary decision on one end of the range. That's what Steve> the 65535 represents (a number larger than reasonably Steve> possible). Then you should specify the maximum value. Steve> One of the chief benefits of policy-based management is that it Steve> reduces the number of management decisions that need to be made Steve> (or in plain english, there won't be that many policies) , so a Steve> limit of 64K seems reasonable. Well, it seems just arbitrary to me. ;-) >> Why is pmPolicyFilter restricted to a maximum size of 65535 octets? >> If there's a good reason for this size, why is pmPolicyAction not >> restricted? Steve> Because the SMI restricts octet strings to 64K. It was my Steve> intent to be consistent with both objects but I missed Steve> policyAction. Yes. The SMI *is* already restricted to this size. See SNMPv2-SMI: -- OCTET STRINGs with a more restrictive size -- may also be used string-value OCTET STRING (SIZE (0..65535)), >> What is the purpose of pmPolicyActionMaxLatency? At first sight, it >> seems like an action is called exactly when a filter is evaluated being >> true. Thus the action latency simply depends on pmPolicyFilterMaxLatency >> and the result of the filter evaluation. Steve> This architecture allows the agent to implement them coupled (more Steve> obvious and simpler to implement) or decoupled (provides more Steve> scalability for larger systems). [...] Ok. I think, I understand these two ways of operation. There are significant differences. E.g. in the decoupled case, it might happen that a filter is evaluated true, then again false and the action gets never executed. How does a manager recognize, how the agent works? >> The pmPolicyMatches DESCRIPTION says `The number of policies ...' while >> it means the number of elements. However, I do not see much value in >> this object type. When a manager reads this variable, it does not know >> at which stage in policy evaluation this value is current. Steve> Yes, it should say "The number of elements ...". Steve> Once filterMaxLatency time has passed, you know this value will be Steve> current. May be a note should be added, that the agent must not update pmPolicyMatches for each row while it runs through the policy table. >> It's explicitly stated that `no state is remembered from the previous >> invocation' in filters and actions. So: how can counters be evaluated >> by a filter in a meaningful way? Steve> I'll answer "how" below, but first I'd like to discuss why we Steve> don't want to remember state - the reasons are complicated and Steve> vitally important. [...] Steve> About the only thing we COULD rationally do is have context 2C keep Steve> state from the last execution of context 2C. Yes. This is what you need for counter evaluation. Steve> Each combination of policy and element is a separate thread of Steve> execution, so we could use threads, but we don't want to have to Steve> support P*E threads (we must allow P*E to be a very large number, Steve> say P=100 and E=10,000). So threads are out. Well, let's say it's an implementation issue. Steve> We could automatically remember the last state of all automatic Steve> (local) variables, but this could be a huge burden, especially Steve> considering that many scripts will have multiple local variables but Steve> few will need to remember any from invocation to invocation. Steve> However, there may be times that we need to remember state from one Steve> context to another. Here are 3 ways: (sorry for the shorthand) Steve> A) Scratchpad MIB: [...] You are kidding!? ;-) Steve> B) Scratchpad accessor function [...] Sounds to be the most reasonable solution of these three proposals. Steve> C) Counter specific accessor function [...] Counters were just one example. Another one would be the detection of state changes, where states are represented by values of an enumeration type object. So this counter specific solution would not be generic enough, I guess. Steve> Finally, let's keep some rigor in our requirements analysis (i.e. a Steve> little skeptecism). I can't imagine a filter or action script making a Steve> meaningful policy-based decision based on the 'instantaneous' delta Steve> value derived from 2 counter values (whether they were collected 2 Steve> minutes apart or 2 hours apart). It seems that at least some smoothing Steve> is required. Yes. I can easily imagine policies that take actions when too many errors occur. This means you need guaranteed time deltas or some implicit evaluation (in case of counters). Steve> What type of policies would depend on traffic or error rates? Policies that limit an ISP customers traffic volume per days. Policies that adapt routing for `gold' customers in case of many errors on the cheaper routes. Steve> What types of rates would they need? smoothed? peak? Well, every computed rate is `smoothed' somehow. What people - well at least I ;-) - would expect (except from discontinuities and wraps) is: value-of-this-eval - value-of-last-eval value = --------------------------------------- this-time - last-time Steve> Where is the best place to get those rates? (another MIB perhaps?) My assumption is: by reading from the relevant MIB objects and computing in the filter script using some kind of inter-evaluation persistent data (script variables or accessor functions?). >> The pmCapabilitiesTable represents a new way to express agent >> capabilities, but with a limited scope. I think it is not a good idea. Steve> Agent capabilities describes the capabilities of the instrumentation Steve> (i.e. SNMP Agent), is static, and is not accessible by SNMP Steve> retrievals. Steve> The capabilities describe the capabilities of the managed system, they Steve> are dynamic, and they are accessible by SNMP retrievals (as well as by Steve> the capMatch accessor function). Steve> In particular, you need this functionality if you want your policy Steve> to know if diffserv is currently supported by the card plugged into Steve> slot #3. Steve> Jon wrote the current iteration of the capabilities table so I'll let Steve> him field your questions about it. I agree that a way to retrieve agent capabilities by SNMP is a good thing. But I don't think it's a good idea to do this just in the PM context. From owner-snmpconf@seymour39.SNMP.COM Wed Sep 20 10:23:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23800 for ; Wed, 20 Sep 2000 10:23:44 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA29860 for snmpconf-outgoing; Wed, 20 Sep 2000 10:07:04 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 20 Sep 2000 10:10:07 -0400 Subject: snmpconf Capabilities Question From: Jon Saperia To: Message-ID: In-Reply-To: <39C873EC.3F0639DF@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 09/20/2000 4:23 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote: > Agent capabilities describes the capabilities of the instrumentation > (i.e. SNMP Agent), is static, and is not accessible by SNMP > retrievals. > > The capabilities describe the capabilities of the managed system, they > are dynamic, and they are accessible by SNMP retrievals (as well as by > the capMatch accessor function). > > In particular, you need this functionality if you want your policy > to know if diffserv is currently supported by the card plugged into > slot #3. > > Jon wrote the current iteration of the capabilities table so I'll let > him field your questions about it. Frank, this is a response to your excellent comments to the PM module. I have created a new subject line so that everyone does not have to read all of the other comments. The short answer is that Steve said it well. I have more detail below. The capabilities that we use here are not the same thing as what people have come to understand as capabilities in the AGENT-CAPABILITIES sense. Nor could this be accomplished with the sysORTable. A much richer set of conditions needed expression than either of these mechanisms allowed. There were some questions posed by Andrew Smith some months ago on this list that led to the current capabilities table in the current form. What the capabilities table is designed to do is express what a 'system' not an agent can do. It is also designed to allow the system to express restrictions as well. For example, if I had a policy that required that parameters be set at a specific value and the system did not support values in that range, this could be determined via this table. Please also note that these restrictions need not be static, that is to say that I can imagine cases where restrictions might be temporary or change as new software is added or removed from the system. For example, we need these capabilities to express: 1. Mechanism specific abilities such as queuing methods supported in the case of DiffServ or Encapsulating Security Protocol in the case of security. These objects may not always be visible at the OID level. 2. Restrictions, or or enhancements to basic capabilities. For example if a standard supported mechanisms 1, 2, and 3 and a vendor had a version that supported their own mechanism type 4, this would be the way for the system to 'advertise' this ability. This would be the way that a policy management application would come to know that a system had implementation-specific enhancements (or restrictions) Once again, these abilities are not always going to be static and values in this table could change. Hope this helps. /jon I have attached the exchange between Andrew and myself on this topic. It was sent to the list on 6/27 so it may have faded from our collective memory. :-) >> 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 Wed Sep 20 11:27:59 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25006 for ; Wed, 20 Sep 2000 11:27:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA02789 for snmpconf-outgoing; Wed, 20 Sep 2000 11:11:41 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 20 Sep 2000 11:14:50 -0400 Subject: snmpconf Re: I-D in configsnmp From: Jon Saperia To: Ehab Al-Shaer , Jon Saperia , snmpconf Message-ID: In-Reply-To: <014101c0229d$ecc335c0$4aa2c08c@cs.depaul.edu> 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 09/19/2000 8:58 PM, Ehab Al-Shaer at ehab@cs.depaul.edu wrote: > 1. in P.9, "if polling would not scale, consider using notification for > reporting the old and new checksum objects". I am wondering based on what this > notifications are generated? is it based on time or event-triggered? I think > you meant event-triggered based on changes which means a notification will be > sent everytime a change is performed on an object. > > Thank you > > -Ehab > > Ehab, I have taken the liberty of forwarding this to the SNMPCONF list since it relates to the BCP. Ehab, this particular sentence perhaps needs to be reworded for clarity. Event based in this context means that when the configuration is changed, a notification will be sent. So we are in agreement if the object is pointed to a single MIB Object. In the case of configuration, that would not be very good. There are several techniques for dealing with this. One is a notification any time the configuration in a branch of the tree changes such as routing parameters for a peer group. The notification can contain the entire row that changed in many case. As with all notifications (and MIB Objects) they should be expressed at the right level of abstraction, a point we hope to successfully make in the BCP. What we mean by this is if you created a notification every time the output queue depth changed on an interface, there would be quite a problem with too many notifications. Bottom line, we are saying the same thing. Mike and I need to fix the words though. /jon From owner-snmpconf@seymour39.SNMP.COM Wed Sep 20 13:22:31 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28266 for ; Wed, 20 Sep 2000 13:22:31 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA06825 for snmpconf-outgoing; Wed, 20 Sep 2000 13:02:21 -0400 (EDT) X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: snmpconf@snmp.com Subject: Re: snmpconf Capabilities Question References: <39C873EC.3F0639DF@nextbeacon.com> Date: 20 Sep 2000 18:58:24 +0200 In-Reply-To: Jon Saperia's message of "20 Sep 2000 16:09:14 +0200" Message-ID: Lines: 17 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Hi! Thanks, Jon, for the detailed answer! I think, do understand that the capabilities handled by the PM MIB are different from what the (broken) AC concept can do. But I'm convinced that it's not a good idea to do what the pmCapabilitiesTable does in the current way and scope. The basic reason for my scepticism: Policy management per se as represented by the PM MIB should be independent from domains and mechanisms (as defined in the diffserv I-D). [I'll be on vacation from now on until the end of this month. So I'll probably not be able to follow this list during the next days.] Frank From owner-snmpconf@seymour39.SNMP.COM Thu Sep 21 07:51:21 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03242 for ; Thu, 21 Sep 2000 07:51:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA14812 for snmpconf-outgoing; Thu, 21 Sep 2000 07:33:44 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 21 Sep 2000 07:36:50 -0400 Subject: Re: snmpconf Capabilities Question 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 09/20/2000 12:58 PM, Frank Strauss at strauss@ibr.cs.tu-bs.de wrote: > Hi! > > Thanks, Jon, for the detailed answer! > > I think, do understand that the capabilities handled by the PM MIB are > different from what the (broken) AC concept can do. But I'm convinced > that it's not a good idea to do what the pmCapabilitiesTable does in > the current way and scope. > > The basic reason for my scepticism: Policy management per se as > represented by the PM MIB should be independent from domains and > mechanisms (as defined in the diffserv I-D). > We very much agree. The policy module is at a layer of abstraction above the mechanism and implementation-specific details. It is independent, that is why the mechanism specific MIB Modules (or their equivalent objects in other MIB Modules) must have their capabilities registered into the Policy MIB Module. The capabilities are far from the details which are below the level of the Policy MIB Module. To use your DiffServ example, the base OID of the DiffServ objects is all that would be in the capabilities table. Enhancements or restrictions would also be registered. This avoids the problem of the manager having to 'poke' around the entire device for information such as does this device support DiffServ and what are its restrictions. The capabilities table is a list of pointers to the details, not the details. The manager must know what the 'capabilities' of the system are to efficiently send policies that are relevant to managed devices. Otherwise all policies would be sent to all devices, far from efficient. The mechanism and implementation specifics are dealt with in modules outside of the Policy MIB Module as in the case with our Policy MIB Module (or its equivalent objects if integrated into the current DiffServ Module). > [I'll be on vacation from now on until the end of this month. So I'll > probably not be able to follow this list during the next days.] > have a good vacation /jon From owner-snmpconf@seymour39.SNMP.COM Thu Sep 21 10:25:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06307 for ; Thu, 21 Sep 2000 10:25:38 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA19169 for snmpconf-outgoing; Thu, 21 Sep 2000 10:09:25 -0400 (EDT) Date: Thu, 21 Sep 2000 16:08:48 +0200 Message-Id: <200009211408.QAA08282@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: <39C2540C.FB1E280@riverstonenet.com> (message from Thippanna Hongal on Fri, 15 Sep 2000 09:53:32 -0700) Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> <39C2540C.FB1E280@riverstonenet.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Thippanna Hongal writes: Thippanna> The scheduler will operate in the startDateAndTime , and Thippanna> endDateAndTime. It triggers events at StartTime and at Thippanna> EndTime as specified in the schedTimeOfDay and uses masks Thippanna> schedMonth,schedDay, schedDayOfWeek enabling multiple Thippanna> schedules in the selected range of Dates. The picture Thippanna> shown will give better picture what I have in mind. [...] Let me check whether I understand what you were saying. You want to have a time interval schedule (defined by a start and an end event) and in addition another time interval schedule which defines the lifetime of the first time interval schedule. In other words, with RFC 2591, you would have two rows, one for the start and one for the end event of the first time interval. You would have four additional rows to turn the first two rows on and off (two rows to turn the other two rows on and two rows to turn the other two rows off). [If there were a mechanism to set multiple variables or to have multiple values, then it would be possible to reduce the total number of rows I think.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Sep 22 06:43:28 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04931 for ; Fri, 22 Sep 2000 06:43:28 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA01330 for snmpconf-outgoing; Fri, 22 Sep 2000 06:27:03 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 22 Sep 2000 06:30:14 -0400 Subject: Re: snmpconf Schedule Requirements From: Jon Saperia To: Juergen Schoenwaelder , CC: Message-ID: In-Reply-To: <200009211408.QAA08282@henkell.ibr.cs.tu-bs.de> 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 09/21/2000 10:08 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > [If there were a mechanism to set multiple variables or to have > multiple values, then it would be possible to reduce the total > number of rows I think.] Juergen, I do not want to speak for Hongal, but on reading your reply, I too was wondering if we may have ended up with too many rows. Without limiting Hongal's other proposal points I would like to see if we can do a simple duration schedule in one row. Hongal, if you had intended this and I misread, sorry. I see this duration type schedule as having a start time and a duration. Without changing the flexibility of the other items proposed, can we have this simple case? It would have a schedType of duration and a new object, duration would indicate how long the policy was to be in effect. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Sep 22 07:18:02 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05587 for ; Fri, 22 Sep 2000 07:18:02 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id HAA02010 for snmpconf-outgoing; Fri, 22 Sep 2000 07:03:21 -0400 (EDT) Date: Fri, 22 Sep 2000 13:02:06 +0200 Message-Id: <200009221102.NAA03987@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: (message from Jon Saperia on Fri, 22 Sep 2000 06:30:14 -0400) Subject: Re: snmpconf Schedule Requirements References: Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Jon Saperia writes: Jon> Juergen, I do not want to speak for Hongal, but on reading your Jon> reply, I too was wondering if we may have ended up with too many Jon> rows. Jon, I am currently just trying to understand what the additional requirements boil down. I just wanted to figure out what Hongal was asking for, whether it is doable with the current RFC 2591 and what the implications are. Jon> Without limiting Hongal's other proposal points I would like to Jon> see if we can do a simple duration schedule in one row. So your requirements seem to be less than Hongal's requirements. Jon> I see this duration type schedule as having a start time and a Jon> duration. Jon> It would have a schedType of duration and a new object, duration Jon> would indicate how long the policy was to be in effect. I think you also need to have another value which you set on the end of the time interval, right? We probably also need to document the behaviour in some corner cases (e.g. the start time triggers again before the previous start time trigger + duration, or the behaviour in case of time transitions). Jon> Without changing the flexibility of the other items proposed, can Jon> we have this simple case? The DISMAN WG has to make this decision. So please post your thoughts on this proposed RFC 2591 extension. Personally, I am especially interested in the opinion of people who have already implemented RFC 2591. Randy, does it make sense to put out a deadline for people to raise their views so that we actually get to a decision in the near future? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Fri Sep 22 10:48:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15900 for ; Fri, 22 Sep 2000 10:48:12 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id KAA07865 for snmpconf-outgoing; Fri, 22 Sep 2000 10:27:52 -0400 (EDT) X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: snmpconf@snmp.com Subject: Re: snmpconf Capabilities Question References: Date: 22 Sep 2000 16:27:16 +0200 In-Reply-To: Jon Saperia's message of "Thu, 21 Sep 2000 07:36:50 -0400" Message-ID: Lines: 29 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >> The basic reason for my scepticism: Policy management per se as >> represented by the PM MIB should be independent from domains and >> mechanisms (as defined in the diffserv I-D). Jon> We very much agree. The policy module is at a layer of Jon> abstraction above the mechanism and implementation-specific Jon> details. It is independent, that is why the mechanism specific Jon> MIB Modules (or their equivalent objects in other MIB Modules) Jon> must have their capabilities registered into the Policy MIB Jon> Module. The capabilities are far from the details which are below Jon> the level of the Policy MIB Module. To use your DiffServ example, Jon> the base OID of the DiffServ objects is all that would be in the Jon> capabilities table. Enhancements or restrictions would also be Jon> registered. This avoids the problem of the manager having to Jon> 'poke' around the entire device for information such as does this Jon> device support DiffServ and what are its restrictions. The Jon> capabilities table is a list of pointers to the details, not the Jon> details. Yes, but it *is* domain specific knowledge. Two questions: 1. What is a `base OID' of a MIB (or of the DiffServ objects)? 2. Who or what has to register capabilities? - Is it the PM MIB sub-agent itself or has it to provide an interface that allows other sub-agents to register their capabilities? The latter is the only way to keep the PM MIB sub-agent independent from domains and mechanisms, but it is not described at all in the document. From owner-snmpconf@seymour39.SNMP.COM Fri Sep 22 11:18:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17294 for ; Fri, 22 Sep 2000 11:18:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA09205 for snmpconf-outgoing; Fri, 22 Sep 2000 11:02:56 -0400 (EDT) From: Jeff Case Date: Fri, 22 Sep 2000 11:02:53 -0400 (EDT) Message-Id: <200009221502.LAA13706@seymour4.snmp.com> To: snmpconf@snmp.com Subject: Re: snmpconf Capabilities Question Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >Yes, but it *is* domain specific knowledge. Two questions: we agree, of course it is now, to your questions >1. What is a `base OID' of a MIB (or of the DiffServ objects)? this is whatever oid is agreed (such as one specified anywhere in an appropriate informational module via the usual mechanisms) that "everybody" understands to represent the modeled capability it does not matter what the value is, so long as all implementations of managers and agents use the same values for the same capabilities or sets of capabilties >2. Who or what has to register capabilities? - Is it the PM MIB sub-agent > itself or has it to provide an interface that allows other sub-agents > to register their capabilities? > The latter is the only way to keep the PM MIB sub-agent independent > from domains and mechanisms, but it is not described at all in the > document. the agent has to do it the specification is appropriately silent about the implementation details as there is no requirement that this be implemented as a master agent/ subagent architecture, as a monolithic agent, or otherwise -- that does not belong in this specification however, the way that you cite is one possible implementation mechanism that i would elect to use with EMANATE and could be done with agent-x and could also be done with a monolithic agent i suspect you will agree that while we do not want to require any particular implementation strategy in a mib document, we want to avoid specifying something that is impossible to implement and, given that there are at least 3 ways to implement the mib using tools that are widely available today, i think we are in pretty good shape in that regard regards, jdc From owner-snmpconf@seymour39.SNMP.COM Sat Sep 23 09:26:55 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21545 for ; Sat, 23 Sep 2000 09:26:54 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA22285 for snmpconf-outgoing; Sat, 23 Sep 2000 09:09:57 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 23 Sep 2000 09:12:35 -0400 Subject: Re: snmpconf Schedule Requirements From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009221102.NAA03987@henkell.ibr.cs.tu-bs.de> 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 09/22/2000 7:02 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > >>>>>> Jon Saperia writes: > > Jon> Juergen, I do not want to speak for Hongal, but on reading your > Jon> reply, I too was wondering if we may have ended up with too many > Jon> rows. > > Jon, > > I am currently just trying to understand what the additional > requirements boil down. I just wanted to figure out what Hongal was > asking for, whether it is doable with the current RFC 2591 and what > the implications are. > > Jon> Without limiting Hongal's other proposal points I would like to > Jon> see if we can do a simple duration schedule in one row. > > So your requirements seem to be less than Hongal's requirements. > Please do not interpret it that way at all. I was pointing to one of the requirements that Hongal put forward. Specifically to a schedule that starts at a specified time and runs for a fixed length of length of time. Hongel put forward others that are important as well. I would like to be able to say start at a time and run for 90 mins. Or Under condition A run for 1 hour. I understand these are two different requests. > Jon> I see this duration type schedule as having a start time and a > Jon> duration. > > Jon> It would have a schedType of duration and a new object, duration > Jon> would indicate how long the policy was to be in effect. > > I think you also need to have another value which you set on the end > of the time interval, right? We probably also need to document the > behaviour in some corner cases (e.g. the start time triggers again > before the previous start time trigger + duration, or the behaviour > in case of time transitions). > In the types of schedule that I have described which are a subset of those Hongal proposes, I do not need an end time since that is implicit in duration. My subset should not be interpreted as suggesting Hongals other points are not important, only that I wanted to emphasize issues of particular interest to me. /jon > From owner-snmpconf@seymour39.SNMP.COM Mon Sep 25 08:22:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01327 for ; Mon, 25 Sep 2000 08:22:32 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id IAA29802 for snmpconf-outgoing; Mon, 25 Sep 2000 08:11:12 -0400 (EDT) Message-Id: <200009251210.OAA07269@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Upcoming issues mail 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: <13750.969884205.1@y5m638.lmera.ericsson.se> Date: Mon, 25 Sep 2000 14:16:45 +0200 X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id IAA29797 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com X-MIME-Autoconverted: from 8bit to quoted-printable by seymour39.SNMP.COM id IAA29802 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA01327 Greetings, We need to get a list of issues on the table for discussion up to and during the upcoming interim meeting. These issues will follow this mail as quickly as I can get them assembled. 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 ECN #: 868 4144 SE-581 12 Linköping, Sweden http://linlab.ericsson.se/~epkpart From owner-snmpconf@seymour39.SNMP.COM Mon Sep 25 17:24:21 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14696 for ; Mon, 25 Sep 2000 17:24:20 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA29739 for snmpconf-outgoing; Mon, 25 Sep 2000 17:00:35 -0400 (EDT) From: Chee Yong Chan Message-Id: <200009252058.QAA08614@aura.research.bell-labs.com> Subject: snmpconf Overhead of running SNMP To: snmpconf@snmp.com Date: Mon, 25 Sep 2000 16:58:10 -0400 (EDT) Cc: cychan@research.bell-labs.com (Chee Yong Chan) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Hi, I would like to have an idea of the overheads incurred by running snmp on routers; for example, how much does processing mib queries slow down the routers? Thanks, Chee Yong. From owner-snmpconf@seymour39.SNMP.COM Tue Sep 26 04:33:37 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07775 for ; Tue, 26 Sep 2000 04:33:37 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id EAA23416 for snmpconf-outgoing; Tue, 26 Sep 2000 04:10:09 -0400 (EDT) Date: Tue, 26 Sep 2000 10:09:30 +0200 Message-Id: <200009260809.KAA25638@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: cychan@research.bell-labs.com In-reply-to: <200009252058.QAA08614@aura.research.bell-labs.com> (message from Chee Yong Chan on Mon, 25 Sep 2000 16:58:10 -0400 (EDT)) Subject: Re: snmpconf Overhead of running SNMP References: <200009252058.QAA08614@aura.research.bell-labs.com> Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com >>>>> Chee Yong Chan writes: Chee> I would like to have an idea of the overheads incurred by Chee> running snmp on routers; for example, how much does processing Chee> mib queries slow down the routers? The answer clearly depends on the design of the router and the software running on top of it. Routers which implement all the primary functions (such as routing ;-) in hardware will show virtually no performance degration of the primary function when processing SNMP requests. On the other hand, routers that are primarily driven by software may experience some performance hit, especially if the internal data organization requires to do non-trivial processing in order to process an SNMP request. In other words: It depends on how much time and money a product vendor invests in management interfaces (and a group of smart engineers). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-snmpconf@seymour39.SNMP.COM Tue Sep 26 06:12:30 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08339 for ; Tue, 26 Sep 2000 06:12:29 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA25529 for snmpconf-outgoing; Tue, 26 Sep 2000 05:52:18 -0400 (EDT) Message-Id: <200009260951.LAA19941@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Web-based archive reminder From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19200.969962275.1@y5m638.lmera.ericsson.se> Date: Tue, 26 Sep 2000 11:57:55 +0200 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Greetings, In discussing issues, it's useful to be able to point to mail that has been sent on a particular subject. I encourage you to refer to the messages under http://www.escribe.com/computing/snmpconf/index.html in discussions of issues. Cheers, David From owner-snmpconf@seymour39.SNMP.COM Tue Sep 26 06:19:35 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08383 for ; Tue, 26 Sep 2000 06:19:35 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id FAA25684 for snmpconf-outgoing; Tue, 26 Sep 2000 05:59:28 -0400 (EDT) Message-Id: <200009260958.LAA28898@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Issue 1 - Use of the Script MIB From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 X-Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19227.969962706.1@y5m638.lmera.ericsson.se> Date: Tue, 26 Sep 2000 12:05:06 +0200 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Greetings, (In all of the issues mail that follows, I have tried to be careful not to misrepresent anyone's views. I'm sure I'll be told if I do. :-)) A large source of discussion recently has been the extent to which we should leverage the Script MIB in our work. The issue basically is whether SNMPCONF should use its own scripting infrastructure or whether it should use the Script MIB instead. My interpretation of this is whether to use a specific or generic tool for the job. This issue is related to issue #2 (Split of filter and action into two objects), although I decided to make that a different discussion. Relevant pieces of mail have been: http://www.escribe.com/computing/snmpconf/m275.html and those in the same thread. Juergen Schoenwaelder has been a proponent of using the Script MIB within SNMPCONF. The argument is that the DISMAN group has tackled many of the issues that SNMPCONF is going to have to deal with if they don't use the Script MIB and that the fit of the Script MIB to SNMPCONF is fine. He has argued that the facilities needed as listed in the bullets below can be done in other ways or are not necessarily valuable. Steve Waldbusser has been a proponent of continuing to use an environment specific to the SNMPCONF work. Amongst other things, he has argued that the Script MIB is not a good fit since it is for generic scripted applications and the PM MIB execution environment is purpose-built for processing policy expressions. Further, he says that the PM MIB requires facilities that aren't in the Script MIB, allows things we need to disallow, and there are differences in the way parameter passing and scheduling need to be handled. One question which might be useful to get a feel for is whether readers believe it will make any difference in terms of implementation of the SNMPCONF work. That is, would use of the Script MIB mean that vendors are either encouraged or discouraged from implementing this? Please consider this issue and respond to the mailing list, even if it's just a "feeling". Cheers, David From owner-snmpconf@seymour39.SNMP.COM Tue Sep 26 06:27:01 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08462 for ; Tue, 26 Sep 2000 06:27:01 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA25860 for snmpconf-outgoing; Tue, 26 Sep 2000 06:07:25 -0400 (EDT) Message-Id: <200009261006.MAA08761@lmera.lmera.ericsson.se> To: snmpconf@snmp.com Subject: snmpconf Issue 2 - Split of filter and action into two objects From: David Partain X-Mailer: Proudly sent by nmh-1.0.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19334.969963181.1@y5m638.lmera.ericsson.se> Date: Tue, 26 Sep 2000 12:13:01 +0200 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Greetings, Some have argued that the split of filters and actions into two different MIB objects is not correct. This is related to issue 1. Again, http://www.escribe.com/computing/snmpconf/m275.html is a useful thread to look at. Juergen Schoenwaelder writes: "this level of granularity (two objects) will just turn out to be very impractical if you express real-world policies." Juergen Quittek argues in a similar fashion that "[the separation] is impractical because of the fine granularity. The problem is not only the separation of filters and actions but also the implied separate handling of each policy." Instead, the argument is that the filter/action pair should be exposed as a single MIB object and that the Script MIB could then be used to transport them. Others have argued that the split is very useful. Steve Waldbusser has given several reasons why he believes this is true, including that policy filters and actions are conceptually quite different and should be separate for modeling reasons. In adddition, he wrote: - Because all filter information is separate, the manager can inspect the filter and understand whether to download the policy to an agent - Because filter information is separate, the agent can schedule filter evaluation separately from action evaluation. - The filter expression is known to be idempotent, information that both manager and agent can use for optimization. - It is easier to re-use filter and action expressions when they are separate. Cheers, David From owner-snmpconf@seymour39.SNMP.COM Wed Sep 27 03:28:50 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06210 for ; Wed, 27 Sep 2000 03:28:50 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA06800 for snmpconf-outgoing; Wed, 27 Sep 2000 03:11:08 -0400 (EDT) Message-Id: <4.3.1.20000926234610.00abc270@mordor> X-Sender: mrm@mordor X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 27 Sep 2000 00:09:54 -0700 To: snmpconf@snmp.com, David.Partain@ericsson.com From: Mike MacFaden Subject: Re: snmpconf Upcoming issues mail In-Reply-To: <200009251210.OAA07269@lmera.lmera.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com At 02:16 PM 9/25/00 +0200, David Partain wrote: >We need to get a list of issues on the table for discussion >up to and during the upcoming interim meeting. These issues will >follow this mail as quickly as I can get them assembled. Things I'm not clear about... 1. General issue of being able to add user defined varbinds to standard notification varbinds, I'm leaning back towards stating this is not good to allow. 2. Issues/costs of implementing helper objects that track number of rows in a table in a table when one uses subagent technology. 3. Perceived usefulness of having an example low-tech mib in BCP to illustrate SNMP MIB Policy or should examples be tied to actual technology specific mib objects. 4. Very large OCTET STRING recommendations (ipsec) BCP recommendation needed. Options enumerated on ipsec mailing list. 5. Being able to backup a configuration using IETF standard MIBS remains problemmatic. Recommend a new standard mib to provide a means for extracting "configuration" off a device for backup. (ex: a table with a list of oids and values that make up the config regardless of mib as Jon mentioned) 6. Implementing configuration systems that scale often requires knowing the volume and rate of change in addition to the varbind list plus any mechanical RowStatus, RowPointer, etc objects. Should there be a standard mib for controlling configuration transactions to support a style similar to database transactions with commit/rollback two-phase commits, etc. would be one way to scale up implementations across a given device or device set. Regards, Mike MacFaden www.riverstonenet.com From owner-snmpconf@seymour39.SNMP.COM Wed Sep 27 13:46:05 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18665 for ; Wed, 27 Sep 2000 13:46:04 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id NAA26050 for snmpconf-outgoing; Wed, 27 Sep 2000 13:26:29 -0400 (EDT) Message-ID: <39D214DE.678E8C11@riverstonenet.com> Date: Wed, 27 Sep 2000 10:40:14 -0500 From: Thippanna Hongal Organization: Riverstone Networks Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf , "disman@dorothy.peer.com" Subject: snmpconf Upcoming issues mail 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 David >We need to get a list of issues on the table for discussion >up to and during the upcoming interim meeting. These issues will >follow this mail as quickly as I can get them assembled. 1. I did sent the requirement list for associating 'time' with policy table both to 'snmpconf' and 'disman' mailing list. This can be another issue to discuss. -- Thanks, hongal ------------------------------------------------------ Thippanna Hongal Software Engineer Tel(O):408 878 6562 Riverstone Networks Inc. 5200 Great America Parkway Santa Clara CA USA 95054 ------------------------------------------------------- From owner-snmpconf@seymour39.SNMP.COM Thu Sep 28 20:11:34 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05810 for ; Thu, 28 Sep 2000 20:11:33 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id TAA22922 for snmpconf-outgoing; Thu, 28 Sep 2000 19:54:48 -0400 (EDT) Message-ID: <39D3C169.3D38A181@riverstonenet.com> Date: Thu, 28 Sep 2000 17:08:41 -0500 From: Thippanna Hongal Organization: Riverstone Networks Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf Subject: snmpconf on vacation 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 all I will be on vacation from 29th September till 16th October, I will not be checking my mails. -- Thanks, hongal ------------------------------------------------------ Thippanna Hongal Software Engineer Tel(O):408 878 6562 Riverstone Networks Inc. 5200 Great America Parkway Santa Clara CA USA 95054 ------------------------------------------------------- From owner-snmpconf@seymour39.SNMP.COM Fri Sep 29 17:27:01 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07412 for ; Fri, 29 Sep 2000 17:27:01 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA01437 for snmpconf-outgoing; Fri, 29 Sep 2000 17:08:53 -0400 (EDT) Date: Fri, 29 Sep 2000 17:08:19 -0400 (EDT) From: Terri Brogdon To: snmpconf@snmp.com, Jon Saperia cc: Jeff Case Subject: snmpconf Knoxville Hotel for Working Group 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 Greetings, This is a reminder that a special rate has been arranged at the Downtown Hilton in Knoxville for the SNMPCONF Working Group which is scheduled for October 26-27. To make a reservation, call toll free to 1-877-644-5866. Ask for the "SNM" conference rate of $76 for a single or double room. The hotel address is 501 W. Church Ave., Knoxville, TN 37902, phone 1-865-523-2300. It is within walking distance (1 mile) of the meeting site. The hotel does not provide free shuttle service from the airport, but there is transporation available at the airport to the downtown area. It is 14.1 miles from the airport to the Hilton if you rent a car. Parking is available at the hotel and meeting site. If you have any trouble at all making your room reservations, please contact me and I will be more than glad to assist. A note on the meeting site and logistics will be sent in the near future. Best regards, Terri Brogdon Administrative Assistant to Jeff Case +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Terri Brogdon SNMP Research International Phone 1 865 579 3311 tbrogdon@snmp.com 3001 Kimberlin Heights Road Fax 1 865 579 6565 Knoxville, Tennessee 37920 http://www.snmp.com +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* From owner-snmpconf@seymour39.SNMP.COM Sat Sep 30 12:24:19 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29251 for ; Sat, 30 Sep 2000 12:24:19 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA19125 for snmpconf-outgoing; Sat, 30 Sep 2000 12:05:47 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 30 Sep 2000 12:09:12 -0400 Subject: snmpconf Re: Knoxville Hotel for Working Group From: Jon Saperia To: Terri Brogdon , CC: Jeff Case 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 09/29/2000 5:08 PM, Terri Brogdon at tbrogdon@snmp.com wrote: > Greetings, > > This is a reminder that a special rate has been arranged at the Downtown > Hilton in Knoxville for the SNMPCONF Working Group which is scheduled for > October 26-27. To make a reservation, call toll free to 1-877-644-5866. > Ask for the "SNM" conference rate of $76 for a single or double room. I tried again to make a reservation. After some difficulty they found it under "SNMP Conference Working Group". So if you have difficulty with try this. Apparently the only rooms that the national reservation service knows about are 'accessible' rooms for the 'physically challenged'. I was told to make the reservation and then as Terri to see if she can fix it. If you have not been able to make your reservation go ahead. Terri please let us all know if/when the rooms have been changed. /jon From owner-snmpconf@seymour39.SNMP.COM Sat Sep 30 22:58:58 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05100 for ; Sat, 30 Sep 2000 22:58:58 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id WAA22814 for snmpconf-outgoing; Sat, 30 Sep 2000 22:45:30 -0400 (EDT) Message-ID: <39D6A4D7.32990C8B@enterasys.com> Date: Sat, 30 Sep 2000 20:43:35 -0600 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 Re: Knoxville Hotel for Working Group 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, On Monday or Tuesday, I booked a room under the SNMP Conference at $76 with no problem. dbh Jon Saperia wrote: > > on 09/29/2000 5:08 PM, Terri Brogdon at tbrogdon@snmp.com wrote: > > > Greetings, > > > > This is a reminder that a special rate has been arranged at the Downtown > > Hilton in Knoxville for the SNMPCONF Working Group which is scheduled for > > October 26-27. To make a reservation, call toll free to 1-877-644-5866. > > Ask for the "SNM" conference rate of $76 for a single or double room. > > I tried again to make a reservation. After some difficulty they found it > under "SNMP Conference Working Group". So if you have difficulty with try > this. > > Apparently the only rooms that the national reservation service knows about > are 'accessible' rooms for the 'physically challenged'. I was told to make > the reservation and then as Terri to see if she can fix it. > > If you have not been able to make your reservation go ahead. > > Terri please let us all know if/when the rooms have been changed. > > /jon -- --- David Harrington Network Management Standards Architect dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA