Subject: snmpconf DRAFT- SNMPCONF Interim Meeting Minutes of meeting held in San Francisco May 17 - 19

From: Jon Saperia <[email-masked]>
Date: Wed, 31 May 2000 16:01:52 -0400

What follows is a draft of the notes taken and the SNMPCONF WG interim
meeting held in San Francisco May 17 - 19, 2000. I would like to thank David
Harrington and Barr Hibbs for their contributions to these minutes. If any
of the attendees have any additions or corrections (including duplicate
detection), please send them to me by 5:00 PM east coast time this Friday
June 2, 2000. I will work on them and also prepare the slide material
available to me at that time.

Thanks
Jon Saperia

Attendees: Jon Saperia, JDS Consulting
Andy Bierman, Cisco
Dan Romascanu, lucent
Steve Waldbusser, lucent
Andrew Smith, extreme
Jeff Case, SNMP Research
Joel Halpern, ivyplan
Bert Wijnen, lucent
Walter Weiss, lucent
Harrie Hazewinkel, covalent
Mike MacFaden, riverstone
Thippanna Hongal, riverstone
Deb Fitzgerald, nortel
Ken White, IBM 
Xiang Li, IWL 
Barr Hibbs, Ultraradus
Chris Wellens, IWL 
Dave Perkins, 
Randy Presuhn, BMC 
Don Goodnature, BMC
Dale Francisco, Cisco

Overall Summary:

This interim meeting was to have advanced the work of all three documents on
the working group charter. Time limitations and a desire to resolve some
pressing issues limited the focus to the Policy and Differentiated Services
Policy MIB modules. Work on the Best Current Practices Document (BCP) will
continue.

The meeting served as a way for attendees to exchange ideas and become
familiar with a proposed architecture. The main result of the meeting is a
fairly extensive set of issues that will be reviewed and discussed on the
working group email list. That list is contained in this summary.

Day One: Agenda Bashing - In summary, we agreed to start with the
Policy MIB Module, then work on the Differentiated Services Policy MIB
Module, then the BCP Document.

Architecture presentation:

Jon Saperia presented slides describing the overall architecture of the
SNMPCONF approach. These slides showed the relationship of the different
levels of policy information and how the different parts of the proposed
SNMP Configuration architecture realize this information. The presentation
will be made available on line separately.

There were a number of persons present who had not been greatly involved
yet, and it led to some useful discussions about and refinements of the
concepts.

There was a debate about terminology for device-type, or
implementation-specific or implementation-version-dependent. The group
preferred implementation-dependent over device-dependent. It was pointed out
that mechanism-specific is akin to standard MIB modules, while
device-specific (implementation-specific) was akin to vendor-extension MIB
modules. It was pointed out that the BCP terminology/descriptions were not
consistent with other documents and we agreed to make fixes to the BCP
document where necessary.

There was significant discussion about details and layers. There is a
continuum. Something (like time filters) can be high (in the manager) or low
(within the device). Sometimes, it is desirable to specify the specifics at
the high level, and at other times it is desirable to hide the low-level
details. Example: one customer wants a Holly four-barrel carburetor
installed; another customer just wants their car to go as fast as possible,
and allow the mechanic to select the best approach. Since policies may be
multi-conditional, it should be possible to create a policy that is part
abstract and part specific.

We discussed the presentation of levels of abstraction. There was discussion
about whether it should be described as levels, or whether device/instance
should be one axis in a matrix with domain/mechanism as the other axis? Are
there only four levels? Are the levels ordered? In the end we learned that
part of the confusion was that one slide was representing a simple taxonomy
while the other was attempting to represent a more detailed view of the
functions and data at a particular level of abstraction.

Policy MIB Presentation:

Steve Waldbusser presented slides on the design of the Policy MIB.

The purpose of the Policy MIB is to use SNMP to move policies to places that
can execute them.

There is a rich set of attributes that can be examined to determine the
state of the network/device/etc. There is a less rich set of attributes
that can be set (either by SNMP or other management-interface). During
discussion, it was observed that capacity and usage/utilization feedback is
an important part of the process.

Capabilities is a Boolean optimization: it is a true/false determination of
what is supported by a device. This Boolean is provided to make it easier to
determine what a device supports than by discovering and examining specific
MIB attributes. The Boolean could be incorrect, so Policy filters should
still check to verify that application of the policy may be inappropriate.
During the time between determining which policies should be distributed to
a device, and the time the policies should be applied to the device, the
capabilities may change. It is important to use these capabilities
optimizations carefully. Policies may be downloaded when not necessary;
policies may not be downloaded when needed. These error conditions need to
be detectable, and there should be some standardization in error handling.

