[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Minutes of the SNMPCONF WG Interim Meeting - Pittsburgh, October 26-27, 2000
Please find attached the minutes of the SNMPCONF Working Group Interim
Meeting, hold in Pittsburgh on 10/26-27. Regards, Dan
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
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
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
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
Bob - In core policy you have a distinction between instance
identification and the policy congestion. Does the filter concept cover
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
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
Language and Library Discussion
-- Language issues
Steve - quickly discussing the changes in the language - quite a few in
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? Or pre-defined constants? -> Steve
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
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
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,
Discuss whether expression author can use const construct inside the
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
Wayne's global whiteboard problem - can content be inspected by network
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
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 want
the 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
-- 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
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
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),
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
Jon: Precedence is issue of overlapping policies; i.e. when schedules
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
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 have
a 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
This concludes the Policy Termination and Precedence discussion
At this point, David Partain brought three other working group
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
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
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
2 things keep shifting and the document needs to be updated to reflect
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.