From owner-snmpconf@seymour39.SNMP.COM Wed Apr 5 15:36:25 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15429 for ; Wed, 5 Apr 2000 15:36:24 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id PAA10357 for snmpconf-outgoing; Wed, 5 Apr 2000 15:17:01 -0400 (EDT) Message-Id: <200004051916.PAA10641@chmls06.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Wed, 05 Apr 2000 15:19:27 -0400 Subject: DRAFT - 47th IETF snmpconf WG Minutes Reported by Jon Saperia From: "Jon Saperia" To: snmpconf CC: saperia@mediaone.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Below is a draft of the working group minutes for our meetings at the 47th IETF. I have not yet submitted them to the secretariat and would appreciate any corrections from those in attendance by 5 P.M. eastern time Friday April 7th so that I can make edits and get the minutes submitted on time. Thanks /jon The snmpconf (SNMP Configuration) working group meet on Tuesday and Thursday March 28 and 30 during the 47th IETF. Below are the minutes of those meetings. Special thanks go to Carl Kalbfleish and Shawn Routhier for taking a comprehensive set of notes during these meetings. Please also note that the presentations briefly described in these notes will also be published in their original form. These notes are a bit longer than usual since much of the question and answer discussion was not removed from these minutes in order to capture as much of the meeting as possible. This single set of notes documents the 3 different sessions the WG group meet in order. The first session began with a review of the agenda which included: Agenda Bashing Administrivia Overview of Approach break Document Status - editors Work to be done by the teams Q&A The proposed agenda for the Thursday meeting was: Review of Tuesday Policy based management MIB Technology specific (Differentiated Services) policy MIB Best Current Practices Document. Dave Harrington began with a review of the three main deliverables of the Working group: A Best Current Practices document on SNMP based configuration A MIB module to be used to facilitate policy based configuration A MIB module specific to policy based configuration of differentiated services. Proposed dates for two interim working group meetings were announced with suggested locations: May 17,18,19 interim meeting Boston June 28-03 San Francisco The goal of these meetings is to facilitate delivery of drafts for the expected July 14th ID cut-off in preparation for the July IETF Meeting in Pittsburgh. Dave Harrington then introduced the editor teams currently working on the documents: 1. Capabilities MIB Module - This has been renamed the Policy MIB Module. The editors are Steve Waldbusser, Jon Saperia and Thippanna Hongal. 2. Differentiated Services Policy MIB Module - The editors are currently David Partain and Harrie Hazewinkel. 3. Best Current Practices Document for SNMP-based configuration - The editors are Mike Macfaden and Jon Saperia. The mailing list information was presented and is: General Discussion:snmpconf@snmp.com To Subscribe: snmpconf-request@snmp.com In Body: subscribe snmpconf Archive: snmpconf-request@snmp.com (index snmpconf in body) Jon Saperia began with a presentation that described the general background and goals of the working group and an overview of the current SNMP architecture and how SNMP based configuration fits into that architecture. The benefits of this integrated approach were also described. The general architecture includes a policy MIB module used by systems to advertise their capabilities (such as support for differentiated services) and the types of roles they support such as interfaces that carry traffic from executive offices. The working group is also undertaking the development of a Differentiated Services Policy MIB Module as an example of how such a module can be combined with the general Policy MIB module as a means of aggregating configuration commands in complex technologies. It is optional and up to the various technology experts to determine if such a module is necessary. These two modules, the Policy MIB Module and the Differentiated Services Policy MIB module (which is used as an example for further work that other WGs interested in other technologies may use) are designed to work with the many, many thousands of MIB objects currently defined. These new MIB modules are 'layers of abstraction' on top of the basic objects which have been and will be defined. The presentation continued with an overview of the steps for configuration that would occur in a system with these capabilities: 1. Technology specific policy subsystems would register with policy module capabilities expressed in terms of a policy type and sub type. 2. The manager(s) would then be able to determine system capabilities (web server, vpn support diff serv, mpls, etc.) 3. Managers define roles and associate them with specific instances in specific devices. 4. Managers send policies to managed devices such as: traffic from interfaces for executive offices need to be marked such that they are given preferential service. 5. Managed devices evaluate the policy filter and policy action MIB Objects (the two parts of a policy sent to a managed system) to determine where and when the policy is applied. 6. The technology specific module sets all necessary values to the instances which have evaluated as belonging to 'rule' expressed by the policy filter in the policy MIB Module. Randy Presuhn asked: How does one know the interface is an exec type when things are evaluated. Jon Saperia: Indicated that such information would need to be marked, most often this would require human intervention. 7. A technology specific policy MIB module may not always be required and the general Policy MIB Module may be able to fully express the details of the action to be performed without further expansion in a technology specific policy MIB Module. 8. The management software monitors usage and status to refine policy or verify changes. The meeting continued with a presentation of the Policy MIB Module by Steve Waldbusser. Policy based management provides a method of aggregating management operations and applies them globally to all elements that share certain characteristics. Policies are in the form of if (element has certain characteristic) (then do something) Examples if (if is fast ethernet and is a trunk) then (apply full duplex mode) The Framework: Policy specification exists in a policy server SNMP is used to move policy to the Policy MIB Module How the policy is instantiated in the managed system is implementation specific. A policy is a filter and action pair as described above. The intention of this architecture is to leverage extensive MIB based infrastructure. Filters can use objects to determine what to do. Actions can use objects to cause the action to be realized in the managed system. The Policy MIB Module requires: 1. The Core Architecture 2. The policy table that contains objects for communicating policies 3. Policy filter language. 4. SNMP based support infrastructure The Policy table contains: - filters and actions would probably be octet strings - description - more information about the policy these descriptions which can contain operational 'clues'. policyMatches - number of current matches, useful for debugging Policy filter language need to define a way to express a filter and action Other tables/features in the Policy MIB Module: role table, capabilities, time. About Roles: Some necessary concepts for policy have never been described in MIB objects so we need to add them ourselves. Roles can be political (is exec, outside contract), financial (gold contract), legal (lifeline) or geographical (California, insecure conduit), or engineered (backup, trunk). A table is required to all for the down load of this information, thus the roleEString table. Capabilities Table: The capabilities table allow managers to know what types of policies or configuration operations are supported in the managed elements. Time: policies may need to be executed only at certain times so we need time controls. We need to provide two views of time: globally consistent (UTC time) and local "business time" (MF 9-5 local time). Operational Considerations: - Policy creation: need to allow an engineer to debug a policy - Policy actions can be debugged in a lab (may be provided by a vendor or other as a library of commands) - Debugging of policy filters consists of ensuring that the filter selects the intended set of elements. (need to provide some way of getting feedback) - Need to see where a policy would be executed - table that shows where a policy is executed. Advantages of the approach: built with existing infrastructure and tools, leverages existing MIB Modules, flexibility, complete architecture, includes operational tools. After the presentation by Steve there were a number of questions and answers. Note that some of the questions are not really questions but statements of opinion. They are included here as questions (Q): Q. SNMP can be used to communicate a policy language to device. Many ways to do such communication, have the requirements for real time, reliability, etc. been considered? A. These have been thought about but it is a longer list and should be taken to the mailing list. RFC1270 may have some helpful information. Q. Have they thought about secure source of time? Policies may be pushed early and scheduled for activation at other times. This may require secure time on the local item. Q. Examples seem to be interface based, but much of the policy questions would be based on other items such as class or type of traffic. A. This is simply an artifact of the examples Many things would be available, in the particular example there would need to be a traffic classifier. Q. Policy may need to be applied to something such as all traffic to/from an IP address. Policies seem to attach to something in a device. We may want to attach policies to other items such as IP addresses which will go across larger structures (entire networks). A. Confusing taxonomy: in this particular case policy is being overloaded. Q. What is the difference between policy MIB and the PIB A. [Editorial comment from Jon Saperia who edited these notes - while both items are still in development it is difficult to make exact comparisons especially when which PIB we are speaking about is not specified. In general, if one thinks of the Policy MIB modules under discussion as providing an aggregation of configuration commands, then there is probably some similarity. The Policy Module accepts aggregated commands that are expanded locally on the managed element. This is what happens when a policyFilter is expanded to provide all the instances to which the policy action is to be applied, and the technology specific Policy MIB Modules expand the configuration command (policyAction) of say provide EF PHB to a particular DSCP value, to the many parameters needed to cause each interface selected to provide the desired behavior. Not that the Policy MIB Module also contains the expression of the Roles and Capabilities of the device which in a PIB environment would be conveyed by other means.] Q. Randy: jump up several layers of abstraction talk about configuration mgt. but this isn't configuration management, these are aids for configuration tools. For example this doesn't give any sort of version control of configuration mgt. A. Steve: different view of configuration management, we are providing the tools for helping out with configuration Follow up question by Jon: wold provisioning be a better term. Randy said no. Q. Some items that are general vs. some items that are unique per system how will they be handled A. Roles (which are handled by humans) can be used to handle such items there may also need to be consistent filters etc. Such a scheme may result in an explosion of roles which could be expensive and so needs to be controlled. Q. Does this mean you will need to configure something to configure something (configuration role to configuration parameter)? A. Well yes, but you would only need to configuration the role once and this may give you other features. Jon: clarification: For those items that may be easy you can just touch them directly rather than go through the role and rules. [Jon's added editorial clarification - this means that for simple configuration operations like changing an IP address, it is not necessary to use any of the mechanisms discussed thus far. It is still possible to use basic SNMP set mechanism to change any instance specific objects desired with no additional overhead.] Q. How does this connect to the policy working group. A. This work attempts to use the work in the policy WG as the base info that would be fed into things. Q. The filter/action is similar to some of the work in the policy WG but not exact. will this be a problem. They are not meant to be direct connections but are meant to be connected. Q. Configuration management is challenging task for ISP . What to keep track of what the object should look like vs. what the network is. By using MIB objects as storage are you not seeing what the network is, rather than storing what it should be. The aggregate that they are probably using are similar but are not being used in real time? Take to mailing list: How to deal with large batch of objects, How to store information about networks, How to capture design rules for network Q. Set the record straight about the meaning of policy. Doesn't thing that policy is an aggregate of configuration. Policy framework talks about abstraction rather than aggregation. By using an improper definition for policy this may be different than policy framework. Suggestion that there are flaws in the scheme, the discussion focused on the little things. But we need to discuses the big things. SNMP has a known feature set that may not be proper for use as configuration mgt. Attempt to push to much information and capability down to the device. Reliability, fault tolerance Bad thing for the device to know to much of the policies, as this may require too much update. A. Take to the mailing list. The next presentation on the agenda was from David Partain on the Diffserv Policy MIB Module Current status: A skeleton that still needs to be filled in and input from the community is desired. Input to our effort has thus far come from: PIB work in the rap and Diffserv WGs, goals are similar to the PIB work but without using a new framework Goals of the Diffserv policy MIB module: - network-level policy based configuration of elements supporting diff serv - to provide a level of policy abstraction above the diff serv MIB module mapping tables - diffserv configuration template - tables to map between the goal of policies and the implementation of configuration an addition to the table won't cause changes, but an use of that policy will cause the configuration to be updated. Input to and output form the diffserv policy MIB module: - Manger may speak directly to the diffserv MIB, diffserv policy MIB module may be viewed as similar to PIB Q. Work done in policy group is a high level model of how things should work. A. Two different middle layers with upper and lower systems the same in concept. Believe that the IETF should examine why the two are different should find the conceptual differences between the PIB and the policy MIB module as this will give us good information for solving the problem Agreement from Dave that this is a good idea and that we should try to reduce the difference and hopefully come up with a single solution. David Perkins: comment to let the market decide. What's to be done - what are the abstraction needs - understand what can be or needs to be abstracted from the diff serv MIB - relationship with the policy based management MIB - put meat on the skeleton - alignment with other WGs Input from the community desired - snmpconf WG input - diffserv, policy, rap - diffserv abstractions - policy based management application developers Upcoming Milestones - post draft during next week - collect WG input - revise and post draft by Friday before interim meeting Q. Should Relationship between multiple MIB modules be standardized? A. Interrelationships will be via shared indices and probably not be full blown interfaces. Q. Has the overhead been calculated for how much this would cost. Concern that this will be expensive. This may be caused by a misunderstanding of the policy and should be taken to the list. Will there be a space crunch or will this thrash? Q. Will it be possible to have conflict between the MIBs A. Yes Q. Will there be conflict resolution. A. Yes, there doesn't seem to be any around it. The next presentation was on the Best Current Practices Document by Mike Macfaden: Presentation Topics - review problem statement - goals - requirements: user vendor - review Best Current Practices draft - review further work items Goals of BCP: Document existing knowledge and techniques which demonstrate effective use of the SNMP framework for configuration. Requirements/User: - secure authenticated access - fine grained access control - standards based - integrated view of configuration status and diagnostic info - the configuration method should not obscure what is being configured The presentation continued with a discussion of service provider requirements and the basic outline of the BCP document with some example suggestions. Tasks to be done for the Document: April - collection of info and best current practices on the mailing list - produce new draft for upcoming may meeting May - revise based on feedback compiled for 17-19 May June 28-30 - revised based on May meetings and further development Q. Seems that the best current practices goes beyond configuration is that correct? A. No. It is not the intent to go beyond configuration but there may be connections elsewhere, the particular question asked about notifications which might get involved as part of a configuration change notification. Q. Does include network wide configuration issues as well as day to day type of things. A. Yes. Q. COPS has a clear ownership for a given policy or area, having multiple managers will make this more difficult do we want to discuss it. A. The design team believes that multiple managers and interfaces will be useful/required. The meeting now turned to setting up the agenda for the Thursday meeting which will look at some of the documents in more detail. The order will be: - BCP - diff serv policy MIB module - policy MIB module Thursday March 30th Meeting. The meeting began with a discussion led by Mike Macfaden on the Best common practices document. The outline was reviews and a call for contributions was made. Trying to get this done in a month or so, April will be busy (hopefully) Document is still young and looking for contributions BCP outline Tenets must deal with Murphy's effects, the network may be unstable at times even while configuration is happening. Undocumented defaults are bad. MIB design - the following are some example issues about MIB Module design that are targeted for inclusion in the BCP. Large amount of power available in SMI, must select the proper abstraction - may be able to use some metrics to determine if the abstraction is correct - number of objects to change, rate of change of those objects higher level error information at the application level is helpful and can be contained in MIB objects. Information about this should be in the BCP. Include some support for diagnostics to help debug things trap throttling and higher level decisions to send/not send traps persistence - how the various protocols will play together with objects tagged as read-only etc. Other general problems/benefits of having multiple management interfaces Management system design Need to show examples of things like AC and sysOR table such that agents do them properly and that managers know what they can do do with them and how they might do so. Possibly try and connect the fault system with the configuration system such that folks (users) may be able to understand that "this section of the net is under construction and may be less than smooth" Comments: GWW - any clarifications that we find should also be reflected back in the base docs that cover that area. Q. Why is policy related stuff in the doc A: As we add network wide management we may need more information and practices so that users have a general understanding of how to perform these functions with SNMP. There were multiple comments about usefulness of the work. Unknown comment- Policy is an overloaded term. Suggestion that as we move forward we more clearly define policy high level description of the policy stuff policy vs. policy rules vs. device stuff. Bert - Terminology is being handled in other WGs probably part of the policy framework WG (and charter). The next presentation was on the Differentiated Service Policy MIB Module and was lead by Harry Hazewinkel. Rather than using the Differentiated Services MIB Module which is very complex, Harry created a wwwPolicy MIB Module as a way of presenting the relationship that exists between the Policy MIB Module, the Technology Specific Policy Modules such as the Policy MIB Module Differentiated Services and the device/instance specific MIB Modules. Example scenario uses policy MIB, wwwbwpolicymib and wwwbwmib - wwwbwmib would probably already exist as part of other work. - policy MIB includes the filters and actions - www registers it's capability with the capability table of the policy MIB Module - the manager can then read the table and start configuring the wwwbwmib table and the various roles that may exist (this is defining the services and associating as necessary) - The policy table then is configured to map things and the wwwbwmib is updated as necessary Q. Andy - without some more details this example doesn't allow for much discussion. Unknown - perhaps we should use OIDs rather than octet strings to allow for better filtering. A. Dave Partain - Understands that this isn't most useful but this is mostly trying to show an example of sequence of events and the connections between the tables. Many people still have some difficulty understanding the example of how things should work, etc A. Randy - was able to understand it (he thinks) Q. What happens if somebody adds entries to the device table after the policy has been "activated" should such new rows be subject to the policy? A. Dave Partain - need to look at that issue - this is all part of allowing multiple interfaces/managers and we may need some extra work/objects to make it function (timestamps etc). Q. Randy - If we are doing configuration automation then the new objects wouldn't need to be updated. If we are doing policy automation then the new object would need to be updated. We need to be clear on what we are trying to do. Q. Andy - Another vote for understanding the example, with a suggestion to try and keep things simple and not get bogged down in the details. Q. unknown - this is one way to give a standard way to access a bunch of device specific information. [Editors comment - The above question is important since it correctly captures an essential component of policy based work. That is that different levels of abstraction are needed. In the SNMP environment this concept can be powerfully used since access based on a user's role (such as administrator) can be controlled quite well. For example a less 'skilled' individual may be able to turn a policy on and off as required. This would require access only to the Policy Module. A more 'experienced' individual might be given access to the technology specific MIB Modules such as the example WWW Policy Module Harry presented above. The most skilled might be allowed to access the device specific details and modify them. Examples include the Differentiated Services MIB Module currently under discussion in the Differentiated Service Working group. unknown - multiple interfaces may lead to difficulties Q. Dave Perkins - no magic in SNMP, SNMP and MIB modules are just one way to move information the magic occurs in the other functions as they try and do something with that MIB data. Q. Jeff Case - identified one area that needs work, when multiple layers are able to manipulate the same data via different routes how do we choose which setting "wins" is it last one wins or higher authority wins or some other option. This also includes such questions as what happens when a policy has caused a change in lower layer tables - should the table be reverted when the policy is removed (or expires) etc. Q. John S. - One approach that wasn't mentioned previously - some other groups couldn't see a way to deal with the multiple manager problem. They used a new object to specify who has control Q. Jeff Case - this doesn't solve the problem, it simply moves it. What happens when control changes hands - should changes revert. Q. John S. - a solution to this problem may be intractable and at least should be in it's own RFC Q. Jeff Case - if we only allow them serially then we must disambiguate rules during change over if we allow them in parallel then we must disambiguate rules in real time. Q. John S - should this be a separate work area Q. Jeff Case - must be careful to avoid biting off too much and should try to solve the problem that we understand and that we can. Expansion in the future would be good. Q. Andy - Any solution will need to cover the multiple manager interface and multiple layers. Q. Randy - This discussion may be pushing to attempt to much too soon, doing some of the other steps first may make solving this type of problem more tractable. 1) the current work is doing well at capturing what you want your configuration to be 2) the next step should be to figure out what you currently have 3) the third step would be to make the current configuration match what you want 4) this discussion seems to be going beyond the 3rd step. Q. Jeff case - sounds like Randy is discussing new configurations available on reboots. Q. Randy - that is not what I meant, restate of his points above Q. Dave Partain - disagrees about where we are starting and thinks that we are starting at the early steps that Randy mentioned Q. Jeff Case - difficulty in exceptions - we want a general policy but with some exceptions the difficulty is how to define when the exception should be corrected and when it should be left as is. Q. Dave Perkins - some information/objects may only be available via certain interfaces, some from CLI, some from SNMP etc. A policy manager may need to be able to access multiple interfaces Q. Unknown - The policy description is good even if it isn't used to drive the object setting directly. Q. Dave Partain - will try and update things to be a little more "real" The final discussion of the day was lead by Steve Waldbusser on the Policy Based Manager MIB Module - We are building an infrastructure - We can use small building blocks, e.g. use MIBs (which may be already available). - need to add some pieces - role table - - capabilities table - used to allow managers to understand what they have to work with. - time objects - Policy Table: - simple SNMP table with octet strings for filters and actions - also includes description string, this string may be carried along through translations to more device/mechanism specific Q. Randy - Does the expression evaluation happen at a point in time or does it cover all objects? A. It covers all objects. Q. Are there constraints on objects in policy actions? A. There are no constraints. A policy action can touch any object it wants/needs, at least in theory. The two of these may lead to cycles where one policy action cause the firing of another policy filter/action. Is there any method to keep this from being infinite (no, this problem doesn't seem to be of major concern). Q. We may not have a problem with the multiple managers, if we do we can add owner strings or some other feature to prohibit this function. Q. Randy - may need owner strings to allow VACM to work with a reasonable number of entries Q. Andy - conflict resolution, who is responsible for finding conflicts in the table? A, Steve - first need to start determining what conflicts are real and some work is needed here. Q. Andy - will policy matches be tractable or will the entity need to spend a lot of time to do the updating. Q. Andy - need to formalize the octet strings for filters/actions (agreement) Q. Jeff case - does conflict resolution need to be handled for both policies form the same source or different sources, conflicts are not necessarily bad as long as there is a precedence order to resolve them Q. Andy - but we don't want the device spending all of it's time resolving them. Q. John - describe some of what happened in the policy groups when they looked at some of these problems, currently work in the policy group on information model and schema but not on the language Q. Steve - details of the language are not important yet, figuring out above that what sort of conflict resolution we are going to use is. Q. John - need to get some of the requirements before trying to write a language Q. Randy - some of the language type issues have been solved in ISO/ITU land several years ago and isn't necessarily that difficult. Is not sure that we need conflict resolution, but we would need to be careful about how often/when we do filter checking and actions. Q. unknown - suggestion to leverage the work done in the policy group especially for policy servers which can be gotten from elsewhere. Q. unknown - why is policy stuff in SNMP A. Steve - this is a policy based configuration using SNMP Q. Andy Bierman - lots of work to describe all the details, execution environment, languages etc. After this series of questions and comments Steve continued with: Policy Filter Expressions The expression details are: - Implicit SNMP retrievals - wildcarding - need to avoid locking information down to specific instances - assessors calls to retrieve data in a convenient way, small # to be defined Role Table: Two tables roleEStable and roleSEtable, one is a mirror of the other to allow the indexes to be flipped. -- roleSEtable Can this be used for substring matches? Parameter to choose substring match or exact. -- Accessor Function: Some work is necessary to decide what sort of accessor functions we may need and what they're functionality would be. Capabilities table: Type defined by WG so all managers can understand them sub type allows implementers to add more specific info. More Discussion follows: Question about the type/subtype tags and if the typing will remove some of what an implementer could do. A. This is an attempt to give some structure to the list, the example may be a little off in specifics but does bring up the question of where one draws the line - should Pentium be a type or should it be something more general, should WFQ (weighted fair queue) be a type or would that be a subtype of some other concept More work is required in this area. Q. Andy - the sub type should perhaps be removed from this table and left for the enterprise to put in via an augments. Q. Andy - what about agent capabilities? A. Steve - The agent capabilities macro is not designed for this, designed for MIB compliance stuff. A. Jon - mentions the technology specific modules contain some of the details. For example in the differentiated services policy module only the types of queuing methods supported by the device would be populated in the table. Q. Andy - why not find the info from the diffserv MIB A. Steve - attempt to make it easier to figure out what other policies may be necessary - this brings the info into one place. Q. Dan - need to include some concept of device limitations on execution items - for example perhaps limiting the number of rules that may be executed at a given time which may be different than the number stored. unknown - still need to work on levels of abstraction across all of the work, at the highest level the device capabilities shouldn't need to be known, this should be something that comes in at a lower level. Steve continued the presentation: Time Time needs to be accessible and may need universal as well as local three choices: policy calendar pointer - rfc2591 accessor function multiple MIB objects Q. Andy - this group may decide to avoid time or may have a bunch of discussion that has already been happening in the other groups, (note conflict resolution becomes more difficult with time based stuff) Q. John - there seems to be several problem areas when dealing with time The presentation concluded with the following table: pmPolicyDebugPETable Operational Requirements Table to show what policies are/would be used on elements to allow the operators to debug things - before the polices go out to see what would be affected - when the policy is in use to see what is affecting things and to turn some off if necessary. Q. Andy Bierman - seems to be moving more to policy based rather than configuration and thinks that we shouldn't be redoing the work that the policy groups have been doing. Wants the outcome to be modular such that some pieces (the configuration stuff) can be used on its own. Bert Wijnen, our AD, made some closing remarks. He indicated that he was please with the lack of heated fights and with the progress in the various groups as well as people from the various groups getting together. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Apr 6 10:02:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08520 for ; Thu, 6 Apr 2000 10:02:45 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id JAA11586 for snmpconf-outgoing; Thu, 6 Apr 2000 09:39:01 -0400 (EDT) Message-Id: <200004061338.JAA25888@chmls06.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 06 Apr 2000 09:41:30 -0400 Subject: snmpconf Issues for Interim Meeting From: "Jon Saperia" To: snmpconf Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit For those of you that were at our meetings in Adelaide or have read the draft notes I posted to this list, you will know that we have a number of issues to discuss. As only an example, a question was raised about the effect of the addition of an element to a managed system that had an entry in our Policy Module. Specifically, did that new element get configured with the default information? There are a number of reasonable views on this topic. If anyone has items that can be concisely stated that will help us in our work and would like to suggest them as agenda items for the meeting next month, please feel free to post them to this list and I will collect them together to help refine an agenda. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Thu Apr 6 11:40:10 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10092 for ; Thu, 6 Apr 2000 11:40:09 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id LAA14796 for snmpconf-outgoing; Thu, 6 Apr 2000 11:24:47 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA614128198@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Issues for Interim Meeting Date: Thu, 6 Apr 2000 17:23:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon, I raised during the meeting the question of the interaction with multiple managers. The answer was that the WG sees as a goal allowing such an interaction (which is different from the COPS single server paradigm). Later in the discussions, the proposal of a policy owner concept as a possible solution to this problem as brought up, though we did not engage in too many details. I would suggest that we include this issue in the agenda items for the interim meeting. Regards, Dan > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Thu April 06 2000 15:42 > To: snmpconf > Subject: snmpconf Issues for Interim Meeting > > For those of you that were at our meetings in Adelaide or have read the > draft notes I posted to this list, you will know that we have a number of > issues to discuss. > > As only an example, a question was raised about the effect of the addition > of an element to a managed system that had an entry in our Policy Module. > Specifically, did that new element get configured with the default > information? There are a number of reasonable views on this topic. > > If anyone has items that can be concisely stated that will help us in our > work and would like to suggest them as agenda items for the meeting next > month, please feel free to post them to this list and I will collect them > together to help refine an agenda. > > Thanks > /jon From owner-snmpconf@seymour39.SNMP.COM Thu Apr 6 12:49:38 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11183 for ; Thu, 6 Apr 2000 12:49:37 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id MAA16930 for snmpconf-outgoing; Thu, 6 Apr 2000 12:30:59 -0400 (EDT) Message-Id: <200004061630.MAA14494@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 06 Apr 2000 12:33:30 -0400 Subject: Re: snmpconf Issues for Interim Meeting From: "Jon Saperia" To: snmpconf@snmp.com Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit > Jon, > > I raised during the meeting the question of the interaction with multiple > managers. The answer was that the WG sees as a goal allowing such an > interaction (which is different from the COPS single server paradigm). Later > in the discussions, the proposal of a policy owner concept as a possible > solution to this problem as brought up, though we did not engage in too many > details. > > I would suggest that we include this issue in the agenda items for the > interim meeting. > Excellent point, I have started a list and have added this. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Sat Apr 8 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 HAA09694 for ; Sat, 8 Apr 2000 07:29:36 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA20897 for snmpconf-outgoing; Sat, 8 Apr 2000 07:09:15 -0400 (EDT) Message-Id: <200004081108.HAA21385@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sat, 08 Apr 2000 07:11:44 -0400 Subject: snmpconf Minutes of SNMPCONFG WG Meetings at 47th IETF - Reported by Jon Saperia From: "Jon Saperia" To: minutes@ietf.org CC: saperia@mediaone.net, snmpconf , Bert Wijnen , Randy Bush Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The snmpconf (SNMP Configuration) working group meet on Tuesday and Thursday March 28 and 30 during the 47th IETF. Below are the minutes of those meetings. Special thanks go to Carl Kalbfleish and Shawn Routhier for taking a comprehensive set of notes during these meetings. Please also note that the presentations briefly described in these notes will also be published in their original form. These notes are a bit longer than usual since much of the question and answer discussion was not removed from these minutes in order to capture as much of the meeting as possible. This single set of notes documents the 3 different sessions the WG group meet in order. The first session began with a review of the agenda which included: Agenda Bashing Administrivia Overview of Approach break Document Status - editors Work to be done by the teams Q&A The proposed agenda for the Thursday meeting was: Review of Tuesday Policy based management MIB Technology specific (Differentiated Services) policy MIB Best Current Practices Document. Dave Harrington began with a review of the three main deliverables of the Working group: A Best Current Practices document on SNMP based configuration A MIB module to be used to facilitate policy based configuration A MIB module specific to policy based configuration of differentiated services. Proposed dates for two interim working group meetings were announced with suggested locations: May 17,18,19 interim meeting Boston June 28-30 San Francisco The goal of these meetings is to facilitate delivery of drafts for the expected July 14th ID cut-off in preparation for the July IETF Meeting in Pittsburgh. Dave Harrington then introduced the editor teams currently working on the documents: 1. Capabilities MIB Module - This has been renamed the Policy MIB Module. The editors are Steve Waldbusser, Jon Saperia and Thippanna Hongal. 2. Differentiated Services Policy MIB Module - The editors are currently David Partain and Harrie Hazewinkel. 3. Best Current Practices Document for SNMP-based configuration - The editors are Mike Macfaden and Jon Saperia. The mailing list information was presented and is: General Discussion:snmpconf@snmp.com To Subscribe: snmpconf-request@snmp.com In Body: subscribe snmpconf Archive: snmpconf-request@snmp.com (index snmpconf in body) Jon Saperia began with a presentation that described the general background and goals of the working group and an overview of the current SNMP architecture and how SNMP based configuration fits into that architecture. The benefits of this integrated approach were also described. The general architecture includes a policy MIB module used by systems to advertise their capabilities (such as support for differentiated services) and the types of roles they support such as interfaces that carry traffic from executive offices. The working group is also undertaking the development of a Differentiated Services Policy MIB Module as an example of how such a module can be combined with the general Policy MIB module as a means of aggregating configuration commands in complex technologies. It is optional and up to the various technology experts to determine if such a module is necessary. These two modules, the Policy MIB Module and the Differentiated Services Policy MIB module (which is used as an example for further work that other WGs interested in other technologies may use) are designed to work with the many, many thousands of MIB objects currently defined. These new MIB modules are 'layers of abstraction' on top of the basic objects which have been and will be defined. The presentation continued with an overview of the steps for configuration that would occur in a system with these capabilities: 1. The technology specific policy subsystems would register with the policy module their capabilities. They are expressed in terms of policy type and subtype MIB Objects. 2. The manager(s) would then be able to determine system capabilities (web server, vpn support diff serv, mpls, etc.) 3. Managers define roles and associate them with specific instances in specific devices. 4. Managers send policies to managed devices such as: traffic from interfaces for executive offices need to be marked such that they are given preferential service. 5. Managed devices evaluate the policy filter and policy action MIB Objects (the two parts of a policy sent to a managed system) to determine where and when the policy is applied. 6. The technology specific module sets all necessary values to the instances which have evaluated as belonging to 'rule' expressed by the policy filter in the policy MIB Module. Randy Presuhn asked: How does one know the interface is an exec type when things are evaluated. Jon Saperia: Indicated that such information would need to be marked, most often this would require human intervention. 7. A technology specific policy MIB module may not always be required and the general Policy MIB Module may be able to fully express the details of the action to be performed without further expansion in a technology specific policy MIB Module. 8. The management software monitors usage and status to refine policy or verify changes. The meeting continued with a presentation of the Policy MIB Module by Steve Waldbusser. Policy based management provides a method of aggregating management operations and applies them globally to all elements that share certain characteristics. Policies are in the form of if (element has certain characteristic) (then do something) Examples if (it is fast ethernet and is a trunk) then (apply full duplex mode) The Framework: Policy specification exists in a policy server SNMP is used to move policy to the Policy MIB Module How the policy is instantiated in the managed system is implementation specific. A policy is a filter and action pair as described above. The intention of this architecture is to leverage extensive MIB based infrastructure. Filters can use objects to determine what to do. Actions can use objects to cause the action to be realized in the managed system. The Policy MIB Module requires: 1. The Core Architecture 2. The policy table that contains objects for communicating policies 3. Policy filter language. 4. SNMP based support infrastructure The Policy table contains: - filters and actions would probably be octet strings - description - more information about the policy these descriptions which can contain operational 'clues'. policyMatches - number of current matches, useful for debugging Policy filter language need to define a way to express a filter and action Other tables/features in the Policy MIB Module: role table, capabilities, time. About Roles: Some necessary concepts for policy have never been described in MIB objects so we need to add them ourselves. Roles can be political (is exec, outside contract), financial (gold contract), legal (lifeline) or geographical (California, insecure conduit), or engineered (backup, trunk). A table is required for the down load of this information, thus the roleEString table. Capabilities Table: The capabilities table allow managers to know what types of policies or configuration operations are supported in the managed elements. Time: policies may need to be executed only at certain times so we need time controls. We need to provide two views of time: globally consistent (UTC time) and local "business time" (MF 9-5 local time). Operational Considerations: - Policy creation: need to allow an engineer to debug a policy - Policy actions can be debugged in a lab (may be provided by a vendor or other as a library of commands) - Debugging of policy filters consists of ensuring that the filter selects the intended set of elements. (need to provide some way of getting feedback) - Need to see where a policy would be executed - table that shows where a policy is executed. Advantages of the approach: built with existing infrastructure and tools, leverages existing MIB Modules, flexibility, complete architecture, includes operational tools. After the presentation by Steve there were a number of questions and answers. Note that some of the questions are not really questions but statements of opinion. They are included here as questions (Q): Q. SNMP can be used to communicate a policy language to device. Many ways to do such communication, have the requirements for real time, reliability, etc. been considered? A. These have been thought about but it is a longer list and should be taken to the mailing list. RFC1270 may have some helpful information. Q. Have they thought about secure source of time? Policies may be pushed early and scheduled for activation at other times. This may require secure time on the local system. Q. Examples seem to be interface based, but much of the policy questions would be based on other items such as class or type of traffic. A. This is simply an artifact of the examples Many things would be available, in the particular example there would need to be a traffic classifier. Q. Policy may need to be applied to something such as all traffic to/from an IP address. Policies seem to attach to something in a device. We may want to attach policies to other items such as IP addresses which will go across larger structures (entire networks). A. Confusing taxonomy: in this particular case policy is being overloaded. Q. What is the difference between policy MIB and the PIB A. [Editorial comment from Jon Saperia who edited these notes - while both items are still in development it is difficult to make exact comparisons especially when which PIB we are speaking about is not specified. In general, if one thinks of the Policy MIB modules under discussion as providing an aggregation of configuration commands, then there is probably some similarity. The Policy Module accepts aggregated commands that are expanded locally on the managed element. This is what happens when a policyFilter is expanded to provide all the instances to which the policy action is to be applied, and the technology specific Policy MIB Modules expand the configuration command (policyAction) of say provide EF PHB to a particular DSCP value, to the many parameters needed to cause each interface selected to provide the desired behavior. Not that the Policy MIB Module also contains the expression of the Roles and Capabilities of the device which in a PIB environment would be conveyed by other means.] Q. Randy: jump up several layers of abstraction talk about configuration mgt. but this isn't configuration management, these are aids for configuration tools. For example this doesn't give any sort of version control of configuration mgt. A. Steve: different view of configuration management, we are providing the tools for helping out with configuration Follow up question by Jon: would provisioning be a better term? Randy said no. Q. Some items that are general vs. some items that are unique per system how will they be handled A. Roles (which are handled by humans) can be used to handle such items there may also need to be consistent filters etc. Such a scheme may result in an explosion of roles which could be expensive and so needs to be controlled. Q. Does this mean you will need to configure something to configure something (configuration role to configuration parameter)? A. Well yes, but you would only need to configure the role once and this may give you other features. Jon: clarification: For those items that may be easy you can just touch them directly rather than go through the role and rules. [Jon's added editorial clarification - this means that for simple configuration operations like changing an IP address, it is not necessary to use any of the mechanisms discussed thus far. It is still possible to use basic SNMP set mechanism to change any instance specific objects desired with no additional overhead.] Q. How does this connect to the policy working group. A. This work attempts to use the work in the policy WG as the base info that would be fed into things. Q. The filter/action is similar to some of the work in the policy WG but not exact. will this be a problem. They are not meant to be direct connections but are meant to be connected. Q. Configuration management is challenging task for ISP . What to keep track of what the object should look like vs. what the network is. By using MIB objects as storage are you not seeing what the network is, rather than storing what it should be. The aggregate that they are probably using are similar but are not being used in real time? Take to mailing list: How to deal with large batch of objects, How to store information about networks, How to capture design rules for network Q. Set the record straight about the meaning of policy. Doesn't think that policy is an aggregate of configuration. Policy framework talks about abstraction rather than aggregation. By using an improper definition for policy this may be different than policy framework. Suggestion that there are flaws in the scheme, the discussion focused on the little things. But we need to discuses the big things. SNMP has a known feature set that may not be proper for use as configuration mgt. Attempt to push to much information and capability down to the device. Reliability, fault tolerance Bad thing for the device to know to much of the policies, as this may require too much update. A. Take to the mailing list. The next presentation on the agenda was from David Partain on the Diffserv Policy MIB Module Current status: A skeleton that still needs to be filled in and input from the community is desired. Input to our effort has thus far come from: PIB work in the rap and Diffserv WGs, goals are similar to the PIB work but without using a new framework Goals of the Diffserv policy MIB module: - network-level policy based configuration of elements supporting diff serv - to provide a level of policy abstraction above the diff serv MIB module mapping tables - diffserv configuration template - tables to map between the goal of policies and the implementation of configuration an addition to the table won't cause changes, but an use of that policy will cause the configuration to be updated. Input to and output form the diffserv policy MIB module: - Manger may speak directly to the diffserv MIB, diffserv policy MIB module may be viewed as similar to PIB Q. Work done in policy group is a high level model of how things should work. A. Two different middle layers with upper and lower systems the same in concept. Believe that the IETF should examine why the two are different should find the conceptual differences between the PIB and the policy MIB module as this will give us good information for solving the problem Agreement from Dave that this is a good idea and that we should try to reduce the difference and hopefully come up with a single solution. David Perkins: comment to let the market decide. What's to be done - what are the abstraction needs - understand what can be or needs to be abstracted from the diff serv MIB - relationship with the policy based management MIB - put meat on the skeleton - alignment with other WGs Input from the community desired - snmpconf WG input - diffserv, policy, rap - diffserv abstractions - policy based management application developers Upcoming Milestones - post draft during next week - collect WG input - revise and post draft by Friday before interim meeting Q. Should Relationship between multiple MIB modules be standardized? A. Interrelationships will be via shared indices and probably not be full blown interfaces. Q. Has the overhead been calculated for how much this would cost. Concern that this will be expensive. This may be caused by a misunderstanding of the policy and should be taken to the list. Will there be a space crunch or will this thrash? Q. Will it be possible to have conflict between the MIBs A. Yes Q. Will there be conflict resolution. A. Yes, there doesn't seem to be any around it. The next presentation was on the Best Current Practices Document by Mike Macfaden: Presentation Topics - review problem statement - goals - requirements: user vendor - review Best Current Practices draft - review further work items Goals of BCP: Document existing knowledge and techniques which demonstrate effective use of the SNMP framework for configuration. Requirements/User: - secure authenticated access - fine grained access control - standards based - integrated view of configuration status and diagnostic info - the configuration method should not obscure what is being configured The presentation continued with a discussion of service provider requirements and the basic outline of the BCP document with some example suggestions. Tasks to be done for the Document: April - collection of info and best current practices on the mailing list - produce new draft for upcoming may meeting May - revise based on feedback compiled for 17-19 May June 28-30 - revised based on May meetings and further development Q. Seems that the best current practices goes beyond configuration is that correct? A. No. It is not the intent to go beyond configuration but there may be connections elsewhere, the particular question asked about notifications which might get involved as part of a configuration change notification. Q. Does [this work] include network wide configuration issues as well as day to day type of things. A. Yes. Q. COPS has a clear ownership for a given policy or area, having multiple managers will make this more difficult do we want to discuss it. A. The design team believes that multiple managers and interfaces will be useful/required. The meeting now turned to setting up the agenda for the Thursday meeting which will look at some of the documents in more detail. The order will be: - BCP - diff serv policy MIB module - policy MIB module Thursday March 30th Meeting. The meeting began with a discussion led by Mike Macfaden on the Best common practices document. The outline was reviewed and a call for contributions was made. Trying to get this done in a month or so, April will be busy (hopefully) Document is still young and looking for contributions BCP outline Tenets must deal with Murphy's effects, the network may be unstable at times even while configuration is happening. Undocumented defaults are bad. MIB design - the following are some example issues about MIB Module design that are targeted for inclusion in the BCP. Large amount of power available in SMI, must select the proper abstraction - may be able to use some metrics to determine if the abstraction is correct - number of objects to change, rate of change of those objects higher level error information at the application level is helpful and can be contained in MIB objects. Information about this should be in the BCP. Include some support for diagnostics to help debug things trap throttling and higher level decisions to send/not send traps persistence - how the various protocols will play together with objects tagged as read-only etc. Other general problems/benefits of having multiple management interfaces Management system design Need to show examples of things like AC and sysOR table such that agents do them properly and that managers know what they can do do with them and how they might do so. Possibly try and connect the fault system with the configuration system such that folks (users) may be able to understand that "this section of the net is under construction and may be less than smooth" Comments: GWW - any clarifications that we find should also be reflected back in the base docs that cover that area. Q. Why is policy related stuff in the doc A: As we add network wide management we may need more information and practices so that users have a general understanding of how to perform these functions with SNMP. There were multiple comments about usefulness of the work. Unknown comment- Policy is an overloaded term. Suggestion that as we move forward we more clearly define policy high level description of the policy stuff policy vs. policy rules vs. device stuff. Bert - Terminology is being handled in other WGs probably part of the policy framework WG (and charter). The next presentation was on the Differentiated Service Policy MIB Module and was lead by Harrie Hazewinkel. Rather than using the Differentiated Services MIB Module which is very complex, Harrie created a wwwPolicy MIB Module as a way of presenting the relationship that exists between the Policy MIB Module, the Technology Specific Policy Modules such as the Policy MIB Module Differentiated Services and the device/instance specific MIB Modules. Example scenario uses policy MIB, wwwbwpolicymib and wwwbwmib - wwwbwmib would probably already exist as part of other work. - policy MIB includes the filters and actions - The wwwbandwithpolicymib subsystem registers it's capability with the capability table of the policy MIB Module - the manager can then read the table and start configuring the wwwbwmib table and the various roles that may exist (this is defining the services and associating as necessary) - The policy table then is configured to map things and the wwwbwmib is updated as necessary Q. Andy - without some more details this example doesn't allow for much discussion. Unknown - perhaps we should use OIDs rather than octet strings to allow for better filtering. A. Dave Partain - Understands that this isn't most useful but this is mostly trying to show an example of sequence of events and the connections between the tables. Many people still have some difficulty understanding the example of how things should work, etc A. Randy - was able to understand it (he thinks) Q. What happens if somebody adds entries to the device table after the policy has been "activated" should such new rows be subject to the policy? A. Dave Partain - need to look at that issue - this is all part of allowing multiple interfaces/managers and we may need some extra work/objects to make it function (timestamps etc). Q. Randy - If we are doing configuration automation then the new objects wouldn't need to be updated. If we are doing policy automation then the new object would need to be updated. We need to be clear on what we are trying to do. Q. Andy - Another vote for understanding the example, with a suggestion to try and keep things simple and not get bogged down in the details. Q. unknown - this is one way to give a standard way to access a bunch of device specific information. [Editors comment - The above question is important since it correctly captures an essential component of policy based work. That is that different levels of abstraction are needed. In the SNMP environment this concept can be powerfully used since access based on a user's role (such as administrator) can be controlled quite well. For example a less 'skilled' individual may be able to turn a policy on and off as required. This would require access only to the Policy Module. A more 'experienced' individual might be given access to the technology specific MIB Modules such as the example WWW Policy Module Harrie presented above. The most skilled might be allowed to access the device specific details and modify them. Examples include the Differentiated Services MIB Module currently under discussion in the Differentiated Service Working group. unknown - multiple interfaces may lead to difficulties Q. Dave Perkins - no magic in SNMP, SNMP and MIB modules are just one way to move information the magic occurs in the other functions as they try and do something with that MIB data. Q. Jeff Case - identified one area that needs work, when multiple layers are able to manipulate the same data via different routes how do we choose which setting "wins" is it last one wins or higher authority wins or some other option. This also includes such questions as what happens when a policy has caused a change in lower layer tables - should the table be reverted when the policy is removed (or expires) etc. Q. John S. - One approach that wasn't mentioned previously - some other groups couldn't see a way to deal with the multiple manager problem. They used a new object to specify who has control Q. Jeff Case - this doesn't solve the problem, it simply moves it. What happens when control changes hands - should changes revert. Q. John S. - a solution to this problem may be intractable and at least should be in it's own RFC Q. Jeff Case - if we only allow them serially then we must disambiguate rules during change over if we allow them in parallel then we must disambiguate rules in real time. Q. John S - should this be a separate work area Q. Jeff Case - must be careful to avoid biting off too much and should try to solve the problem that we understand and that we can. Expansion in the future would be good. Q. Andy - Any solution will need to cover the multiple manager interface and multiple layers. Q. Randy - This discussion may be pushing to attempt to much too soon, doing some of the other steps first may make solving this type of problem more tractable. 1) the current work is doing well at capturing what you want your configuration to be 2) the next step should be to figure out what you currently have 3) the third step would be to make the current configuration match what you want 4) this discussion seems to be going beyond the 3rd step. Q. Jeff case - sounds like Randy is discussing new configurations available on reboots. Q. Randy - that is not what I meant, restate of his points above Q. Dave Partain - disagrees about where we are starting and thinks that we are starting at the early steps that Randy mentioned Q. Jeff Case - difficulty in exceptions - we want a general policy but with some exceptions the difficulty is how to define when the exception should be corrected and when it should be left as is. Q. Dave Perkins - some information/objects may only be available via certain interfaces, some from CLI, some from SNMP etc. A policy manager may need to be able to access multiple interfaces Q. Unknown - The policy description is good even if it isn't used to drive the object setting directly. Q. Dave Partain - will try and update things to be a little more "real" The final discussion of the day was lead by Steve Waldbusser on the Policy Based Manager MIB Module - We are building an infrastructure - We can use small building blocks, e.g. use MIBs (which may be already available). - need to add some pieces - role table - - capabilities table - used to allow managers to understand what they have to work with. - time objects - Policy Table: - simple SNMP table with octet strings for filters and actions - also includes description string, this string may be carried along through translations to more device/mechanism specific Q. Randy - Does the expression evaluation happen at a point in time or does it cover all objects? A. It covers all objects. Q. Are there constraints on objects in policy actions? A. There are no constraints. A policy action can touch any object it wants/needs, at least in theory. The two of these may lead to cycles where one policy action cause the firing of another policy filter/action. Is there any method to keep this from being infinite (no, this problem doesn't seem to be of major concern). Q. We may not have a problem with the multiple managers, if we do we can add owner strings or some other feature to prohibit this function. Q. Randy - may need owner strings to allow VACM to work with a reasonable number of entries Q. Andy - conflict resolution, who is responsible for finding conflicts in the table? A, Steve - first need to start determining what conflicts are real and some work is needed here. Q. Andy - will policy matches be tractable or will the entity need to spend a lot of time to do the updating. Q. Andy - need to formalize the octet strings for filters/actions (agreement) Q. Jeff case - does conflict resolution need to be handled for both policies from the same source or different sources, conflicts are not necessarily bad as long as there is a precedence order to resolve them Q. Andy - but we don't want the device spending all of it's time resolving them. Q. John - describe some of what happened in the policy groups when they looked at some of these problems, currently work in the policy group on information model and schema but not on the language Q. Steve - details of the language are not important yet, figuring out above that what sort of conflict resolution we are going to use is. Q. John - need to get some of the requirements before trying to write a language Q. Randy - some of the language type issues have been solved in ISO/ITU land several years ago and isn't necessarily that difficult. Is not sure that we need conflict resolution, but we would need to be careful about how often/when we do filter checking and actions. Q. unknown - suggestion to leverage the work done in the policy group especially for policy servers which can be gotten from elsewhere. Q. unknown - why is policy stuff in SNMP A. Steve - this is a policy based configuration using SNMP Q. Andy Bierman - lots of work to describe all the details, execution environment, languages etc. After this series of questions and comments Steve continued with: Policy Filter Expressions The expression details are: - Implicit SNMP retrievals - wildcarding - need to avoid locking information down to specific instances - assessors calls to retrieve data in a convenient way, small # to be defined Role Table: Two tables roleEStable and roleSEtable, one is a mirror of the other to allow the indexes to be flipped. -- roleSEtable Can this be used for substring matches? Parameter to choose substring match or exact. -- Accessor Function: Some work is necessary to decide what sort of accessor functions we may need and what the functionality would be. Capabilities table: Type defined by WG so all managers can understand them sub type allows implementers to add more specific info. More Discussion follows: Question about the type/subtype tags and if the typing will remove some of what an implementer could do. A. This is an attempt to give some structure to the list, the example may be a little off in specifics but does bring up the question of where one draws the line - should Pentium be a type or should it be something more general, should WFQ (weighted fair queue) be a type or would that be a subtype of some other concept More work is required in this area. Q. Andy - the sub type should perhaps be removed from this table and left for the enterprise to put in via an augments. Q. Andy - what about agent capabilities? A. Steve - The agent capabilities macro is not designed for this, designed for MIB compliance stuff. A. Jon - mentions the technology specific modules contain some of the details. For example in the differentiated services policy module only the types of queuing methods supported by the device would be populated in the table. Q. Andy - why not find the info from the diffserv MIB A. Steve - attempt to make it easier to figure out what other policies may be necessary - this brings the info into one place. Q. Dan - need to include some concept of device limitations on execution items - for example perhaps limiting the number of rules that may be executed at a given time which may be different than the number stored. unknown - still need to work on levels of abstraction across all of the work, at the highest level the device capabilities shouldn't need to be known, this should be something that comes in at a lower level. Steve continued the presentation: Time Time needs to be accessible and may need universal as well as local three choices: policy calendar pointer - rfc2591 accessor function multiple MIB objects Q. Andy - this group may decide to avoid time or may have a bunch of discussion that has already been happening in the other groups, (note conflict resolution becomes more difficult with time based stuff) Q. John - there seems to be several problem areas when dealing with time The presentation concluded with the following table: pmPolicyDebugPETable Operational Requirements Table to show what policies are/would be used on elements to allow the operators to debug things - before the polices go out to see what would be affected - when the policy is in use to see what is affecting things and to turn some off if necessary. Q. Andy Bierman - seems to be moving more to policy based rather than configuration and thinks that we shouldn't be redoing the work that the policy groups have been doing. Wants the outcome to be modular such that some pieces (the configuration stuff) can be used on its own. Bert Wijnen, our AD, made some closing remarks. He indicated that he was pleased with the lack of heated fights and with the progress in the various groups as well as people from the various groups getting together. From owner-snmpconf@seymour39.SNMP.COM Sat Apr 8 07:36: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 HAA09780 for ; Sat, 8 Apr 2000 07:36:08 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id HAA20950 for snmpconf-outgoing; Sat, 8 Apr 2000 07:21:11 -0400 (EDT) Message-Id: <200004081120.HAA23791@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sat, 08 Apr 2000 07:23:50 -0400 Subject: snmpconf Working Group Presentations From: "Jon Saperia" To: snmpconf CC: Randy Bush , Bert Wijnen Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit For those of you that may be interested, I have forwarded to the IETF minutes people, all the PowerPoint presentations made at our meeting last week. I did not send them to this list since some people do not like to receive 2.5 MB email messages. If anyone has an urgent need for them before the IETF puts the proceedings out, please let me know. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Sat Apr 8 08: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 IAA10305 for ; Sat, 8 Apr 2000 08:42:24 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA21176 for snmpconf-outgoing; Sat, 8 Apr 2000 08:29:53 -0400 (EDT) Message-ID: <38EF24CA.2671C7D3@americasm01.nt.com> Date: Sat, 08 Apr 2000 08:23:38 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Kung Loh" Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf Working Group Presentations References: <200004081120.HAA23791@chmls05.mediaone.net> Content-Type: multipart/mixed; boundary="------------0704B5811A6A6C1EB9C94EAE" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com This is a multi-part message in MIME format. --------------0704B5811A6A6C1EB9C94EAE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jon: Could you please email the presentations to me at your convenience? Thanks in advance Kung Jon Saperia wrote: > > For those of you that may be interested, I have forwarded to the IETF > minutes people, all the PowerPoint presentations made at our meeting last > week. I did not send them to this list since some people do not like to > receive 2.5 MB email messages. If anyone has an urgent need for them before > the IETF puts the proceedings out, please let me know. > Thanks > /jon --------------0704B5811A6A6C1EB9C94EAE Content-Type: text/x-vcard; charset=us-ascii; name="kungloh.vcf" Content-Description: Card for Loh, Kung Content-Disposition: attachment; filename="kungloh.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Loh;Kung tel;work:ESN352-7043 x-mozilla-html:FALSE org:5A50 Preside Management adr:;;;;;; version:2.1 email;internet:kungloh@americasm01.nt.com x-mozilla-cpt:;-24960 fn:Kung Loh end:vcard --------------0704B5811A6A6C1EB9C94EAE-- From owner-snmpconf@seymour39.SNMP.COM Sat Apr 8 10:12: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 KAA10902 for ; Sat, 8 Apr 2000 10:12:53 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id JAA21740 for snmpconf-outgoing; Sat, 8 Apr 2000 09:56:58 -0400 (EDT) Message-Id: <200004081356.JAA04385@chmls05.mediaone.net> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Sat, 08 Apr 2000 09:59:37 -0400 Subject: snmpconf SNMPCONF Working Group Interim Meeting Announcement From: "Jon Saperia" To: ietf@ietf.org, snmpconf CC: Randy Bush , Bert Wijnen , saperia@mediaone.net Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit The SNMPCONF Working group intends to hold an interim meeting to work on all items currently in our charter: - The Best Current Practices Document - The Differentiated Services Policy MIB Module - The General Policy MIB Module To better coordinate with other meetings, the location has changed since it was last discussed at the Adelaide IETF Meeting. Details available at this time are: Meeting Dates: Wednesday, May 17 9am - 6pm Thursday, May 18 9am - 6pm Friday, May 19 9am - 3pm Location: (Meeting Site TBD) San Francisco or San Jose, CA Sponsor: A sponsor or co-sponsors are desired to host this meeting. A hotel meeting room is preferred, but corporate facilities would be fine. Please contact me at saperia@mediaone.net if you can help. From owner-snmpconf@seymour39.SNMP.COM Sun Apr 9 03:43:03 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 DAA05396 for ; Sun, 9 Apr 2000 03:43:03 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id DAA04339 for snmpconf-outgoing; Sun, 9 Apr 2000 03:25:25 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA6141281A5@ITC-EML2> From: Dan Romascanu To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Working Group Presentations Date: Sun, 9 Apr 2000 09:23:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon, Can you please forward me the presentations? Thanks, Dan > -----Original Message----- > From: Jon Saperia [SMTP:saperia@mediaone.net] > Sent: Sat April 08 2000 13:24 > To: snmpconf > Cc: Randy Bush; Bert Wijnen > Subject: snmpconf Working Group Presentations > > For those of you that may be interested, I have forwarded to the IETF > minutes people, all the PowerPoint presentations made at our meeting last > week. I did not send them to this list since some people do not like to > receive 2.5 MB email messages. If anyone has an urgent need for them > before > the IETF puts the proceedings out, please let me know. > Thanks > /jon From owner-snmpconf@seymour39.SNMP.COM Sun Apr 9 12:48:01 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 MAA09311 for ; Sun, 9 Apr 2000 12:48:00 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id MAA08387 for snmpconf-outgoing; Sun, 9 Apr 2000 12:27:12 -0400 (EDT) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Sun, 09 Apr 2000 12:29:49 -0400 Subject: snmpconf The May interim Meeting - Please respond asap 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 Folks, I am working on making arrangements for the interim SNMPCONF WG meeting that will be held May 17 to 19th in either San Francisco or just south depending on availability. As some of you know, we are attempting to coordinate this meeting with an RMON WG meeting that will take place Monday and Tuesday of the same week to reduce travel for participants who might be interested in both and the Area Director. In order to get a good rate, we need to know how many people are likely to attend. Please send me a note as soon as you can to let me know if you plan on attending either or both of the WG Meetings. Andy will poll the RMON list as well. Thanks very much /jon From owner-snmpconf@seymour39.SNMP.COM Sun Apr 9 14:04:00 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09856 for ; Sun, 9 Apr 2000 14:04:00 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id NAA08642 for snmpconf-outgoing; Sun, 9 Apr 2000 13:50:22 -0400 (EDT) Message-ID: <38F0C369.1EFB5FEB@cisco.com> Date: Sun, 09 Apr 2000 10:52:41 -0700 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: rmonmib@cisco.com Subject: Re: snmpconf The May interim Meeting - Please respond asap 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: > > Folks, I am working on making arrangements for the interim SNMPCONF WG > meeting that will be held May 17 to 19th in either San Francisco or just > south depending on availability. > > As some of you know, we are attempting to coordinate this meeting with an > RMON WG meeting that will take place Monday and Tuesday of the same week to > reduce travel for participants who might be interested in both and the Area > Director. > > In order to get a good rate, we need to know how many people are likely to > attend. Please send me a note as soon as you can to let me know if you plan > on attending either or both of the WG Meetings. Andy will poll the RMON list > as well. Thanks Jon, I'll just borrow your msg :-) The RMONMIB WG intends to hold a 2 day interim on the Monday & Tuesday (May 15-17), at the same hotel as the SNMPCONF WG interim, in San Francisco, CA. Please send mail to Jon at saperia@mediaone.net and indicate: - which interim meeting(s) you plan to attend (rmon, snmpconf, both) - which nights (if any) you plan to stay at the hotel hosting the meetings? The hotel room rate is likely to be in the range $180 - $220 USD. > > Thanks very much > /jon Andy From owner-snmpconf@seymour39.SNMP.COM Sun Apr 9 18:57:12 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13998 for ; Sun, 9 Apr 2000 18:57:11 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA09826 for snmpconf-outgoing; Sun, 9 Apr 2000 18:44:50 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB06B1B683@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: snmpconf@snmp.com Subject: RE: snmpconf The May interim Meeting - Please respond asap Date: Mon, 10 Apr 2000 00:44:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Jon, I intend to attend both SNMPCONF and RMONMIB meetings. Bert From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 08:14:02 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 IAA06912 for ; Mon, 10 Apr 2000 08:14:01 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id HAA22107 for snmpconf-outgoing; Mon, 10 Apr 2000 07:58:17 -0400 (EDT) Message-ID: <35A7D40B978CD311AF05002048404D34C0D0D2@wm2.btrd.bostontechnology.com> From: "Wiener, Steve (Marketing)" To: "'snmpconf@snmp.com'" Subject: RE: snmpconf Working Group Presentations Date: Mon, 10 Apr 2000 07:53:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Please forward persentations to me Thank you Steve Wiener Product Marketing Enhanced Services Division 100 Quannapowitt Parkway Wakefield, MA 01880 781-224-8528 swiener@comversens.com -----Original Message----- From: Jon Saperia [mailto:saperia@mediaone.net] Sent: Saturday, April 08, 2000 7:24 AM To: snmpconf Cc: Randy Bush; Bert Wijnen Subject: snmpconf Working Group Presentations For those of you that may be interested, I have forwarded to the IETF minutes people, all the PowerPoint presentations made at our meeting last week. I did not send them to this list since some people do not like to receive 2.5 MB email messages. If anyone has an urgent need for them before the IETF puts the proceedings out, please let me know. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 17:22: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 RAA04901 for ; Mon, 10 Apr 2000 17:22:28 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id RAA00892 for snmpconf-outgoing; Mon, 10 Apr 2000 17:00:07 -0400 (EDT) Message-Id: <200004102100.RAA17950@aix43.snmp.com> X-Mailer: exmh version 2.1.1 10/15/1999 to: snmpconf@snmp.com Subject: Re: snmpconf Working Group Presentations Date: Mon, 10 Apr 2000 17:00:05 -0400 From: Steve Moulton Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com The snmpconf working group presentation slides are available via anonymous ftp in ftp.snmp.com, directory pub/snmpconf. You need to explicitly cd pub/snmpconf to see a directory of the files. I would have made these available via majordomo, but I could not get it to successfully mime the files in the short amount of time I have available to make these files available. The files are bcp-meeting-2.ppt bcp-overview.ppt policyModule-thurs.ppt policyModule-tues.ppt snmpconf-overview.ppt snmpconf-partain-day1.ppt snmpconf-partain-day2.ppt --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 17:24:02 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 RAA04929 for ; Mon, 10 Apr 2000 17:24:02 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA01013 for snmpconf-outgoing; Mon, 10 Apr 2000 17:07:10 -0400 (EDT) Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC721@SOL> From: Andrew Smith To: "Jon Saperia (E-mail)" Cc: "'snmpconf@snmp.com'" Subject: RE: snmpconf Minutes of SNMPCONFG WG Meetings at 47th IETF - Repo rted by Jon Saperia Date: Mon, 10 Apr 2000 14:04:33 -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 Jon, Thanks for the detailed report. A couple of minor nits: 1. If we are going to attribute the Q and As, which is helpful, I think, although the IETF guidelines say don't do that, we need to disambiguate some of them (multi-Steve's, multi-Randy's (I think) and assorted Andy's, and who is GWW? Is that Greg? - change my comments to "Andrew" if that helps). 2. It would help to add pointers to slides at appropriate places (e.g. temp or permanent URLs) - the IETF people are good at fixing these up into permanent URLs when the proceedings are done. 3. Might be more appropriate to remove the editorialising in order to provide an accurate record - whilst your added comments are generally helpful, they do tend to alter the way a reader then would understand the following text. I think they'd be better made as mailing list comments. Thanks, Andrew **************************************************************** Andrew Smith tel: +1 (408) 579-2821 Extreme Networks fax: +1 (408) 579-3000 3585 Monroe St. http://www.extremenetworks.com Santa Clara CA 95051-1450 em: andrew@extremenetworks.com **************************************************************** > -----Original Message----- > From: Jon Saperia [mailto:saperia@mediaone.net] > Sent: Saturday, April 08, 2000 4:12 AM > To: minutes@ietf.org > Cc: saperia@mediaone.net; snmpconf; Bert Wijnen; Randy Bush > Subject: snmpconf Minutes of SNMPCONFG WG Meetings at 47th IETF - > Reported by Jon Saperia From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 18:35:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06050 for ; Mon, 10 Apr 2000 18:35:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA02133 for snmpconf-outgoing; Mon, 10 Apr 2000 18:11:47 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Apr 2000 18:14:23 -0400 Subject: Re: snmpconf Minutes of SNMPCONFG WG Meetings at 47th IETF - Repo rted by Jon Saperia From: Jon Saperia To: Andrew Smith CC: "'snmpconf@snmp.com'" Message-ID: In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC721@SOL> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit on 04/10/2000 5:04 PM, Andrew Smith at andrew@extremenetworks.com wrote: > Jon, > > Thanks for the detailed report. A couple of minor nits: > > 1. If we are going to attribute the Q and As, which is helpful, I think, > although the IETF guidelines say don't do that, we need to disambiguate some > of them (multi-Steve's, multi-Randy's (I think) and assorted Andy's, and who > is GWW? Is that Greg? - change my comments to "Andrew" if that helps). > > 2. It would help to add pointers to slides at appropriate places (e.g. temp > or permanent URLs) - the IETF people are good at fixing these up into > permanent URLs when the proceedings are done. > > 3. Might be more appropriate to remove the editorialising in order to > provide an accurate record - whilst your added comments are generally > helpful, they do tend to alter the way a reader then would understand the > following text. I think they'd be better made as mailing list comments. > > Thanks, > > Andrew Thanks for the comments. As I mentioned in the earlier note, I had planned on sending them out over last weekend, and I did. With regard to the URLs, that is a good idea and I will see what I can do - perhaps I will put them up on my WEB site when I get a chance. Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 18:35:39 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06051 for ; Mon, 10 Apr 2000 18:35:39 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA02259 for snmpconf-outgoing; Mon, 10 Apr 2000 18:16:18 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Apr 2000 18:18:56 -0400 Subject: Re: snmpconf Working Group Presentations From: Jon Saperia To: Message-ID: In-Reply-To: <200004102100.RAA17950@aix43.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 04/10/2000 5:00 PM, Steve Moulton at moulton@snmp.com wrote: > > The snmpconf working group presentation slides are available via > anonymous ftp in ftp.snmp.com, directory pub/snmpconf. > > You need to explicitly cd pub/snmpconf to see a directory of the files. > > I would have made these available via majordomo, but I could not > get it to successfully mime the files in the short amount of time > I have available to make these files available. > > The files are > > bcp-meeting-2.ppt > bcp-overview.ppt > policyModule-thurs.ppt > policyModule-tues.ppt > snmpconf-overview.ppt > snmpconf-partain-day1.ppt > snmpconf-partain-day2.ppt > Thanks Steve, you anticipated Andrew's request. /jon From owner-snmpconf@seymour39.SNMP.COM Mon Apr 10 18:37: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 SAA06087 for ; Mon, 10 Apr 2000 18:37:28 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id SAA02316 for snmpconf-outgoing; Mon, 10 Apr 2000 18:21:26 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Mon, 10 Apr 2000 18:24:04 -0400 Subject: Re: snmpconf Working Group Presentations From: Jon Saperia To: Message-ID: In-Reply-To: <200004102100.RAA17950@aix43.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 04/10/2000 5:00 PM, Steve Moulton at moulton@snmp.com wrote: > > The snmpconf working group presentation slides are available via > anonymous ftp in ftp.snmp.com, directory pub/snmpconf. > > You need to explicitly cd pub/snmpconf to see a directory of the files. > > I would have made these available via majordomo, but I could not > get it to successfully mime the files in the short amount of time > I have available to make these files available. > > The files are > > bcp-meeting-2.ppt > bcp-overview.ppt > policyModule-thurs.ppt > policyModule-tues.ppt > snmpconf-overview.ppt > snmpconf-partain-day1.ppt > snmpconf-partain-day2.ppt > > Thanks, everyone enjoy. /jon From owner-snmpconf@seymour39.SNMP.COM Thu Apr 13 04:50:45 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24883 for ; Thu, 13 Apr 2000 04:50:45 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id EAA05735 for snmpconf-outgoing; Thu, 13 Apr 2000 04:25:14 -0400 (EDT) Message-Id: <200004130824.KAA08747@y5m602.lmera.ericsson.se> To: snmpconf@snmp.com Subject: draft-ietf-snmpconf-diffpolicy-01.txt 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: <8744.955614271.1@y5m602> Date: Thu, 13 Apr 2000 10:24:32 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by seymour39.SNMP.COM id EAA05731 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 8bit Greetings all, I have just submitted draft-ietf-snmpconf-diffpolicy-01.txt to the ID folks. For those of you who are impatient and want to see it now rather than wait for the official announcement, you'll find it at http://www.cs.utk.edu/~partain/draft-ietf-snmpconf-diffpolicy-01.txt We now look forward to a lively discussion. 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 Fri Apr 14 06:59: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 GAA05455 for ; Fri, 14 Apr 2000 06:59:08 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id GAA02274 for snmpconf-outgoing; Fri, 14 Apr 2000 06:40:23 -0400 (EDT) Message-Id: <200004141039.GAA05271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: snmpconf@snmp.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpconf-diffpolicy-01.txt Date: Fri, 14 Apr 2000 06:39:45 -0400 Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Configuration Management with SNMP Working Group of the IETF. Title : The DiffServ Policy MIB Author(s) : H. Hazewinkel, D. Partain Filename : draft-ietf-snmpconf-diffpolicy-01.txt Pages : 27 Date : 13-Apr-00 The MIB Module described in this document provides a conceptual layer between high-level 'network-wide' policy definitions that affect configuration of the differentiated services (DiffServ) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring DiffServ at a conceptually higher layer than that of the DiffServ Architecture MIB [DSARCHMIB]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-snmpconf-diffpolicy-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpconf-diffpolicy-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000413095607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpconf-diffpolicy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpconf-diffpolicy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000413095607.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-snmpconf@seymour39.SNMP.COM Mon Apr 17 03:00:46 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26928 for ; Mon, 17 Apr 2000 03:00:45 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id CAA18406 for snmpconf-outgoing; Mon, 17 Apr 2000 02:37:55 -0400 (EDT) Message-ID: <15F58915DF84D311AC7D0090279AA614128238@ITC-EML2> From: Dan Romascanu To: "'mrm@yagosys.com'" , snmpconf@snmp.com, dromasca@lucent.com Cc: bwijnen@lucent.com, "'hubmib@hprnd.rose.hp.com'" , "'johnf@rose.hp.com'" Subject: snmpconf RE: Why rfc2668/MAU-MIB refuses import InterfaceIndex TC Date: Mon, 17 Apr 2000 09:35:52 +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 > Mike, > Thanks for the observation. I think this was an editorial omission which can be fixed in a future spin. The editor probably focussed on the technical changes and we all missed this one (including the WG chair and the technical advisor). I agree that it would be a good thing that the BCP document in snmpconf add the recommendation of re-using existing TCs with similar semantics, and MIB editors should thrive towards implementing this recommendation. Regards, Dan > -----Original Message----- > From: Mike MacFaden [SMTP:Mike.MacFaden@yagosys.com] > Sent: Sun April 16 2000 22:01 > To: snmpconf@snmp.com; dromasca@lucent.com > Cc: bwijnen@lucent.com > Subject: Why rfc2668/MAU-MIB refuses import InterfaceIndex TC > > > > Hello, > > Why wasn't the mau mib upgraded to import InterfaceIndex TC from rfc > 2233 as was done to the EtherLike-MIB? > > This object originally from rfc 2239: > ifMauIfIndex OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This variable uniquely identifies the interface > to which the MAU described by this entry is > connected." > REFERENCE "RFC 1213, ifIndex" > ::= { ifMauEntry 1 } > > could have been fixed in rfc 2668 as: > > IMPORT ... > InterfaceIndex FROM IF-MIB; > ... > ifMauIfIndex OBJECT-TYPE > SYNTAX IntefaceIndex > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This variable uniquely identifies the interface > to which the MAU described by this entry is > connected." > ::= { ifMauEntry 1 } > > EtherLike-MIB followed this tack from rfc1643: > > ifIndex, transmission FROM RFC1213-MIB > > to 2358/2665: > > ifIndex, InterfaceIndex FROM IF-MIB; > > The Best Current Practices/SNMPCONF wg document should say something > about using existing TCs for a given well known semantic > *if it exists* and explain how to fall back to using a weaker reference > (a base type and a REFERENCE clause) under certain conditions. > > I'm sure there are such cases as this where it is best not to and > the IETF standards process does warp MIB documents in unique ways > but after looking at the evolution of EtherLike-MIB vs MAU-MIB I'm > unclear as to what happened here. > > > Thanks in Advance, > Mike MacFaden > Riverstone Networks, Inc > From owner-snmpconf@seymour39.SNMP.COM Mon Apr 17 17:43:27 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10375 for ; Mon, 17 Apr 2000 17:43:27 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id RAA01418 for snmpconf-outgoing; Mon, 17 Apr 2000 17:28:31 -0400 (EDT) Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB06D3FCF7@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'mrm@yagosys.com'" , snmpconf@snmp.com, Dan Romascanu Cc: "'hubmib@hprnd.rose.hp.com'" , "'johnf@rose.hp.com'" Subject: snmpconf RE: Why rfc2668/MAU-MIB refuses import InterfaceIndex TC Date: Mon, 17 Apr 2000 23:27:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com I agree, and Dan, I assume you as WG chair in hubmib wiull keep an eye on this when the dopcument is ready for revision or advancement. Bert > ---------- > From: Dan Romascanu[SMTP:dromasca@lucent.com] > Sent: Monday, April 17, 2000 9:35 AM > To: 'mrm@yagosys.com'; snmpconf@snmp.com; dromasca@lucent.com > Cc: Wijnen, Bert (Bert); 'hubmib@hprnd.rose.hp.com'; 'johnf@rose.hp.com' > Subject: RE: Why rfc2668/MAU-MIB refuses import InterfaceIndex TC > > > > Mike, > > > Thanks for the observation. I think this was an editorial omission which > can > be fixed in a future spin. The editor probably focussed on the technical > changes and we all missed this one (including the WG chair and the > technical > advisor). I agree that it would be a good thing that the BCP document in > snmpconf add the recommendation of re-using existing TCs with similar > semantics, and MIB editors should thrive towards implementing this > recommendation. > > Regards, > > Dan > > > -----Original Message----- > > From: Mike MacFaden [SMTP:Mike.MacFaden@yagosys.com] > > Sent: Sun April 16 2000 22:01 > > To: snmpconf@snmp.com; dromasca@lucent.com > > Cc: bwijnen@lucent.com > > Subject: Why rfc2668/MAU-MIB refuses import InterfaceIndex TC > > > > > > > > Hello, > > > > Why wasn't the mau mib upgraded to import InterfaceIndex TC from rfc > > 2233 as was done to the EtherLike-MIB? > > > > This object originally from rfc 2239: > > ifMauIfIndex OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "This variable uniquely identifies the interface > > to which the MAU described by this entry is > > connected." > > REFERENCE "RFC 1213, ifIndex" > > ::= { ifMauEntry 1 } > > > > could have been fixed in rfc 2668 as: > > > > IMPORT ... > > InterfaceIndex FROM IF-MIB; > > ... > > ifMauIfIndex OBJECT-TYPE > > SYNTAX IntefaceIndex > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION "This variable uniquely identifies the interface > > to which the MAU described by this entry is > > connected." > > ::= { ifMauEntry 1 } > > > > EtherLike-MIB followed this tack from rfc1643: > > > > ifIndex, transmission FROM RFC1213-MIB > > > > to 2358/2665: > > > > ifIndex, InterfaceIndex FROM IF-MIB; > > > > The Best Current Practices/SNMPCONF wg document should say something > > about using existing TCs for a given well known semantic > > *if it exists* and explain how to fall back to using a weaker reference > > (a base type and a REFERENCE clause) under certain conditions. > > > > I'm sure there are such cases as this where it is best not to and > > the IETF standards process does warp MIB documents in unique ways > > but after looking at the evolution of EtherLike-MIB vs MAU-MIB I'm > > unclear as to what happened here. > > > > > > Thanks in Advance, > > Mike MacFaden > > Riverstone Networks, Inc > > > From owner-snmpconf@seymour39.SNMP.COM Thu Apr 20 21:50:00 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25023 for ; Thu, 20 Apr 2000 21:49:59 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id VAA13005 for snmpconf-outgoing; Thu, 20 Apr 2000 21:32:20 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 20 Apr 2000 21:35:22 -0400 Subject: snmpconf SNMPCONF Working Group Interim Meeting Logistics From: Jon Saperia To: snmpconf CC: Jon Saperia , Randy Bush , Bert Wijnen , Andy Bierman 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 Folks sorry for the delay. The additional details for making hotel reservations are below. Note that you are also responsible for making your own Air and Rental Car arrangements if you need them. For those not familiar with this area you will want to fly into San Francisco Airport - this hotel is in the City. Meeting Dates: Wednesday, May 17 9am - 6pm Thursday, May 18 9am - 6pm Friday, May 19 9am - 3pm Hotel: Sir Francis Drake Hotel 450 Powell Street San Francisco, CA 94102 We have been given an 800 number for our reservations: 800-227-5480 For additional information see: http://135.145.16.183/sirfrancisdrake.com/ The group name to use to get the group rate is: IETF The rates are $195 plus tax for a Single or Double and $215 for a tripple. **************************************************************************** IMPORTANT NOTE: 20 Rooms are held for us ONLY UNTIL April 28th. After that reservations will be on an as available basis on the current rate. Because of a special event over the weekend, we only have 10 rooms for Friday Night. If anyone has difficulty let me know and I can connect you with an agent that can get rooms in other hotels nearby as needed. Please act on this quickly. If you have any questions, please send me mail. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Apr 21 08:21:52 2000 Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13611 for ; Fri, 21 Apr 2000 08:21:51 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id IAA10146 for snmpconf-outgoing; Fri, 21 Apr 2000 08:06:24 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 21 Apr 2000 08:09:29 -0400 Subject: snmpconf Additional Helpful information about SFO Interim Meeting Logistics From: Jon Saperia To: snmpconf , Andy Bierman , Jon Saperia 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 most of you know the RMON WG is meeting the previous two days in the same hotel. Andy Bierman posted some additional information to the RMON group that people not familiar with the area may find helpful: Airport: San Francisco International (SFO) Airport Info: http://www.flysfo.com/ http://www.quickaid.com/airports/sfo/ Shuttle & Taxi Info: http://www.quickaid.com/airports/sfo/stop/sfo0698.html Note that the SNMPCONF WG is also still looking for additional sponsors for this event and a VGA projector for use during the meeting. If you can help with any of these items please send mail to saperia@mediaone.net Thanks /jon From owner-snmpconf@seymour39.SNMP.COM Tue Apr 25 15:35: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 PAA23831 for ; Tue, 25 Apr 2000 15:35:42 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id PAA07447 for snmpconf-outgoing; Tue, 25 Apr 2000 15:13:48 -0400 (EDT) Message-ID: <3905ECCF.D119054B@ctron.com> Date: Tue, 25 Apr 2000 15:06:55 -0400 From: David Harrington Organization: Enterasys X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: snmpconf@snmp.com Subject: Re: snmpconf The May interim Meeting - Please respond asap 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: > > Folks, I am working on making arrangements for the interim SNMPCONF WG > meeting that will be held May 17 to 19th in either San Francisco or just > south depending on availability. > > As some of you know, we are attempting to coordinate this meeting with an > RMON WG meeting that will take place Monday and Tuesday of the same week to > reduce travel for participants who might be interested in both and the Area > Director. > > In order to get a good rate, we need to know how many people are likely to > attend. Please send me a note as soon as you can to let me know if you plan > on attending either or both of the WG Meetings. Andy will poll the RMON list > as well. > > Thanks very much > /jon From owner-snmpconf@seymour39.SNMP.COM Tue Apr 25 16:40: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 QAA25506 for ; Tue, 25 Apr 2000 16:40:53 -0400 (EDT) Received: (from majordomo@localhost) by seymour39.SNMP.COM (8.9.3/m.000221) id QAA09285 for snmpconf-outgoing; Tue, 25 Apr 2000 16:22:45 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 25 Apr 2000 16:25:59 -0400 Subject: snmpconf Hotel Reservation Reminder 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 just a reminder for those of you that plan on attending the previously announced SNMPCONF interim meeting in San Francisco May 17 1- 19. Remember that the hotel is holding rooms for us until this Friday April 28th. After that time rooms will be on a price/space available basis only. /jon From owner-snmpconf@seymour39.SNMP.COM Fri Apr 28 10:30: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 KAA02124 for ; Fri, 28 Apr 2000 10:30:08 -0400 (EDT) Received: by seymour39.SNMP.COM (8.9.3/m.000221) id KAA02313 for snmpconf-outgoing; Fri, 28 Apr 2000 10:03:45 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 28 Apr 2000 10:07:04 -0400 Subject: snmpconf Interim - Hotel Reservation Reminder From: Jon Saperia To: snmpconf Message-ID: In-Reply-To: <39087D01.88086991@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-snmpconf@snmp.com Precedence: bulk Reply-To: snmpconf@snmp.com Content-Transfer-Encoding: 7bit Andy said it all. For folks attending the SNMPCONF WG Meeting May 17th to the 19th, if you have not already done so, you should make your hotel reservations. /jon ---------- > From: Andy Bierman > Organization: Cisco Systems, Inc. > Date: Thu, 27 Apr 2000 10:46:41 -0700 > To: rmonmib@cisco.com > Subject: RMONMIB Interim - Hotel Reservation Reminder > > > This is just a reminder for those of you that plan on attending the > previously announced RMONMIB interim meeting in San Francisco May 15-16. > Remember that the hotel is holding rooms for us until this Friday April > 28th. After that time rooms will be on a price/space available basis only. > > Andy