Capabilities may exist at different levels of abstraction. Do we need to
clarify our terminology for capabilities, such as type and subtype?

A discussion on "scheduling  must we use a particular approach? " was
shelved for later discussion.

The BNF expressing the expression in the current document needs
close inspection and corrections. There are some problems. One issue is the
length of the OCTET STRINGs. This discussion can be done on-list, rather
than face-to-face.

The efficiency of evaluating filters may need to be improved by having some
standard expression pieces that constrain the scope of managed objects to be
considered. Requiring that all expressions begin with the roles would reduce
the costs of evaluation. We need to be careful to allow the initial
expression to be multi-valued, to reduce duplication of policies, and to
handle different vendors referring to something using different OIDs (Bay
MIBs vs. IETF MIBs)

Roles in SNMPCONF differ from roles in policy framework. Framework assumes a
centralized PDP that determines role combinations. The assumption is being
made that PDP has a semantic understanding of roles. SNMPCONF has found a
way to store "roles" on the target devices. This may not be lightweight.

We need to discuss whether iterations exist outside the rule, or inside the
rule. We need to discuss scoping versus filtering regarding the level of
abstraction. Some use rules to express policies, while others are using
policy to determine which rules should be distributed.

There are rules about what is allowed in the filters and in the actions.
SETS and compound statements - may not be used in filters.

Should the preferred language for expressions be C or maybe Perl, since Perl
is commonly used by operators and is commonly built into embedded
environment.

What should we do with an error? How do we handle runtime exceptions? We may
need exists() and isInstanced(). Do we need IPAddress, engineID, and context
to properly qualify objects? How do we handle error conditions with requests
to remote devices.

We need to determine how to wildcard roles (ifIndex.*). Should we support
if-then-else?

For time determination, should we use rfc2591, additional acessor
functions, or separate MIB objects designed for our purposes. It is useful
to have the time calculations at the device so there is no dependency on a
connection between manager and device. Rfc2591 resolves issues of local
time, daylight savings, etc. Is there a need for duration-based time stuff?
Does device need to understand time?

There was a discussion of needed debugging capability. Do we need a test and
verify function?  Does the pmTrackingElementToPolicyTable allow one to get
at the necessary information to debug the problems? Should we somehow log
the SETs when a policy is applied, with a time limit for persistence? Does
this table offer sufficient value to justify its existence? Should it be
possible to forceOFF the application of a policy to an element via this
table? That would provide one central MIB to control the forceOFF. This
suggestion needs to be discussed on the mailing list. Do we need to have
standard notification when policy is overridden? Should we add a last-update
field to pmTable? Should we add current_version field? Which policy group is
this part of?

Day Two

Review of Issues:

We reviewed topics to be discussed, both from yesterday¹s meeting and new
topics proposed by the attendees. The following lists were produced during
an extended conversation designed to generate topics for discussion both for
the remainder of the meeting and on the SNMPCONF mailing list. These issues
will be published again to the mailing list in groups to foster discussion
and resolution of issues.

A Meta-question was raised: how do we add items to the list of features, and
how do we resolve whether they will be accepted? Do we need to consider the
costs/benefits?

General Functional Questions:
    
1. Should operators be able to override policy? Where is it useful to
restrict this in the architecture - fall out issues?

2. We need to more fully specify terminology regarding capabilities type and
sub-type.

3. What do we call capabilities that are beyond type and sub-type such as
those found in the mechanism and implementation specific modules? The
mechanism for their discovery is?

4. Are capabilities and capacity information part of the policy decision?

5. How do we do duration time calculations?

6. How do we represent and deal with time of day in the policy expression?

7. Time based rules are good things, there are some scheduling approach
options:
        What light weight options do we want to allow?
        Do we require the device to know about time of day?

8. Would like to test a filter to get to the pointer to the attributes that
have been changed as a result of the policy.

9. Do the debug tables do enough?  Do they need to change or should they be
removed? What is needed to improve them and is it worth the cost?

10. When was a system last touched? What was changed and when was a
constellation of policies changed?

11. How do capabilities work?

12. How do we represent capacity and information about utilization?

13. General issue of debugging policies and the PmTracking table. How useful
is this and how do we want to support the function? Is more needed for these
tables?

14. How do we deal with revision of a single policy and sets of policies? Do
we have policy groups, and policy priorities. How will we represent them?

15. Is there fate sharing between policies in groups, if so how is this
specified?

16. How often do policy evaluations run?

17. Storage-type clarification for policies, are they all non-volitile?

18. Do/can-we start/stop polices as groups?

19. Resolution of the forced off in the pmTracking tracking table?

20. Do we want to allow cascading policy what are the implications?

21. What are legitimate policy names?

22. Notifications - what is the proper role, what are the proper
notifications to be developed?

