NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 05-Nov-00
Jonathan Saperia <firstname.lastname@example.org>
David Partain <email@example.com>
Operations and Management Area Director(s):
Randy Bush <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
Operations and Management Area Advisor:
Bert Wijnen <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe snmpconf
Archive: firstname.lastname@example.org (index snmpconf in body)
Description of Working Group:
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.
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.
Goals and Milestones:
Announce Working Group and call for Input
Submit Initial Drafts for BCP and MIB Documents
Meet at 47th IETF in Adelaide
New Internet Drafts, including a document describing potential future work.
Meet at 48th IETF meeting in Pittsburgh
WG Last Call on remaining Drafts. Submit to AD for consideration as BCP and PS.
Revised Drafts for BCP and MIB Documents
Meet at 49th IETF meeting in San Diego
Revised Drafts for BCP and MIB Documents including a document describing potential future work.
Meet at 50th IETF meeting in Minneapolis
WG Last Call documents
No Request For Comments
October 26-27 Interim Meeting SNMPCONF Working Group
Minutes Submitted by Dan Romascanu and Steve Moulton
Joel M. Halpern
Kwok Ho Chan
Thursday, October 26
Thanks to the hosts.
Schedule of discussions
1. Script MIB discussion (Partain/Waldbusser)
* Show me the commercial implementation on boxes
* Are the semantic differences important and valid
* It's a general tool but we may want a specific tool
* It is too much of a good thing
Could RFC 2592 be good enough, could it be used? - Juergen's proposal
2. Language discussion (Waldbusser)
Proposal - use the language that is specified in the document
3. Execution environment (Waldbusser)
4. Scheduling module discussion (Hongal/Saperia)
Proposal - will be done with the scheduling MIB
5. Policy grouping, precedence and termination
6. Status of diffserv MIB
* What's being done
* What's to be done
* Disappear or changed?
7. Implementation ? - what's being done? Interoperability
8. What to do about Jon Saperia's ID
9. Status of the IPSec Policy WG cooperation (Partain)
* Need for examples - will be brought to help on the discussion
1. Script MIB Discussion
David representing Juergen: it is good to reuse technologies. The proposal is to re-use Script MIB for storing and transporting policies.
Jeff pointed out that we knew previously about the Script MIB, discussed it, and decided that it is not appropriate
Steve: there are three objects overlapping the script MIB - filter object, action object, description. In the Script MIB there is a lot of stuff that is not relevant. Execution environment does not fit with the environment assumed by the Policy MIB. The run table is inconsistent.
David - Separation of filters and actions is an important issue - it is more difficult to do with the Script MIB.
Steve: How to use the Script MIB - replace octet object defining actions and filters by references to the Script MIB. Concept of association is weak and seems to have documentation purposes in the Script MIB.
Dave D. - Script MIB is good for all that is procedural. Can the Script MIB be stripped down of the unnecessary objects, in order to see how it may work
Joel - looking at the compliance clauses - a lot of mandatory objects in the Script MIB are in our 'non-necessary' list.
Steve - using the script MIB would contradict the goals of simplicity and scalability. Doing the grouping would ease expressing paradigms like 'all Ethernet interfaces'.
Joel - does the model of execution look very much like running a script?
Bob - In core policy you have a distinction between instance identification and the policy congestion. Does the filter concept cover both?
Steve - Yes
David P. - The script MIB was designed for mid-level managers. It is the wrong tool for the purpose.
Jeff - need for partitioning of filters and actions will become obvious for everyone soon. Assuming this is true, the Script MIB is not simpler, because the number of objects to refer the Script MIB would be the same as the number of objects, and tougher to implement.
Dave - trying to summarize - there is value in the model as created by this WG, the generic Script MIB does not meet the requirements of this model
At this point Jon tries to summarize - question to the WG - do we believe, that the policy module as constructed is best served by not using the Script MIB? Hum if inappropriate! Strong consensus. If somebody has strong reasons to disagree, send reasons to the list.
Minutes takers are instructed to reflect this discussion faithfully, give the opportunity for discussions. A clear statement will be introduced in the document about why we are not wanting to use the Script MIB.
Language and Library Discussion
-- Language issues
Steve - quickly discussing the changes in the language - quite a few in the BNF
Dave H. raised the issue if changes be made on anything else but local variables? Text does not say
Steve - all is local variables.
Dave H. - ensure that only local variables can be modified in the filter side.
Dave H. - refer to the ISO definition of C rather than the ANSI definition
Data type constants definition - is this useful? Use #const instead of #define?
Steve - Or pre-defined constants?
conclusion - will use #const
Dave H. - Can we distinguish between non-executing an action because the filter result is zero, or because termination as result of an error?
Steve - add a gauge variable pmPolicyAbnormalTerminations for abnormal termination counter.
Dave H. - what the implementation would do - what value is returned? - in the case of an abnormal termination between of error?
Add a numerical gap between data types and error codes
Re-address delta function - delta("oid", minDeltaTime, ...) - other benefits - it takes away time keeping functions from the script, independence from scheduling skews, deltas times independent of scheduling time - issue deferred to the list
Are 64 bit integers going to be supported? Should all integers be 64 bit, or should we add long long? If we say all ints are 64 bits what happens when we pass 2^32+1 to snmpset? - resolution - support 64 bits, but do not use 64 bit for everything. Use long long when need to express 64 bits. Proposal will be taken to mailing list.
Details regarding casting ints (sign conversion, etc.) - make sure that casting rules are clear for snmp functions
Introduce note about Perl being a moving target therefore there is no reference-able version of Perl - though the language should be familiar both to C and Perl programmers
Is wstrnlen() needed?
Extend beyond $1-$9 (restriction on 2 character token is wrong)
The RowStatus accessor function implies the usage of RowStatus in one of the two ways accepted by SMIv2 for agents implementation - leave it as is
Decrease mandated minimum to 32 varbinds instead of 60
Define the concepts of 'element' and 'context' - might be necessary to change names - resolution define "execution context", define "this element"
Should results of a varbind list be included in the same snmpset, as defined today in the document? - resolution could be defined one way or another, but it should be specified
Consider in examples having descriptor-style OIDs not in quotes so they aren't confused and considered legal to be sent over wire
Be very explicit that examples are using descriptors
Put other language stuff brought by Dave H., Joel, other, on a list of items to be discussed after some examples are presented
-- Library Discussion
Library went through substantial changes
Bob - Relationship between the accessor functions and the MIB access rights is not clear - text should be written about inherited access rights after Steve investigates the issue more.
Allow OID assignments?
i = ifNumber.0;
/*not C but would increase efficiency in local SNMP contexts */
/*open - would get to that later */
Discuss "inherited" access rights - Dave H. put a security name in the policy table? DISMAN specialists need to be consulted - decision - this is delayed for the agenda in the meeting in San Diego, discuss on the mailing list and bring specific proposals before the San Diego. Organize a meeting to bring in a smaller group of experts - Ross Mundy, etc.
Discuss whether expression author can use const construct inside the scripts -
Steve proposes that this is not necessary
Jeff - why is it necessary?
Dave H. - diffserv has some well known constants that we would have globally named and used, this is the global const construct that would be really useful . Is global naming naming? - looks like fixing the problem is more painful than the gain. This is the consensus of the meeting, may be raised again in the future
Discuss whether varbinds may be indexed by strings. Suggestion was made to make ifindex a string variable rather than a quoted string. Rejected, because it would not work for ifIndex.1.
Pursue typelessness - Whether to use only a typeless getvar and abandon getint?
Wayne's global whiteboard problem - can content be inspected by network management?
Scratchpad discussion was started - to be continued on Friday.
Friday, October 27
Status of DiffServ MIB (Hazewinkel)
Presentation of diffserv concept and model diagram
MIB tables - datapath starting point table, traffic classifier tables, meter functions tables, action tables, queueing element tables All tables can be used for configuration, except the diffservDataPathTable
- needed a starting point table for specific data path configuration
Dave - is a way to start policy needed? Proposal - one table which specifies the indexing. That's all that will be left in this WG MIB module. A good text explanation about how the different pieces fit will be added (how it gets started, where roles come from, etc.)
Kwok - We still need an ifIndex some place in the management system that is mapped to the role or sets of roles that are relevant for the policy
There needs to be a difference between the button that activates the mechanism in the policy MIB and the specific policy algorithms that should be defined in the mechanism specific MIB. 'Invoke the algorithm by reference and not by value.'
Bob M. will prepare a proposal with two RowPointer TCs, one for targets that must be copied when a template is applied to an interface, and the other where there will be multiple pointers to a single target.
Back to the Language Discussion
Scratchpad discussion - example about RMON matrix - raised issue whether scratchpad would be consistent between reboots
Dave H. suggests that we create flags about scratchpad being consistent between reboots and being shared
Wayne - do we need a table reflecting what policies are in a state of running or executing? -Steve - it is already reflected in the MIB
Should we make scratchpad contents visible in MIB objects?
Joel: This scratchpad represents the allocation of a row in a table. What happens to the scratchpad if there is a power failure? If the row allocation persists across the power loss then you wantthe scratchpad value to exist. If the policy goes away, you want the scratchpad to go away (fate share).
-- Next issue: variable bindings indexed by strings.
If we are going to take the approach that OID and constant translations are done by the manager; we ought to leave varbind translation in the manager and leave it out of the language. There is no reason to have varbind list naming in the agent; this should be in the manager. Sure it makes it harder to debug; but lighter to implement, and is parallel with leaving OID and constant naming in the manager.
Current Varbind naming is by integer index (0..).
Discussion about use of varbind lists as arrays of local storage. This to solve the issue of how we declare/maintain local storage.
There was a long discussion about whether an integer index on a varbind will be sufficient for readability, or if we need a string index. The room was tilting towards using a integer index, but strong consensus within the room was not reached.
-- Next issue: should varIndexs be integers or strings.
Aside: varIndexs are used to index scratchpads. In short, should objects in a scratchpad be named by integer or by character string. The general feel of the room was that we do want to allow strings as varIndices.
-- Next issue: Implied getints.
Do we want to allow the semantic
i = ifindex.3
do an implied get and put the value in i? After some discussion the consensus of the room was that we should not have an implied getint.
-- Next issue: How do we handle Wayne's global whiteboard problem.
Problem: We need to be able share data say between same policies on different elements. 4 instances:
. policy*element (i.e, scratchpad data is scoped by policy and by element). We already have this.
. all elements * 1 policy
. all policies * 1 element (not useful)
One proposed solution is to add an argument to get/setScratchpad to specify policyElement/policy/global for scope of namespace. This led to discussion of when to free a scratchpad entry. The proposals were
. Keep track of who did the last setScratchpad on an item; and when that policy goes away the object goes away.
. Explicit delete scratchpad entry function
. If the thing that created something is destroyed, the things that are created are destroyed. Does the creator or the last writer determine fate?
A request was made to restrict the number of scratchpad entries that can be created. This met with general agreement, with the proviso that there may be different limits for policy*element, policy, and global.
Conclusion: Extend scratchpad functions with scope parameter,
Mention explicitly about
. Implementation specific limits on scratchpad variables per policy
. implementation specific limits on global scratchpad may be lower
. should we make scratchpad contents visible in MIB objects
. should scratchpads persist across reboots
This is the end of the discussion on accessor library.
The discussion turned to array bounds and bounds checking. The fact of an interpreter dumping core leads to a loss of the entire execution engine leads to great conservatism with respect to array references. The question is, have we been too conservative?
The point was brought up that Perl has arrays bounds checking, returning "undefined variable" on out-of-range array references. Should we look at doing that? Steve Waldbusser became "a rabid proponent of array indexing now that Chris mentioned dynamic array index checking".
The discussion moderator agreed that we should do this, and that the issue should be taken to the mailing list for consensus.
One participant was more comfortable with accessing substrings through accessor functions. Another made the point that "[" (the array reference index delimiter) is an accessor function.
Jon Saperia lead the next presentation, in which the set of issues revolved around
. What to do when a policy terminates.
. What to do in the event of a policy override
. What to do when a policy that had an override is to be restored.
. What to do when a policy that was modified by a policy with a
higher precedence is to be restored.
[see policy-termination.ppt discussion slides]
What to do when a policy that was modified by a policy with a higher precedence is to be restored.
Possible actions before a policy is activated:
. The objects did not exist, two forms:
. no such object
. no such instance
. Object instances existed but with different values (BGP timer had 60, but the guy at the CLI set it to 30).
. Objects existed as a side effect of some of the objects.
Policy termination is the removal of a policy entry, it can also be what happens on schedule boundaries. That is handled by a special object.
Policy Termination Choices
. Delete current policy
. Leave as is - take no action and leave values
. Install another policy
. Restore specific default
. Restore specific values other than default (say what it was before I changed it).
Jon proposes three pmPolicyTable objects for policy control:
pmPolicyNonTemporalTerminate (delete(1), leaveInPlace(2), installAlternate(3))
1: run and delete policy (oneshot). Anything touched remains in last state.
2: run and leave in place
3: run, replace with another policy
Semantics: Null if pmPolicyNonTemporalTerminate is delete(1) or leaveInPlace(2), otherwise pointer to the pmPolicyEntry that will replace the entry after execution.
pmPolicyDispose (delete(1), leaveInPlace(2), installAlternate(3))
Semantics: Same as pmPolicyNonTemporalTerminate except this specifies the behavior for interval (time-based) schedules. In the case of the use of alternate schedules, the schedule that is to be used is the one specified in pmPolicyRestore.
The question was raised about what we do about looping policies. This does not present a clear solution. What problem are we solving?
To clarify, Jon asked what happens to objects that are touched when a policy terminates. How do you reset: do we reinstall policy?
Floor: I thought we did this with precedence. We fall back to policy below it.
Jon: Precedence is issue of overlapping policies; i.e. when schedules overlap.
Floor: I Thought precedence is the tool to deal with this. We have intentional policy conflict so that when a policy goes away then the policy lower in precedence takes over. Use lowest level precedence to set default conditions; if there is no lower, then object values stay the same.
Jon: This implies policy groups, which we have not had until now.
Floor: the highest remaining precedence policy is the "default case". If there is no remaining policy, no action is taken. Note that the solution I specified does not deal with what happens to a policy when it deactivates. This should be a policy termination object that says what cleanup needs to be done. For example: policyDispose: when a policy will no longer execute; remove it or keep it in table. For example: When the 1-2 PM video conference policy is done; it should go away. But the baseline bronze policy should stick around.
The question was raised about what do you do with all of the other stuff floating around that a policy has created: what do you do with dangling markers, objects, etc?
One proposed solution: when you clean up something pointed to by a policy pointer, installation - dependent cleanup takes place. If we have a metabutton to make a bunch of stuff, we should havea metabutton clean the stuff up. The write metabutton reads the stuff before it sets it for cleanup.
There is not a clean semantic for associating objects with policies so we don't know what to clean up. We should have a one shot policy that is invoked that a policy goes away. It should run in the same context of the policy that it is running in and clean up the scratchpad &c.
The point was raised that we may already have it. You are about to create level 35; you create 34 at the same time to clean up.
The objection was raised that doing root cause analysis by analyzing variable state becomes difficult with this.
Another objection is that only having if else choices may trip you up.
At this point two new approaches have been proposed. The three currently under discussion are
2 put policies in precedence groups, and install policy so that each policy has a policy destructor installed in a higher precedence group
3 associate destructor policy with each policy (can be done w/ 1).
Proposed Basic Rules:
. Good policies will always have a default available
. We will use groups to organize precedence. You only resolve precedence in a group.
. The lowest policy number will be a default.
The point was raised that we may need different words; there is conflict with the concept of an active policy in the diffserv world.
Another objection is that as things stand in the diffserv world, there is no concept of global precedence.
A proposed scenario: imagine the possibility that when you evaluate the left half you make instance selection; the right half is invoked later to make sure the precedence evaluation is done correctly. For a given policy and a given instance you are always going to run the highest precedence policy in a group that is active. Note that when you have a policy exit, you may on exit set some things the the lower level policy immediately resets. One must be careful of race conditions.
This concludes the Policy Termination and Precedence discussion
At this point, David Partain brought three other working groupbusiness issues:
1) What are various companies are thinking about implementing?
He is doing internal prodding in Ericsson, talking with Chris Elliott at Cisco, and poking SNMP Research. We need to have proof positive that this stuff actually works.
Ideally he would like to see an interoperability event.
Jeff Case commented that this is going to happen; but not before San Diego.
2) He has been trying to work with Ricky Charlet in IPsec about ways we can work together particularly with respect to the diffserv policy MIB. Nothing is happening in IPSEC world right now; the IPSEC people are currently concentrating efforts elsewhere, but the cooperation will pick up.
3) There is a personal internet draft published by Jon Saperia. There have been some voices saying that the WG should adopt this. DLP is in favor. Are there thoughts about using this as a background document for what we are doing.
Three viewpoints were presented on draft-saperia-policysnmp:
. If the purpose of this document is marketing then is useful now; if it is a technical explanation it should be deferred.
. It aids in implementations. It has been useful in actual implementations. In terms of what we are doing now it is not so helpful. I think someone else should take over change control. It does lay terms and contexts for doing policy based management with SNMP, and provides a map for how the architecture is tied together (managers & agents &c).
. One of things that was good about it was the pictures. Do you anticipate that we can get some of this into the Simple Times - will you have time to do this? I think this group is getting badly outmarketed.
The question: is a document that describes the mapping of SNMP technology to policy in general and a document that describes where the various pieces in a snmp system are at an introductory level something the WG wants? It is in a non-graphic form (ID) today.
>From the floor: it is a good document but need some work in two areas
1 it needs some work in terminology alignment with other working groups.
2 things keep shifting and the document needs to be updated to reflect that.
This is not huge, but it is just work.
We have good consensus from this group that this document should be taken on by the working group. We need to get consensus from the working group at large via the mailing list.
SNMPconf - December 14, 2000 13:00 - 15:00, and December 15, 2000 09:00 - 11:30
Chairs: Jon Saperia (email@example.com) and David Partain (David.Partain@ericsson.com)
Agenda was published as http://www.ietf.org/ietf/00dec/snmpconf-agenda.txt, and the only changes made were re-arrangements of topics due to time constraints.
The note takers for the sessions were Rob Frye (firstname.lastname@example.org),
Russell Dietz (email@example.com), and Steve Moulton (firstname.lastname@example.org).
David Partain opened the meeting, Blue attendance sheets were circulated. Jon Saperia indicated what the current drafts are, how to join the mailing list, and displayed the agenda.
The first day of the meeting had presentation and discussion of the Policy Management MIB with some related discussions about accessors and language features, and the presentation of status on the Configuring Networks and Devices with SNMP BCP. Day two had more accessor and language discussion and a presentation of issues that have arisen in the DiffServ Policy MIB. The text of these meeting notes have been re-arranged to keep the accessor and language items together.
Session One: December 14, 2000 13:00 - 15:00
The first document discussed was the Policy Management MIB (draft-ietf-snmpconf-pm-04.txt), presented by Steve Waldbusser. There was much work done on the current version; 5 slides of changes were presented. Some of the significant highlights are:
- Scratchpad functions were extended and include scoping, examples of scoping were given.
- Parameter tokens $1 through $9 were increased to allow $01 thru $99, and these parameters are available in local variables.
- Text was changed to use const" in the document for built-in constants,
rather than "#define".
- A gap was added in numbering between data types & error codes to allow enough room for future data type expansion.
- Added pmPolicyAbnormalTerminations, which counts the number of times that policy execution has failed.
- Minimal varbind list length was changed to 32 variables (from 60) for each Policy instance.
- Added 64-bit "long long int" integers, getint() modified to return "long int".
- Added array derefencing; the contents of octet string objects in strings can now be returned and a way was needed to access binary data in octet strings.
- Added support for Strings.
- Filter scripts execute immediately when network elements are discovered; action scripts execute immediately when its related Filter evaluates TRUE.
- A script code table was added for scripts that are larger than the MTU; multiple SNMP sets will be needed to build the script, then reference it in the other MIBs to trigger its execution.
- Added newCapability & newRole notifications, add registration table for managers to receive these notifications.
- A description of the handling of SNMP errors was added.
- New BNF was defined to account for the various changes made; there may be some discussion of the BNF on the mailing list.
- ISO C, not ANSI C (X3J11), will be used as the standard language definition; with the addition of String support, there was some discussion about making C++ the standard language definition though conclusion was reached that C should continue
to be the standard reference, due to concerns about needing to make it simple so implementation on embedded platforms would be possible. This may not be relevant, as the BNF describes a subset of C or C++ anyway.
- A question was raised about whether this language definition & SMING should be combined, or at least use the SMIng functions in the SNMPconf language. However, SMING is data definition oriented, whereas the SNMPconf policy language is operator oriented, which makes SMING inappropriate at present for the SNMPconf expression language. Furthermore, because of the state of SMING,
it is not yet possible for SNMPconf drafts to make reference to SMING documents, other than as "works in progress". Therefore, between the C/C++ issues and SMING issues, we should stick with the C reference and then add the items we need from C++. There may be further discussion on the list about this, if anyone disagrees with this approach.
There was a question on the example given of pmPolicyAbnormalTerminations that led to the conclusion that more clarifying text is needed.
There was some discussion about the notification registration table, as to whether it is like RFC 2573's trapFilterTable & trapForwardingTable [correction: snmpNotifyFilterTable and snmpNotifyTable, respectively].
Although there are similarities, the RFC 2573 tables are not appropriate, as the snmpNotifyFilterTable is based on an information bus model; all traps from all sources go thru that table. This did not reach satisfactory conclusion and will be considered & discussed further on the mailing list. Similar discussion was related to the code table vs VACM in SNMPv3. No satisfactory conclusion was reached and this topic will be considered & discussed further on the mailing list.
Some Security issues were discussed and will be added into the draft. In particular, dealing with SNMP actions in scripts - how security parameters are to the SNMP calls and Mid-level manager inherited access writes - how to decide which security parameters to use.
Policy Grouping for precedence was discussed, particularly that we ensure that when a policy is no longer valid.
rather than waiting for "max latency" time to expire, when Policy C terminates and "uncovers" Policy B, that B would execute immediately. To accomplish this, an "on exit" clause was discussed so that policies would go to a "quiescent" state when the policy is no longer in effect,
and use precedence & grouping so that a "normal" policy runs all the time when some higher-priority policy is NOT running. Error conditions need to be considered, where setting of some variables depend on other settings elsewhere.
Policies run while the schedule indicates the policy is active and are dormant otherwise; some sets of policies are interrelated and these sets of policies should be turned on and off in tandem. Edge triggered versus level triggered scheduling (with addition of duration) was discussed to accomplish this; using edge-triggered scheduling, pairs of scheduleEntry's would be needed to accomplish one schedule although the addition of duration is not sufficient to provide sufficient level-triggered semantics. It was agreed that level-triggered scheduling is desired. There are unreliable semantics regarding when multiple, potential overlapping schedules touch a policy; consensus was that we probably want the semantic that the policy is active if ANY associated schedule is active. There was some discussion about whether the DisMan ScheduleMIB would provide the needed functionality, or if we could use it and change the meaning of certain objects when used with the Policy management MIB - it was agreed that this could result in confusion. The difficulty in having one policy clean up from another was discussed, with the possibility of having the scheduler do some cleanup (ie, do more than simple scheduling, such as be a "schedule guardian" or "ober-scheduler").
No matter what happens, the new policy must be able to determine the result. Based on the concerns outlined by Steve in his presentation,
Jon Saperia presented a new pmSchedTable to the group designed to address these concerns. This will be the basis for another revision of the draft.
Further work is needed in the scheduling (pmSchedTable) area.
Possible future draft changes include adding "pass by reference" and automatic initialization, to be discussed further on the list as needed.
The next document was Configuring Networks and Devices with SNMP (draft-ietf-snmpconf-bcp-03.txt), presented by Wayne Tackabury. Some highlights of that presentation:
- The scope was clarified, text was thoroughly reorganized, examples were expanded & clarified. The scope of the draft is to provide guidance on current practices using SNMP for configuration, focusing on using SNMPv3 and to provide the groundwork for policy-based SNMP configuration. The draft provides guidance for ISP Operators in SNMP deployment practices and configuration change diagnostics, guidance to agent/MIBmodule developers for developing coherent and scalable settable row objects and other features, and guidance to management station developers in implementing transactional semantics.
- A request was made for text to be contributed describing how some agent implementions do a lot of things incorrectly and how management stations can cope with these poor agent implementations.
- The current draft needs WG review and further editing; particularly security issues discussion. The plan is to go to WG last call after IETF 50 while avoiding scope creep. It is intended for Standards-track as BCP.
Session Two: December 15, 2000 09:00 - 11:30
With some examples from the Policy Management MIB, Steve Waldbusser led the discussion of Accessor Functions and Language Issues.
Language and Accessor Function issues included the following.
- In the Accessor Functions discussions (particularly in the first session), several examples were given, both simple (involving simple settings of integers) and complex (setting up RMON2 alMatrix monitoring).
These examples were used to show flaws of certain approaches and the use of the searchColumnEntry or storing the OID/index in the scratchpad between invocations.
- There was some discussion about how resource cleanup would occur,
particularly considering that there is no automatic garbage collection. No solution was reached in the meeting and may be discussed further on the mailing list.
- It was generally agreed to do "pass by reference" so that "&" is not
needed when passing parameters to accessor functions.
- Automatic, non-default, initialization was added. This occurs
whenever a script becomes active.
- There was considerable discussion about the need to
support both createAndWait or createAndGo operations.
The group consensus was that both createAndWait and createAndGo should be provided.
- The createAndWait/createAndGo discussion led into a discussion of the staging of building PDUs to send (or parsing/reading received PDUs) - whether by passing of varbinds 1 at a time vs a "varargs" approach. There was no clear consensus, so a small design team (Steve Waldbusser, Juergen Schoenwalder) will consider the possible approaches for building PDUs, including PDUs as objects with operator overloading.
- The next significant discussion was whether or not to add a "setCli()" function to interact with command line interface mechanisms (analogous to the "system" function call on Unix). Major concerns are of it being used in heterogeneous environments, it is ugly and goes against standards although is very practical, the numerous security issues (eg: how to map SNMP context to "login" equivalent), etc. Many reasons were given for doing so (even by those who would prefer not to), and many reasons against it. No consensus was reached, so we decided that this is to be investigated further - it was agreed that it's a bad thing to do, That the benefits may not outweigh the bad things. We will continue discussion on the list.
Policy Grouping discussions were next. The policyGroup & policyPrecedence semantics have not been worked out entirely, although in general lower numbered precedence value gives higher priority within a group, and the highest precedence policy whose filter allows it to run at a given time "wins". Time-ordering of policies within a group may be critical. It was agreed that any particular policy (action) should run as an atomic transaction. An entire policyGroup should be considered as a single logical policy, such that all policies are running at once, depending on what filters trigger for given elements.
Some discussion was done regarding booting/startup. Specifically, any policy not in a group can fire immediately, within its schedule, and for those in a group, no Policy can run, except for the highest Precedence policy, until all filters for all policies in the group have been evaluated. More discussion took place on the issue of what to do on "policy replacement" - what to do when PolicyB trumps PolicyA, B runs, then B terminates. The conclusion was that it is necessary to immediately re-evaluate A's filter & schedule to determine if PolicyA's actions need to be invoked. This leads to different windows of evaluating precedence and filters, and deciding appropriate actions. Filters should be rechecked immediately when precedence changes, new policies are added, or old policies are deleted. It was agreed that this needs further consideration on the list.
The next draft discussed was The DiffServ Policy MIB (draft-ietf-snmpconf-diffpolicy-03.txt), presented by Harrie Hazewinkel and Bob Moore. Harrie gave some background of what DiffServ is all about, then used the diffServDataPathTable in DIFFSERV-MIB as a starting point for SNMPconf policy-management discussions.
The DIFFSERV-POLICY-MIB is used to create templates with classifier, meter, actions drop, mark, and count using the diffPolicyDPCTable. A Policy example was used for providing gold service, applying EF marking to packets from certain customers. Obsoleted entries could be garbage collected, which is not currently defined in standard. There are further issues related to garbage collection, such as being able to tell if something SHOULD be GC'd. The conclusion was reached that we need to use template cloning with a single SNMP Set to build the right diffserv policy, although that leads to further problems with RowPointers.
Bob Moore then continued the discussion showing the difficult interactions between Templates & RowPointers. The advantages of this approach for doing data path parameterization was shown, and it was shown that duplicating Templates does not require duplicating parameterizations. It was determined to be necessary to identify in Templates what needs a new row (new object to point to) vs re-using the same object as in copied-from row(s). There is no simple answer to this; an example next-order problem was shown with "fan-out/fan-in" linkages, with the desire to share a new single instance rather than duplicating instances.
The current diffserv MIB has only StaticRowPointers which point "outside" of the template; it doesn't have dynamic RowPointers. It was suggested that an appropriate approach might be to not focus on the RowPointers, but on the pointed-to objects via a new kind of TextualConvention, which would have the negative effect of combining 2 distinct operations together: copy & clone vs the value & use of the objects. There are 2 steps involved: generating (creating the new row & new OID) or reusing (referencing the row by copying the OID), and determining how to plug in the relevant information to referencing tables.
An ID has been submitted into the Management and Operations area with 2 new TCs to handle these template conditions. However, that draft will likely be modified and re-submitted (on the MIBs list) with just the one TC that describes new behavior, not currently available with the definition of RowPointer operations. Meanwhile, the DiffServe WG is moving ahead with their approach in case the generalized ID doesn't become an RFC in time. It was agreed that between now & the next IETF (IETF 50, March 2001), the diffserv examples will be updated by David Partain.
To wrap up the meeting, Rob Frye agreed to distribute notes to the WG list not later than 12/22/2000 [note: they are being sent to Chairs on 12/25/2000]. There will be further discussion on the mailing list for at most 2 weeks about the need for an interim meeting before IETF 50 in March to discuss topics such as the "setCLI" function. We agreed to see how much can be done on list first, then hold an interim meeting if we do not reach consensus. The existing charter says that we will conclude our work by IETF 50 in March 2001.
Policy Termination and Precedence