[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 


Jon Saperia
Joel M. Halpern
Bai Jian	
Mart Nurmet
Alan Luchuk
David Levi
Steve Moulton
Mike McFaden
Dave Harrington
Harrie Hazewinkel
Kwok Ho Chan
Dan Romascanu
Bob Moore
Walter Weiss
Jeff Case
Wayne Tackabury
Dave Partain 
Steve Waldbusser
Dave Durham
Chris Elliott

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 

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 
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? 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 
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 

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?
int i;
char descr[256];
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 
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 

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)
.  global

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), 


   1: run and delete policy (oneshot).  Anything touched
      remains in last state.
   2: run and leave in place
   3: run, replace with another policy

pmPolicyRestore RowPointer

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 

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 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

1  pmPolicyNonTemporalTerminate/pmPolicyRestore/pmPolicyDispose,
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 group
business 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

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.