Execution Environment Questions:

1. What are the implementation target environment requirements for the work?

2. What are the minimal requirements for systems that participate in the
policy work and configuration.

3. Would like clearer definition of what Œthis element¹ is.
        
4. What is the scheduling environment?

Policy Processing Questions:

1. An agent that gets a bad policy should do the right thing where right
thing is to be defined.

2. Expression examples would be helpful: can we get (a+b) and ((a+B)*c) or
a+(bxc) or (A+B)xc?

3. How do we handle syntax errors?

4. How do we handle run time exceptions -How many errors are OK within a
policy?

5. How to deal with partial failures - notification of policy in trouble?

6. Types of exceptions - e.g. divide by zero or parts of the system
failures. Token and run time exceptions?

7. What is the role of the manager in evaluating expressions?

8. What type of error reporting from the agent is required.
    -agent validation functions and what type of errors
    -Policy testing/verification prior to putting into service

9. Is it a requirement that we support UTF8 in our accessor functions?

10. Do we want to feed values from filter in to the policy action?
    - Intermediate values?
    - After we get a return value do we want to fire an action, and if so
      with a parameter other than true false, passing arguments.

11. Is the constraint of left and right useful?

12. Do we need both action and filter or would one do? What are the
interactions allowed?

13. Need to address the question of the syntax of an identifier - what is
the proper syntax of ifType.$1 - what is the structure including
wildcarding?

14. What are the implications of wildcarding and implications in both
directions in the role tables.

15. How big should an expression be allowed to be?

16. Not possible to download all policies everywhere. Must subset what to
send so must handle two errors: download superfluous policy, fail to
download needed policy: Type I and Type II - false positives

17. How do we detect and how to standardize error handling.

18. Estimated number of policies that we need to handle - we need the
architecture to be able to scale up and down - what attributes are required
to meet this goal?

19.Where to start the policy evaluation?

20. How often to evaluate the filter and when?

21. Is iterator is outside or inside the filter statement?

22. Is one iterater sufficient or do we need nested iterators.

23. How do we select instances?

24. What do we want for role - iteraters how many where.

Language Related Questions:

1. Language for expressions. To what degree do we want to use an existing
language, and to what extent do we want to define our own?  If we leverage
an existing language, but constrain it to behave in ways that make it
incompatible with the original, then we do not get reuse of language
implementation, although we may get reuse of operator knowledge of languages
like Perl.

2. We need to discuss Choice of language and Richness of language.
Temporary variables, garbage collection; do we support temps or not?

3. Is UTF-8 support required in the expression language?

4. Extensibility Questions:
    For language and assessor functions - a natural one that allows for
    extension without re-opening the standard?
    sub-setting the language (do we allow or prohibit it)?
    sub-setting the assessor functions ibid?

5. Accessor functions  work to be done; reviewing proposed list.  How to
add new ones as they are needed? Can they go outside the SNMP universe?
Mapping of principals, etc?

6. How do we handle versioning issues?

7. There were some standardization questions: standardization of element
identifiers? capability type and subtype? extensibility mechanisms - are
these part of the expression language?

8. Is the attribute of the element predefined? Can there be multiple
instances?

9. How big should an expression be?

10. What are the execution environment requirements?

11. Temporary variables - do we want them: How do you dispose of them if we
have them?

12. There were a number of attributes that people felt were desired. These
include: needs to be debug-able - want to avoid memory leaks want to have
instrumentation that helps people find bugs, want to avoid loopers but want
iterators.

13. Issues about comments - comments in the expression - are they allowed?

Architectural and Relationship with other Documents Questions:

1. How do we expect the mechanism and implementation specific policy modules
to interact with the policy module?

2. The Policy MIB Module can manipulate any MIB object. Therefore, these MIB
modules need to create objects that can be manipulated by the Policy Module.
These need to be added to the Differentiated Services Policy MIB Module

3. Can policies cascade (nest)?  Can filters or actions cascade? Can a
policy reference another? How are policies named so they can be referenced?

4. Access control to the objects touched by the policy module need to be
specified. In short, when a policy is run, whose security credentials are
used?

5. How do we deal with security issues when a policy includes out of box or
out of SNMP 'view' operations?

6. The policy module provides for instance expansion.  The mechanism and
implementation specific modules provide for object expansion.

7. What is the semantic method for expressing the fact that a policy has
decided that a mechanism template is to be applied to a specific set of
instances? Do we want to use language or specific MIB objects? One view is
that the semantics are in the definition of the MIB object that is in the
mechanism specific module.

8. Issues about indexing between policy module and the Diffserv MIB module
need pointers in both directions. Linkages of the differentiated services
policy MIB module to the Policy MIB Module relationship; of the DS MIB to
our work.

