NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Jonathan Saperia <saperia@mediaone.net>
David Partain <david.partain@ericsson.com>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
General Discussion:snmpconf@snmp.com
To Subscribe: snmpconf-request@snmp.com
In Body: subscribe snmpconf
Archive: snmpconf-request@snmp.com (index snmpconf in body)
The working group will create a Best Current Practices document which outlines the most effective methods for using the SNMP Framework to accomplish configuration management. The scope of the work will include recommendations for device specific as well as network-wide (Policy) configuration. The group is also chartered to write any MIB modules necessary to facilitate configuration management, specifically they will write a MIB module which describes a network entities capabilities and capacities which can be used by management entities making policy decisions at a network level or device specific level.
As a proof of concept, the working group will also write a MIB module which describes management objects for the control of differentiated services policy in coordination with the effort currently taking place in the Differentiated Services Working Group.
Deliverables
1. A Best Current Practices document to provide guidelines on how to best use the existing Internet Standard Management Framework to perform configuration management.
2. A MIB module which describes a network entities capabilities such as support for a particular type of security or a particular queuing method on certain interfaces. The module will also convey the capacity of the device to perform certain work.
3. A MIB module which can be used to concisely convey information about desired network wide Diffserv Based QoS behavior.
4. A document which describes potential future work needed to meet all the Requirements for Configuration Management.
Done |
|
Announce Working Group and call for Input |
Done |
|
Submit Initial Drafts for BCP and MIB Documents |
Done |
|
Meet at 47th IETF in Adelaide |
Done |
|
Interim Meeting |
Jul 00 |
|
New Internet Drafts, including a document describing potential future work. |
Done |
|
Meet at 48th IETF meeting in Pittsburgh |
Sep 00 |
|
WG Last Call on remaining Drafts. Submit to AD for consideration as BCP and PS. |
Done |
|
Interim Meeting |
Nov 00 |
|
Revised Drafts for BCP and MIB Documents |
Dec 00 |
|
Meet at 49th IETF meeting in San Diego |
Feb 01 |
|
Revised Drafts for BCP and MIB Documents including a document describing potential future work. |
Mar 01 |
|
Meet at 50th IETF meeting in Minneapolis |
Apr 01 |
|
WG Last Call documents |
Minutes from the snmpconf Working Group sessions
IETF50, Minneapolis, Minnesota USA
21 and 23 March 2001
Reported by Glen Morehead
Session 1 - 1530 to 1730, 21 March
Minutes prepared by Glen Morehead
Note takers were David Harrington (dbh@enterasys.com) backed up by Glen Morehead (glen.morehead@powerupnetworks.com)
NOTE: The slides referenced in these minutes are available at ftp.snmp.com/pub/snmpconf/ietf50/ and will be submitted with the minutes.
---
The agenda was presented by Jon Saperia for bashing; no changes were requested. (slides in working-group-agenda.ppt)
---
Presentation: Dave Partain - Status Update.
(continuing with Jon's slides)
Good progress has been made in the last month. There has been lots of activity on the mail list. We are getting close to completion. The primary focus now is to discuss any new items for each document. Nearly all of the items from the January 12 ToDo list are completed. Work will continue on the list until forward progress stops.
We're hoping to resolve all issues and set a deadline within the next week or two. The deadline will be announced on the mailing list. If changes are requested, the person that wants the change has the burden of proof. We will work to complete any issues raised on the mailing list, and then will issue the WG last call.
---
Presentation: Wayne Tackabury - Status of the BCP Document.
(slides in bcp.ppt)
Wayne recapped the focus of the BCP Document, and summarized the changes made since San Diego.
* The topic reorganization has been finalized.
* There has been an extensive rework of the existing text, including significant clarification and invocation of many new examples.
* The previous example MIB was replaced with a new sample MIB designed for this document (BLDG-HVAC-MIB).
* The glossary section was rewritten.
The changes are detailed in the slides.
There was some additional discussion of whether this is best current practice, reflecting discussion from the mailing list.
---
Presentation: Harrie Hazewinkel - Status of the Diffserv Policy MIB. (no slides were used)
This MIB is small because diffserv modified their MIB to adopt our design. The example of how to use the MIB has been extended, but it has been kept simple.
---
Presentation: Steve Waldbusser - Status of the Policy MIB.
A printout of the changes made was 4.5 pages long, but we are closer to the end than to the beginning. The ToDo list is getting shorter rather than longer. Now is a good time to read the document because it is getting stable.
Loosely-typed variables were added. A concern was raised that the management station can get confused if a string is used as an OID. This discussion was taken offline.
The reference language is now C++ not C. This change allows pass-by reference and loosely-typed variables.
QuickStart guides were added.
A new "unity" element was defined.
Counter32Delta() was reviewed.
CounterRate() was described and discussed. CounterRate() stores N values. For example, if the sampling rate is set to every 5 minutes, store 12 values to get 1-hour smoothing. A question was raised about how to synchronize between two different counters, and the answer was to start both counters on the same pass. The calling script must be responsible for discontinuity management. Questions were asked whether it is possible to change minInterval algorithmically, and what happens if there are errors doing reads of some samples. Steve and Jeff Case decided to take the discussion offline.
SignalError() can send an error for a scripts that doesn't die when it hits an exception.
PmPolicyAdminStatus - Should a 0 enum be used?
There was extensive discussion on createAndGo(). Questions and comments raised:
* Does setRowStatus do random indexing or incremental indexing? With createAndGo(), you need to keep an index to the row just created.
* There is an error in the example - status varbind must be set to createAndGo.
* Should createAndGo be classified as a convenience function or a general function?
* Dave Partain doesn't like the createAndGo() function, but some agents don't support createAndWait().
* Maybe this should be abstracted to create() to hide the differences between createAndGo and createAndWait.
* Do we need both semantics in the row creation?
* Should we continue work on createAndGo(), or just assume createAndWait()?
* A higher-level abstraction does more work, and simplifies the scripts.
* Different tables may have different support levels.
The ElementType Filter Rationale was discussed. A question was raised concerning how to run a policy on multiple types. The answer given was to use an "any". This is an implicit "foreach element in XXX".
There was lots of discussion on TypeRegOIDPrefix. It was decided to continue the discussion on the mailing list.
The PmSchedTable was discussed. It was suggested that maybe we're not using the right model here, and maybe PCIM got it right. It was suggested that it would be good to include a simple example of the types of schedules needed, specifically some of the RFC2445 types.
---
David Partain finished the presentations with some comments.
(included under Additional To Do Items in his slides, working-group-agenda.ppt):
* Examples are needed to help clarity, for example with all of the accessor functions.
* We need to document how to create vendor-specific extensions such as setCli.
* The IMPLIED question was addressed. It was agreed - IMPLIED is evil, and is now gone.
* Table indexing on pmRoleTable needs to be fixed.
---
Jon Saperia wrapped up the day with a preview of Friday's agenda.
----------------------------------
Session 2 - 0900 to 1130, 23 March
Minutes prepared by Glen Morehead.
Note takers were Steve Moulton (moulton@snmp.com) backed up by Glen Morehead (glen.morehead@powerupnetworks.com)
NOTE: The slides referenced in these minutes are available at ftp.snmp.com/pub/snmpconf/ietf50/ and will be submitted with the minutes.
---
Agenda bashing was completed at the first working group meeting.
---
The first presentation was a continuation of Steve Waldbusser's presentation from Wednesday, March 21, 2001.
Presentation: Steve Waldbusser - Policy MIB Issues. (slides in friday-policy-mib.ppt)
Cleaning up after failed action script is difficult. In particular, a script may make changes to the agent state that are difficult to back out on a script failure. One possible solution is to have a regCleanup() call that takes the row status variable for each row created, which is called on script failure.
Similarly, cleaning up scratchpad variables is difficult. A proposed change is to change the functionality of setScratchpad to remove a variable if no value is supplied. This can be called on script failure. Scratchpad variables need a storageType, to disambiguate which are stored across an agent reboot, and which are not.
In the case of a policy action script failing, there needs to be a mechanism to allow the lower precedence script to execute. One approach is to have the failing script call a function called defer() to allow another script to run. Concerns were expressed from the floor about the additional complexity this adds to the execution environment. Steve remarked that the original very synchronous model will not work effectively for this reason.
Wes Hardaker remarked that other policy working groups specify a fallback action, rather than a lower precedence action. Falling back to a lower precedence works in QoS but in a security policy realm is a bad thing to do. Steve agreed with this principle with regard to security and remarked that in this case you just not use defer. Unfortunately, this means that things might remain unconfigured.
Jon Saperia made the point that distinction between fallback and failure is important.
Wes continued with the fallback issue saying that the way this was handled in the in the IPSEC policy MIB is that there are multiple fallback actions specifiable. You also have runtime failures. He wants configuration to be external to the script in this case. We need a recommendation on the interaction between run time error and defer().
Steve Waldbusser clarified by saying that if you die with an execution failure in the filter, you fall back. If you die in the action you do not fall back. There is currently no semantic for falling back along the filter chain in the document.
Joel Halpern made the point that you need to clarify in the text what you expect to happen if policy one executes, it fails and defers(). You hit policy 2 and hit a defer(). What do you intend to remember? You need to tell the reader.
The next discussion point was on entity naming. Should the manager be called the PDP (Policy Decision Point) and the agent the PEP (Policy Enforcement Point)? Are these terms still in use? Joel Halpern said that the terms are still in use in COPS, but elsewhere, the document has expired and has not been replaced.
Jon Saperia mentioned that Bert has sent out note saying that we need to review latest Policy Terminology draft to align our terms.
Bob Moore said the use of these terms in core policy is not precise. We should not get too hung up as to the placement of the decision in PDP. There is no suggestion in PCIM that the PDP is the one and only point that makes the decision. Within the broad meaning, these terms do no violence do PCIM or core policy.
Jeff Case mentioned that is that somewhere around page 2 or 3 you might want to make a reference to RFC2571 snmp architecture spec that talks about command generator and command responder, and say we are going to use manager and agent. These are loosely similar (but do not create a normative reference) to terms in such a such a document.
Wes Hardaker expressed concern that this language is going to undergo a lot of changes after deployment. There is no way to version the language. He would like an object he can query to determine the version of the language. David Partain would like such a facility to determine versions of vendor extension libraries. The issue arose of how to deal with incompatible forward revisions; a version object would be adequate. All scripts will need a capMatch(version) invocation once there are multiple versions of the language.
Randy Presuhn mentioned that there are cases where library bugs get fixed but you have code that has become dependent on erroneous behavior. This can also happen when there are semantic ambiguities in the language.
David Partain stated that he didn't think we are going to fix this today. What are the chances that you will change out a script engine without looking at your scripts? I think we need to take this to the list.
Several issues came up on notifications, and were not resolved:
* Should there be a configuration notification on script failure facility?
* Should there be a way to throttle failure notifications? Should they be throttled by state change?
* Should the notification section be placed in a difference compliance statement, to make it optionally implementable?
* Should there be a time-based throttle on notifications?
The final discussion in this presentation covered code reuse. The original design did not allow for functions. There was tepid support for the ability to invoke a script from within another script, and stronger support for user-definable functions. One possibility would be to put function support into a capability set not required by the baseline.
---
Presentation: Jon Saperia - Capability Table Changes
(slides in capabilities-objects.ppt).
Several objects are removed from the pmCapabilitiesTable to simplify the table, in keeping with the starting small approach. In general, instance-specific objects were removed. capMatch() now works on a system-wide, not per-element, basis. A pmCapabilitiesOverrideTable was added to allow overriding the information in the pmCapabilitiesTable when the capabilities discovered were either erroneous or undesired. A fuller explication of this change will be sent to the mailing list.
There was some discussion about how security should be handled. The text says that policies are executed in the context of the last writer to the policy script. Is this text adequate? Do we need an OwnerString?
Brian Carpenter brought up the separate point that many router vendors have difficulties with storageType and don't like it. The problem is that entire configurations need to be written back to flash as opposed to the data associated with a single configuration, and that the flash environment on many router implementations does not handle this well. Several possibilities were discussed, including delayed write to NVRAM and having a "write all configuration" object. This has been an issue with the Diffserv MIB. Jeff Case reminded the meeting that rowStatus is a textual convention, and it is not the only reasonable paradigm. Bert Wijnen mentioned that issue on diffserv is that there was no persistence discussion in the document at all. That MIB is close to WG last call; we may need to help them with that.
Randy Presuhn refocused us back to the security discussion. Access rights are just one part of the problem. In a large system you may have different owners for different policies. The current indexing structure in the -05 draft is going to make multiple manager access control difficult. To make it tractable there has to be some sort of automatic correlation between the indexing and the VACM table.
David Partain brought up the point of the likelihood of someone being responsible for diffserv policy and someone else being responsible for user policy. You can do it with what you have now, but it would be more difficult than it could be.
Jeff Case reminded us that once you are on your favorite router vendor's console, you have no constraints on what you can change. Once you are in, you are in. We have more functionality that that today. To put in more w/out implementation experience is not correct. We may already have too much. A brain cramp to consider: If you want to keep policy writers separate, you may want to run separate agents instances in different contexts.
---
Presentation: Configuring DiffServ DataPaths using PolicyScript, PolicyMIB and diffServ Templates - Thippanna Hongal
(slides in diffservmib2.ppt)
Hongal has done some work on showing pictorially what happens in diffserv MIB.
Jon Saperia summarized this presentation as the best exposition seen so far of how the Policy MIB and Diffserv Policy Modules work together.
Brian Carpenter make the comment that the Gold example is a bit naive.
It turns out that the usual case is less complicated, which is not exactly what was expected.
---
Harrie Hazewinkel reviewed the discussions taking place with respect to the diffserv MIB. There is still much learning going on. In particular, templates can be reused across interfaces.
---
BCP Document Discussion - Mike MacFaden
(slides in bcp-2.ppt)
Mike reviewed the goals from IETF48, and what steps have taken place since then.
---
The final part of meeting consisted of a review of the action items.
Wes is to address the issue of language versioning and code reuse.
Steve Waldbusser is to make a proposal on ToDo item #33 (helper objects for management system fallover).
wstrlen() was removed as an action item. Randy Presuhn will look at international issues in general.
Steve Waldbusser will work on explaining why the notification registration table will not work, and will work on a discussion of duplication with respect to the notification MIB.
The IMPLIED keyword on the pmRoleTAddress will be removed unless there are objections from the mailing list.
There are three very different open questions in security:
* rights delegation
* ownership and management of the security
* notification scheme for configuration changes.
NOW IS THE TIME TO READ THE DOCUMENT.
It is proposed that we take two weeks maximum to propose changes to the documents and air any other concerns. On April 6 we close any additional items, assuming the diffserv documents are finished. The next draft can be done in two weeks. There will be two or three more versions before all is done.
The meeting adjourned somewhat ahead of time.
Agenda
Configuring Networks and Devices With SNMP
Best Current Practices for SNMP Configuration
Capability Table (Suggested Changes from .05 draft)
Configuring DiffServ DataPaths Using PolicyScript,PolicyMIB and DiffServ Template
Simplification for error recovery
Policy Management MIB Progress and Next Steps