Conflict Issues

1. How do we deal with intentional and unintended conflicts.
2. Is conflict detection or resolution a goal?
3. What happens when a policy is deleted? What if anything do you revert to?
4. How many errors are acceptable in a policy? How are they reported?
5. What happens when a configured element breaks that is executing a policy?

In the afternoon of the second day (Thursday) we had a long discussion of
the architecture. There seems to be general agreement on the chosen approach
though more work needs to be done to express this. The relationships (the
ones presented in Jon's slides and later represented by Steve) seem to be
the right ones and could be beneficial. Andrew suggested that a team might
want to do more work on this.

The theoretical approach is "for all elements, for all filters, then for
each instance which triggers an action, perform the action". This is too
inefficient, and we need to improve the scalability. One way is to define a
standard order of evaluation that will yield fast elimination of large
portions early in the process. Another approach is to preprocess the filter,
such that the number of filters to be processed is reduced. (i.e. the PDP
only sends appropriate role-based filters to the PEP)

The amplification of instances promises greater savings than amplification
of objects. The amplification of objects is useful when two vendors use
different implementations of the same things.

An agent should be able to determine which elements are supported for policy
(and which existing functionality is not supported for policy). Not all
functionality must be exposed to management via policy.

Instance amplification happens in the device-specific component, and in the
domain-specific evaluation.
The most interesting is the expansion within the filter expansion applied
over some set of objects, in a way to avoid evaluating the universe. The
agent should know which things it should be able to iterate over. The
manager should be able to determine which things the agent knows how to
iterate over. To constrain the number of types of elements, an enumerated
integer provides constraints to extensibility. A new proposal is to allow a
manager to download an OID Prefix to identify what should be iterated over.

Reuse of filters is unlikely to be frequent. Reuse of actions is more likely
to have benefits. However, the cost of indirection may be more expensive
than the benefits.

Friday Agenda 9 - 12 day three:

We agreed that we wanted to spend time on the following topics even though
that meant that we would not get to the BCP document before the close of the
meeting.

MIB Relationships:

Should Diffserv-Policy MIB Module refer to the Policy MIB Module, or should
the Policy MIB Module refer to Diffserv-Policy MIB Module? i.e. where should
the pointer (and dependencies/knowledge of relationship) be?

Jeff Case wants Policy MIB to point to Diffserv Policy MIB because he
expects to use a mid-level manager with a Policy MIB, and multiple Diffserv
Policy MIB instantiations on various devices. The indexes used by both
Policy MIB and Diffserv Policy MIB must be consistent across devices and
across reboots.

It is not always possible to determine from Diffserv Policy MIB entries
which Policy MIB entries are associated; it will not be possible to
determine from Diffserv Policy MIB entry which policies will be affected if
the Diffserv Policy MIB entry is deleted. (This is similar to not
understanding which programs  will be impacted by deleting  /etc/host file
on UNIX or  something.dll in WinXX). This may be made easier by having an
installation log which keep track of which installed pieces have
relationships, but this still wouldn¹t resolve all the possible anomalies of
these relationships. We need to study the issues here and make sure we have
a good design.

Scalability:

How often do policies execute, and where are the iterators?
    Continuously, event-driven, once, periodically, ad hoc, combination?
We may need to consider the parts separately:
How often do the filters get evaluated?
How frequently do actions get enforced?

How can the importance of filter evaluation be specified - which filters are
the most important when determining evaluation frequency? (not precedence in
conflict resolution)?

How quickly will you notice state changes?     Should we make it possible
for the NMS to specify maximum acceptable latency? This doesn¹t imply
polling; an async engine can provide very low latency without polling.
Should we have a Reevaluate-All button to force all filters to be
reevaluated?

Should there be a lower bound for detection of the action, and an upper
bound for the completion of the action Š these are two different things!

Rollbacks  When a policy no longer exists or applies, in the absence of a
specific policy which applies to the new state, what should the new settings
be? Do we need to keep original state for re-application? Do we keep the
same settings until a policy is found that tells us otherwise?

Wrap Up:

Conflict Resolution still needs to be discussed. We need to discuss how
policies will be "packaged," and how packages are defined.

Next Interim Meeting:

June 28-30 Boston is cancelled because certain people cannot make it that
week, and the consensus of the attendees is that the time to produce
modified documents, review them, and meet again, then produce modified
documents and review them before the IETF meeting is too demanding a
schedule.

The proposed alternative is to have an interim meeting on the Friday and
Saturday following IETF Pittsburgh (with a full day Saturday). An early-week
meeting would provide an opportunity for an overview of the work done during
this interim meeting, plus questions and answers, and leave enough time for
people to read all the necessary documents prior to the working sessions
Friday and Saturday.